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