> -----Original Message----- > From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On > Behalf Of Shane Amante > Sent: Thursday, April 15, 2010 10:11 AM > To: Brian E Carpenter > Cc: 6man > Subject: Re: [Fwd: New Version Notification > fordraft-carpenter-6man-flow-update-02] > > Brian, Mark, > > Brian: FWIW, I like the direction of this version of draft > much better than previous versions; however, I agree with > Remi that the current version is a bit confusing at the > moment and could likely be rewritten to be more simple and > just obsolete RFC 3967. In addition, I'm still a bit unclear > and, therefore, uncomfortable on the proposal with respect to > flow-labels within an "administratively defined domain". In > particular, if one administrative domain has set their own > "locally defined" flow-label, I think the draft could benefit > from a stronger emphasis that the flow-label MUST or, at > least, SHOULD be reset to 0 upon /leaving/ that domain, > otherwise the next domain may (or, will?) misinterpret the > meaning of the incoming "locally-defined" flow-label. The > way I interpret the text in Bullet 3 of Section 3 seems > written in a way that is specific to packets entering domains > that are going to use locally-defined flow-labels, but not > how they must treat those same packets as th ey leave their > domain and, most importantly, need to interact with other > domains that don't understand or want to use a "standard" > definition of a flow-label, i.e.: in Bullets 1, 2 & 4. Or, > perhaps I'm misunderstanding something.
Hi, Shane, I am fully with you. Actually, during our updating for 02 version, I talked with Brian, "whether we need a outbound router to set the router-modified flow label back to all-zero". By that time, we were considering the backwards compatible with RFC3976 "delivered the flow label unchanged". Therefore, we cannot change flow label on the outbound router because we cannot tell whether it is from hosts or routers. Now, we are talking about to obsolete 3967 totally, then reset flow label upon/leaving Flow Label domain would be quite reasonable. Cheers, Sheng > More below. > > On Apr 14, 2010, at 16:13 MDT, Brian E Carpenter wrote: > > Hi Mark, > > > > On 2010-04-15 09:59, Mark Smith wrote: > >> Hi Brian and Sheng, > >> > >> On Wed, 14 Apr 2010 16:48:25 +1200 > >> Brian E Carpenter <brian.e.carpen...@gmail.com> wrote: > >> > >>> Hi, > >>> > >>> This is completely revised from the proposal we presented in > >>> Anaheim. This version allows locally defined use of the > flow label > >>> in a simpler way, as the discussion suggested. > >>> It's still quite a dense read, but we believe that if this was > >>> adopted, it would open the way to actually using the flow label. > >>> > >> > >> I've had a read through it, although not a comprehensive > one, which > >> I'll endeavour to do in the next day or so. > >> > >> I'm wondering about this change for a couple of reasons: > >> > >> -- > >> 2. If this is done, all packets in a given flow MUST be > given the > >> same flow label value. A flow is defined in this case as all > >> packets with the same source and destination IPv6 > addresses and > >> port numbers and the same transport protocol number, > i.e., the > >> same final Next Header value [RFC2460]. This rule > constrains the > >> definition of a flow in RFC 3697 for the specific case that a > >> router sets the flow label. However, it does not > constrain the > >> bits of the flow label in any particular way. > >> -- > >> > >> Firstly, if the IPv6 packets are fragments, the transport layer > >> header may not be available. I think that would mean that although > >> these packets fragments are part of a flow, they wouldn't > have their > >> flow label changed. > > > > Yes, certainly, if the router inserting the flow label is stateless. > > I honestly don't see a way round that and it's probably > better to list > > it as a limitation. It probably doesn't matter - anyone who is > > deploying a local scheme for the flow label is presumably > able to also > > deploy a non-fragmenting network. > > Actually, one would hope that implementations are actually > "smart" about fragments. Specifically, one could look for a > Fragment Header and, upon noticing it, mask out or exclude > Layer-4 transport information, (e.g.: protocol, source and > destination port) as input keys for, say, LAG or ECMP. This > means one would only consider the 2-tuple of source and > destination IP address, which is better than nothing, but > more importantly would still preserve ordering. > > > >> Secondly, for IPv6 packets with a number of extension > headers before > >> the transport layer header, I think this rule could impact > forwarding > >> performance. While I'm not sure if it is that practical, > however it'd > >> be good if flow classification could be done using only > fixed headers > >> in the IPv6 packet, or a fixed portion of the fixed header bits. > > > > I will send a separate message on that point. > > I wholeheartedly agree with Mark's point. I would add that > IPv6 Extension Headers may not impact forwarding performance > on PE interfaces, because they are [somewhat] high-touch > interfaces that typically must be capable of imposing various > 2- or 5-, or 6-tuple[1] classifiers on PE-CE interfaces for > applying ACL's (forward/drop), policing/rate-limiting or > marking (IPv6 TC field) functions. *However*, the same is > not true of P routers, which generally have several dozen > bleeding edge interfaces of 40G and 100G and beyond. Thus, > allowing P routers to more quickly access input keys to a LAG > or ECMP hash function is pretty critical. > > [1] 6-tuple if you include Traffic Class. > > > >> I suppose partly that comes down to what a 'flow' is. In some > >> contexts, it is definitely a transport layer connection. > In others, > >> e.g. an MPLS network, I think it could be seen to be all > packets that > >> match a Forwarding Equivalence Class. If it was possible > to use a FEC > >> to set the flow label, once the packet has traversed the MPLS > >> network, and the MPLS labels are stripped off, the flow label that > >> was set due to the FEC would be preserved, which might be > useful. Is > >> there an opportunity to make the definition of a flow a bit more > >> general, and then for allow for the choice of different packet > >> classification methods to be used to define a flow, based > on context > >> e.g. transport layer connection in some contexts, MPLS > FEC, QoS/Diff Serv classifiers etc. in others? > > > > And that's an even wider question. I'm inclined to duck it, or at > > least to assert that it's a much wider question than 6man > can tackle. > > Let's not duck ... not yet, anyway. :-) > > With respect to MPLS, there is the following, now expired, > draft which might be what you're looking for: > http://tools.ietf.org/html/draft-kompella-mpls-entropy-label-00 > ... however, there are some challenges with it, namely > handling Penultimate Hop Popping (PHP), which isn't discussed > in the draft, plus the fact that legacy HW certainly most > likely will not support pushing additional labels required to > insert an entropy-label. If you're interested in this draft, > I suggest we take if offline and/or to the MPLS list. > > That said, I would hope the use of an MPLS entropy label > might be avoided for IP over MPLS traffic and, instead, a > simpler approach would be to use (even in MPLS networks) just > the following as input-keys to LAG or ECMP: > - IPv6 source address; > - IPv6 destination address; and, > - A _proper_ IPv6 flow-label that unambiguously identifies an > underlying "flow" > ... without needing to seek out Transport layer info. > > I believe it would be an implementation detail as to what > IPv6 header fields a vendor would allow to be included as > input-keys to a hash that would be calculated and put into a > IPv6 flow-label. Although, certainly I would hope we could > insist on a minimum of the 2-tuple and "recommend" that they > include the more valuable the 5- or 6-tuple as input-keys to > the hash algorithm for the flow-label. > > -shane > > > > > > > Brian > >> > >> Regards, > >> Mark. > >> > >> > >> > >> > >> > >> > >>> Brian and Sheng > >>> > >>> -------- Original Message -------- > >>> Subject: New Version Notification for > >>> draft-carpenter-6man-flow-update-02 > >>> Date: Tue, 13 Apr 2010 21:44:42 -0700 (PDT) > >>> From: IETF I-D Submission Tool <idsubmiss...@ietf.org> > >>> To: brian.e.carpen...@gmail.com > >>> CC: shengji...@huawei.com > >>> > >>> > >>> A new version of I-D, draft-carpenter-6man-flow-update-02.txt has > >>> been successfully submitted by Brian Carpenter and posted > to the IETF repository. > >>> > >>> Filename: draft-carpenter-6man-flow-update > >>> Revision: 02 > >>> Title: Update to the IPv6 flow label specification > >>> Creation_date: 2010-04-13 > >>> WG ID: Independent Submission > >>> Number_of_pages: 10 > >>> > >>> Abstract: > >>> 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. > >>> > >>> > >>> > >>> The IETF Secretariat. > >>> > >>> > >>> > >>> > -------------------------------------------------------------------- > >>> 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 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
