On 2010-02-21 01:58, Mark Smith wrote: > Hi Brian, > > On Thu, 18 Feb 2010 16:34:05 +1300 > Brian E Carpenter <brian.e.carpen...@gmail.com> wrote: > >> Hi, >> >> 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, that's worth thinking about. It would be unfortunate if the second domain is forbidden from using a local scheme if the first domain already did so. Brian > > > > > >> 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-00.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 --------------------------------------------------------------------
