On 2009-08-05 11:26, Vince Fuller wrote: >> That said, I can't see any reason why ITRs and ETRs can't use >> the flow label among themselves, in a way completely compatible >> with RFC3697. But if their hardware engines can't include the >> flow label in the n-tuple, that's a problem. > > The issue isn't whether the "hardware engines can't include the flow label > in the n-tuple" on the ITRs/ETRs; since LISP is implemented on ITRs and ETRs, > we have no problem specifying their behavior. > > The issue is how to effect load-splitting across Link Aggregation Groups > (LAGs) in all of the non-LISP-aware transit routers on the Internet through > which LISP-encapsulated traffic will flow. > > Current operational reality is that the installed base of transit routers > on the Internet uses a hash of source/dest addres/port to split traffic > across LAGs so LISP uses an encapsulation that is compatible with that > reality.
Sure. But IMHO the LISP design should not be restrictive. It should be possible by design to change the fields used for the hash if the operational reality changes in the future. (In fact, one of the motivations for the exact choices made in RFC3967 was to make it possible to include the flow label in such a hash without knowing what sort of usage, if any, was being made of the flow label. And I see no particular issue with a network where some LAG-aware routers do include the flow label in the hash and others don't.) > > Specifying some alternate reality and hoping that the operational world will > modify its behavior to match doesn't seem very practical, particularly since > one of LISP's virtues is that it requires no changes to the transit routing > system. Well understood. But future-proofing is rarely an error. Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
