> -----Original Message----- > From: Mark Smith > [mailto:i...@69706e6720323030352d30312d31340a.nosense.org] > Sent: Tuesday, February 23, 2010 5:22 AM > To: Brian E Carpenter > Cc: Sheng Jiang; '6man' > Subject: Re: [Fwd: I-D Action:draft-carpenter-6man-flow-update-00.txt] > > Hi Brian, > > On Tue, 23 Feb 2010 09:46:50 +1300 > Brian E Carpenter <brian.e.carpen...@gmail.com> wrote: > > > On 2010-02-22 22:22, Mark Smith wrote: > > > 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. > > > > Yes, so you send them on with MSB = 1 (local usage allowed) > but with > > the other bits zero (local usage not set). > > > > I'll re-read the draft again tonight to check my thinking, > however this is how I've been seeing the possible values
The possible values is one thing the others does not sure and want to discuss in 6man mail list. In the current 00 version, MSB=0 is to obey the rules of [RFC3697]. It means the in-path routers cannot do anything in the current all zero situation, which has overwhelming proportion now. It means when hosts do not use the flow label, the other can NOT use it too! That's actually, in my opinion what we should change. In we can agreed all zero should be possible for using local defined behaviors, there are two solutions: A: MSB 0, the remaining 19 bits is allowed for Flow Label Domain usage. B: Like Mark proposed, make all 0 outstanding value Discussion are appreciated. Regards, Sheng > o 0x00000 - unknown/undefined and of no flow domain > significance, covering the common case today > > 0 0x00001 through 0x7ffff - end-to-end significance, so > routers should not change the value, regardless of whether > flow domains exist or not > > 0 0x80000 through 0xfffff - local flow domain significance, > can be changed by a flow domain egress or ingres router. If > the router does not know of a new next (egress) or current > flow domain (ingres) value, it resets the flow value to > 0x00000. Otherwise, the flow value is set to an appropriate > new or current flow domain's MSB=1 value. I think this later > option of modifying the value from a previous MSB=1 value to > a new one is the only difference between what I've been > thinking and what is in the draft. > > Regards, > Mark. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
