[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