[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RRG] The use of UDP in LISP




On Dec 10, 2007, at 1:51 PM, Iljitsch van Beijnum wrote:

On 8 dec 2007, at 19:23, Shane Amante wrote:

I think this can be solved by giving each ETR a small range of addresses rather than a single one. For instance, if the mapping system tells the ITR that an ETR has 240.0.0.5/29 then the ITR could send one flow towards 240.0.0.0, another flow to 240.0.0.1 and so on.


1) As one of the instigators to get Dino to move to the UDP approach for load-balancing, I can say we discussed this, but it was ruled out, since it creates administrative overhead for operators/administrators to acquire and /properly configure/ a large enough subnet on the ETR to get 'decent' load-balancing over LAG's, etc. through the core.

So? If we put in the spec that you MUST assign a /29, /28 or what have you to an ETR and all ITRs automatically use that entire address range, they'll simply have to do it or it won't work.

You might certainly be able to say MUST, but that doesn't mean everyone will configure ITR/ETR's that way. As one example, look at the plethora of RFC's related to Internet security that everyone MUST/ SHOULD/etc. follow and, unfortunately, don't ...

Furthermore, I, and lots of others, would much rather not be "protocol police" and chase people around telling them to fix their ITR/ETR deployments (by assigning a /29, /28, etc.), when we can easily accommodate it in the protocol automatically and for very, very, very little overhead.


The lack of address space doesn't sound convincing to me either, today everyone with an AS number has at least a /24 and obviously not everyone with an AS is going to run ETRs as that way we don't save any routing table state.

I'm not convinced that the load balancing issue amounts to much in the first place, by the way. In the vast majority of cases traffic will come from many different places so load balancing will happen without assistence.

As someone who has lived with the very acute pain of unfair load- balancing for the past several years, it is a very real problem -- the biggest problem today, and for the last few years, is EoMPLS. Only just recently has someone offered a couple of suggestions to alleviate the pain of EoMPLS:
http://tools.ietf.org/html/draft-bryant-filsfils-fat-pw-00
While I don't necessarily agree with the recommended approaches in that draft, I (and other operators) agree that it's a very real problem and needs to be solved.

Back to LISP, and any other proposal which uses tunneling, there will lots of cases where medium- to large- Enterprises and/or SP's are sending traffic from their network, tunneled through an ITR, to a decently sized content/server-farm or other SP's with ETR's. Don't assume that because either of the downstream/edge Enterprise's or SP's have 2 (or more) upstream SP's that they will always be evenly load- splitting their traffic between those two providers. When either Enterprise A or SP B has one of their access circuits cut, or when one of the upstream SP's is experiencing congestion, etc. then Enterprise A or SP B will move all, or nearly all, of their traffic onto the other upstream SP. This results in a lot of traffic being sourced from a single ITR toward a single ETR.

One other point to consider: if you are an owner of that ITR or ETR and you don't use this UDP encapsulation scheme, you will have very, very, very little input into the 'outcome' of that load-hashing algorithm in each core router that your tunneled traffic goes through, (it would just use the outermost src & dst IP's). When your traffic lands on a congested component-link, you're likely to be quite upset about that, but the SP that owns that core router is most likely going to be unable to do anything about it. Instead, the "quick fix" will be for end-users of ETR's (and ITR's) to change their load-splitting policy for EID -> RLOC mappings, which means they will want/need to quickly change state of the mapping system to fix the congestion problem. Now, why we would want to add this additional "emergency" bursty traffic load on the mapping system if it can largely be avoided, (and, instead, the mapping system can deal mostly with longer timescale traffic engineering)?

-shane

--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg