Jim, you've stated that 6LSA respects the RFC 3697 requirement
to deliver the original, unmodified flow label.
draft-chakravorty-6lsa-01.txt makes that statement but does not
define any mechanism to explain how it's done. As far as I can see,
the ingress 6LSA router would have to signal downstream, and the
egress 6LSA router would have to keep state.
The mystery is solved in draft-chakravorty-bcc-fec-00.txt, where I find:
Because of the requirement to maintain the integrity of the Flow
Label field, the 6LSA switching technique can only be applied to
packets arriving at an edge port with their Flow Label field set to
zero. In future work on 6LSA, more generalized treatment of packets
that arrive with non-zero Flow Label will be presented.
In other words, 6LSA as defined today is incapable of delivering the
original flow label except for default traffic. That seems like
a substantial limitation.
Brian
Bound, Jim wrote:
You can see good example of 6LSA in Charts at:
http://www.nav6tf.org/documents/arin-nav6tf-apr05/5.QoS_and_IPv6_SC.pdf
The rest of the slides for IPv6 may be interesting to some from this
joint ARIN+NAv6TF meeting too.
http://www.nav6tf.org/html/nav6tf_events.html
/jim
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
