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