Regards
Brian Carpenter
On 2010-04-15 14:10, Shane Amante wrote:
> 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
I'm personally quite attracted by this. It does further damage
to the sacred principle that the flow label is immutable,
but maybe that is the inevitable result anyway.
Brian
> 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 they 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
--------------------------------------------------------------------
