In your previous mail you wrote: > - 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.
=> I can't see the difference with varying the UDP source port. Instead, it's more 'straightforward' to just have the ITR's / => it is not more straightforward, you can put the hash where you'd like. 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. => you have just to put at least one of the end on a virtual link to get up to 64 bits of path selection. IMHO it is more than one could ever need... Thanks [email protected] PS: IMHO this is an example of IPv6 misunderstanding: the solution was developed for IPv4 and as it doesn't fit exactly into IPv6 in place of adjusting the solution you propose to adjust IPv6. -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
