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