> 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.
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.
--Vince
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
