Brian, explanation below. This is why we believe this decent technical work needs review to further work on good input like yours and your review. This can be a means to use the IPv6 Flow Label in a very positive way for deployment.
> Jim, you've stated that 6LSA respects the RFC 3697 requirement > to deliver the original, unmodified flow label. Yes and the 6LSA archtitecture will support that, what we defined in draft-chakravorty-bcc-fec-00.txt initially is that the Flow Label will be zero from clients or forwarded to 6LSR. Clearly that will change, from the client, and even from edge routers that are not 6LSA-capable. More below. > > 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. That is correct. There are many methods to do that when the packet comes into the ingress 6LSR (6LSA Router). It also can be optimized to the egress 6LSR router to the destination router or client. Using in this draft FEC of flow label zero assumption also permitted a fast protototype and there is an implementation and I hope we can test it on Moonv6 in the near future to debug. It also permits review of the basic model and architecture before we decide on best way to move non zero flow labels. > > 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. The FEC structures and methods are defined today initially assuming this limitation not the 6LSA architecture. >From the 6LSA arch draft: draft-chakravorty-6lsa-01 > All lead packets, whether they are the first packet from the upstream > router or 6LSR or not, are treated like they were the first packet of > the flow. > Lead packet has no existing entry in the switching table of the 6LSR. > All lead packets have a 0 (zero) label coming into the 6LSA nodes > from a best-effort network. When source nodes are 6LSA nodes, lead > packets may carry non-zero labels. Conversely, hosts generating non-zero labeled packets have to work within the 6LSA domain. And we thought that it was clear to everyone that that 6LSA is the working paradigm. If one forces a non-6LSA paradigm and starts labeling the packets outside of the 6LSA network, then one needs to use the label distribution mechanism all across multiple network domains (that even MPLS does not do) and avoid using locally generated label model (one of the models we will propose) to avoid the very remote possibility of finding packets in a different flow with a duplicate label arriving with the same source address and through the same router port going to the same destination address. But, the key is we have to move non zero flow label packets as you suggest to the 6LSA egress router. 6LSA also want to have a very robust security method for packets that enter the 6LSA domain. That is work in progress too. The model of 6LSA is we can extend it to where we need it to go as architecture and it will support client-to-client flows restored is the objective. If we can get our collegues in the community to work on this we believe we can build a significant added value TE and QoS method here that will truly differentiate IPv6 capabilities on a network path, where IPv4 simply cannot accomplish. Also we are only working on IPv6. This model is not bogged down by any weight with any assumptions to support IPv4, thus, the model is free to evolve and execute based on what we can develop with IPv6. Thanks for jumping in here Brian we appreciate it and we need more review and the community work on this with the draft authors. /jim > > 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_IP > v6_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 --------------------------------------------------------------------