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