> > This may seem a bit unexpected, but after working on > > draft-carpenter-flow-ecmp (just updated) and working with > my student > > Qinwen Hu on some aspects of the flow label, it seemed like > time for > > another look at the flow label standard, and Sheng Jiang > was having similar thoughts. > > > > We'd like to discuss this in Anaheim if possible. > > > > I've had a read through this draft and support what it is proposing. > > In regarding the following processing rules: > > > o Considering packets outbound from the Flow Label > Domain, if MSB = > 0, a boundary router MUST NOT change the flow label. > If MSB = 1, > it MUST set all 20 bits of the flow label to zero, so that the > locally defined behaviour is not exported from the domain. > o Considering packets inbound to the Flow Label Domain, > if MSB = 0, > a boundary router MUST NOT change the flow label. If an inbound > packet has MSB = 1, it has originated from a source not > following > the current specification. This is considered to be an > extremely > unlikely case, and the boundary router MUST set all 20 > bits of the > flow label to zero, as the choice least likely to cause unwanted > behaviour. (Note that this means the rules for inbound and > outbound packets at the boundary router are identical.) > > one thought I had would be that there could be a use case where e.g. > when a packet leaves a flow domain and has it's MSB=1, and > enters another flow domain e.g. crossing the boundary between > enterprise network and an ISP, the flow label could be > changed to a MSB=1 value of local significance to the second > flow domain. This would be somewhat similar to how ISPs can > provide specific BGP community values for it's customers to > set to influence routing within the ISP's AS. If there is no > specified MSB=1 value for the second flow domain, then the > flow label must be set to all zeros.
Yes, the second flow domain should be also able to use the local defined behaviors. In my opinion, when the packet leaves a flow domain, the egress router does not sure whether there will be another flow domain or not (the second flow domain may be appear to be several hops away). So, it should leave the MSB=1 to keep the possibility. The rest 19 bits may be reset to all 0 depends or untouched depending on whether the egress router wants to prevent the exporting of local defined behaviours. Actually, I don't think it is necessary to do so. The leaking of locally defined behaviours is not harmful. Cheers, Sheng > > Regards, > Mark. > > > > > > > Brian > > > > -------- Original Message -------- > > Subject: I-D Action:draft-carpenter-6man-flow-update-00.txt > > Date: Wed, 17 Feb 2010 18:15:02 -0800 (PST) > > From: internet-dra...@ietf.org > > Reply-To: internet-dra...@ietf.org > > To: i-d-annou...@ietf.org > > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > > > Title : Update to the IPv6 flow label specification > > Author(s) : B. Carpenter, S. Jiang > > Filename : draft-carpenter-6man-flow-update-00.txt > > Pages : 9 > > Date : 2010-02-17 > > > > Various uses proposed for the IPv6 flow label are incompatible with > > its existing specification. This document describes changes to the > > specification that permit additional use cases as well as allowing > > continued use of the previous specification. > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-carpenter-6man-flow-update-0 > > 0.txt > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
