> -----Original Message----- > From: Mark Smith > [mailto:i...@69706e6720323030352d30312d31340a.nosense.org] > Sent: Monday, February 22, 2010 5:22 PM > To: Sheng Jiang > Cc: 'Brian E Carpenter'; '6man' > Subject: Re: [Fwd: I-D Action:draft-carpenter-6man-flow-update-00.txt] > > Hi Sheng, > > > On Mon, 22 Feb 2010 11:15:52 +0800 > Sheng Jiang <shengji...@huawei.com> wrote: > > > > > 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). > > I was thinking more of the situation where the egress router > does know that the adjacent domain is a flow domain, and > therefore is configured to change the flow value to another > MSB=1 value or leave it alone if the original MSB=1 value > matches the configured outgoing MSB=1 value.
Right. > If there is no new configured outbound MSB=1 value, then I > think it is better to set the flow value to MSB=0/all bits > zero, indicating that the packet has left the prior flow > domain, and that the egress router does not have any > knowledge of any subsequent flow domains or their flow domain values. Not sure here. All 0 bits mean killing the possibility the second flow domain uses local defined behavior. It seems not right. > > 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. > > > > I think leaking them could be, if there are equivalent flow > values in the subsequent flow domain which have different meanings. All right. The leaking of locally defined behaviors may cause confusing meanings. Then, the egress router should prevent the exporting of local defined behaviours. Cheers, Sheng > Regards, > Mark. > > > 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 --------------------------------------------------------------------
