[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