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. 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. > 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. 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 --------------------------------------------------------------------
