Francis,
On Aug 7, 2009, at 09:24 MDT, Francis Dupont wrote:
In your previous mail you wrote:
And I understand that current load balancers can only do this based
on a few fields:
src/dest IP addresses (two RLOCs), the IP traffic class, the IP
protocol field (UDP=17) and the src/dest UDP ports (xxxx and
LISP=4341).
I just don't see how this works very well with LISP, though... The
two RLOCs are likely to be constant for all traffic between the same
LISP routers, and ITR/ETR pair (right?).
=> in fact the IPv6 addresses don't need to be the same when xTRs are
attached to regular links with /64 prefixes. So IMHO most of this
discussion is insane:
:-)
- if we need to vary things between a pair of IPv6 xTRs it should
be enough (and simple/easy) to vary the addresses
The above was considered at the initial design stages of LISP, (I
think Dino may have considered this approach?); however, it was shot
down, because this would require the installers/administrators of the
LISP ITR to both know the reasons why the above is required *and*
configure the IPv6 ITR's with /64's to get the load-splitting benefits
across LAG/ECMP paths. (Remember the adage: "My network, my rules").
Instead, it's more 'straightforward' to just have the ITR's /
automatically/ calculate a hash of the incoming IP packet and stuff
that into the UDP source port before transmitting it out its uplinks
toward the ETR. The key advantage of this approach is that ITR's /
will/ be owned & operated by downstream customer's (i.e.: it's their
CE's) who are likely unaware of and, therefore, may not care about the
(extremely large) prevalence of LAG/ECMP paths through their upstream
providers ... until congestion occurs in their upstream providers and
they get upset. When in doubt, automatic == good.
-shane
- we already have a "waste" of 2^64 addresses per links so this should
never become a resource problem (:-)
- the O UDP checksum proposal obsoletes all the today deployed nodes
which check them (so all hosts I know and perhaps a lot of routers
too),
so if we believe something has to be fixed some routers should be
fixed
and not all BSD/Linux/MacOS/Windows boxes (software and hardware).
To summary not only it is better to encourage application of RFCs
than to twist them because they don't reflect the last idea, but
in this case this is a total economical non-sense...
Thanks
francis.dup...@fdupont.fr
PS: Margaret, the insane is not for you: your messages in this thread
are clearly the most reasonnable/rational.
PPS: to use the flow label (not alone) is not stupid, the 5-tuple is
not always easy to extract in particular with IPv6.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
