RE: 6LSA Slides and QoS

["Bound, Jim" <[e-mail]>]

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
> > [e-mail]
> > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> > 
> 
> 

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------