Subject: Re: [Fwd: I-D Action:draft-carpenter-6man-flow-update-00.txt]

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 14 Apr 2010 19:21:05 +0200

Hi, I came across this draft coming from the ROLL space where a proposal
exists to use the Flow Label changed enroute maybe.

Besides the fact that I find ROLL use of such spec of 6MAN not being
ready, i.e. in its infance (I will suggest that to the ROLL WG), I have
a general comment here in 6MAN.

Modifying a field of an IP packet "en-route" is something which comes
with a price tag: obviously slower.  Generally speaking writing takes
much longer than reading.

I find this proposal to change the Flow Label behaviour to come in too
early, at a point where we don't yet have widespread use of simple Flow
Labels (or is it widely used?).

I wouldn't touch on any IP field enroute...  there exist already
exceptions allowing to touch enroute and they're not widely used either
(RH, HbH, etc.)

Alex

Le 18/02/2010 04:34, Brian E Carpenter a écrit :
> Hi,
>
> This may seem a bit unexpected, but after working on
> draft-carpenter-flow-ecmp (just updated) and working with my student
> Qinwen Hu on some aspects of the flow label, it seemed like time for
> another look at the flow label standard, and Sheng Jiang was having
> similar thoughts.
>
> We'd like to discuss this in Anaheim if possible.
>
> Brian
>
> -------- Original Message -------- Subject: I-D
> Action:draft-carpenter-6man-flow-update-00.txt Date: Wed, 17 Feb
> 2010 18:15:02 -0800 (PST) From: [email-masked] Reply-To:
> [email-masked] To: [email-masked]
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
> Title           : Update to the IPv6 flow label specification
> Author(s)       : B. Carpenter, S. Jiang Filename        :
> draft-carpenter-6man-flow-update-00.txt Pages           : 9 Date :
> 2010-02-17
>
> 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.
>
> A URL for this Internet-Draft is:
>
http://www.ietf.org/internet-drafts/draft-carpenter-6man-flow-update-00.txt
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list [email-masked] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 14 Apr 2010 19:41:09 +0200

I take advantage of my slot here to also talk about the fact that I
believe Flow Labels and IPv6 Flows in general are little known in MEXT.

For example the MEXT WG defines an "IPv6 flow" to be a "group of packets
matching a traffic selector", different than the rfc3697 idea of
"3-tuple of the Flow Label and the Source and Destination Address fields
enables efficient IPv6 flow classification".

MEXT's draft-ietf-mext-flow-binding-06 goes further and defines "A flow
identifier uniquely identifies a flow binding associated with a mobile
node.  It is generated by a mobile node and is cached in the table of
flow binding entries maintained by the MN, HA, CN or MAP.".

No MEXT mentioning of "Flow Label", but the same spirit - because a flow
binding is actually a pair of addresses to which one adds an 16bit (not
20) id.

MEXT Mobile IPv6 using the _spirit_ of IPv6 flows (3-tuple
address-address-id), and the term "flow" but _not_ the IPv6 Flow Label
field was very surprising to me at the time of proposal.

Now I am surprised 6MAN proposes to modify the IPv6 Flow Label - what
does this mean to MEXT Mobile IPv6?  Is 6MAN proposing new Flow Label
behaviour in order to be better in MEXT (doesn't seem so, mutability
wasn't requested in MEXT)?  Or just ROLL?

For whom is this Flow Label update intended?

Alex

Le 14/04/2010 19:21, Alexandru Petrescu a écrit :
> Hi, I came across this draft coming from the ROLL space where a
> proposal exists to use the Flow Label changed enroute maybe.
>
> ready, i.e. in its infance (I will suggest that to the ROLL WG), I
> have a general comment here in 6MAN.
>
> Modifying a field of an IP packet "en-route" is something which
> comes with a price tag: obviously slower. Generally speaking writing
> takes much longer than reading.
>
> I find this proposal to change the Flow Label behaviour to come in
> too early, at a point where we don't yet have widespread use of
> simple Flow Labels (or is it widely used?).
>
> exceptions allowing to touch enroute and they're not widely used
> either (RH, HbH, etc.)
>
> Alex
>
>> draft-carpenter-flow-ecmp (just updated) and working with my
>> student Qinwen Hu on some aspects of the flow label, it seemed like
>> time for another look at the flow label standard, and Sheng Jiang
>> was having similar thoughts.
>>
>> Title : Update to the IPv6 flow label specification Author(s) : B.
>>  Carpenter, S. Jiang Filename :
>> 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.
>>

---

From: Philip Levis <[email-masked]>
Date: Wed, 14 Apr 2010 13:23:05 -0700

> exists to use the Flow Label changed enroute maybe.

Alex,

I think you're misrepresenting ROLL here, even though (after your objections there) the use of the flow label was very clearly described a few days ago. Changing the flow label enroute is not on the table in ROLL; it was a while ago as a crazy idea, then everyone realized the issues it would create. 

Phil

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 15 Apr 2010 09:45:30 +1200

> For whom is this Flow Label update intended? 

1. For all the people who have proposed use cases that are incompatible
with RFC 3697. This is briefly discussed in the draft, and I plan
another draft with more details about that.

2. To "unlock" the uses cases already proposed that are compatible with
RFC 3697 (draft-blake-ipv6-flow-label-nonce, ECMP, and LAG).

I haven't tracked MEXT at all. If they want to place requirements
on the flow label, now would be a good time for them to tell 6man.

Regards
   Brian

On 2010-04-15 05:41, Alexandru Petrescu wrote:
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 15 Apr 2010 09:51:08 +1200

Alexandru,

> Labels (or is it widely used?). 

But that's the problem. If you have read the -02 draft, you will understand
that flow label usage today is essentially non-existent. Usage is not going to
occur unless we make it desirable - and it's quite clear that RFC 3697 did
not succeed in making it desirable. So either we do something, or we continue
to carry 20 useless bits in every IPv6 packet.

Please forget the -00 and -01 drafts, they were completely overtaken by
the discussion at IETF77.

Regards
   Brian

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 15 Apr 2010 00:32:42 +0200

Le 14/04/2010 22:23, Philip Levis a écrit :
> I think you're misrepresenting ROLL here, even though (after your
> objections there) the use of the flow label was very clearly
> described a few days ago. Changing the flow label enroute is not on
> the table in ROLL; it was a while ago as a crazy idea, then everyone
> realized the issues it would create.

Sorry for misunderstanding...

(only a day ago it was stated in ROLL list that changing the flow label
  enroute is possible as long as it is restored...)

I guess I have to wait and see.

Alex

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 14 Apr 2010 16:22:35 -0700 (PDT)

Using RFC 3697 instead of Traffic Selectors (draft-ietf-mext-binary-ts) has been discussed in MEXT, here is a pointer:
http://www.ietf.org/mail-archive/web/mext/current/msg03327.html

I don't think MEXT opted for that kind of use, they want more generic flow description.

BR,

Behcet

----- Original Message ----
> From: Brian E Carpenter <[email-masked]>
> To: Alexandru Petrescu <[email-masked]>
> Cc: [email-masked]
> Sent: Wed, April 14, 2010 4:45:30 PM
> Subject: Re: IPv6 Flows, Mobile IPv6 Flows, ROLL RPL Flows
> 

1. For all the people 
> who have proposed use cases that are incompatible
with RFC 3697. This is 
> briefly discussed in the draft, and I plan
another draft with more details 
> about that.

2. To "unlock" the uses cases already proposed that are 
> compatible with
RFC 3697 (draft-blake-ipv6-flow-label-nonce, ECMP, and 
> LAG).

I haven't tracked MEXT at all. If they want to place 
> requirements
on the flow label, now would be a good time for them to tell 
> 6man.

Regards
  Brian

On 2010-04-15 05:41, Alexandru 
> Petrescu wrote:
> binding is actually a pair of 
> addresses to which one adds an 16bit (not
> 20) id.
> 
> MEXT 
> Mobile IPv6 using the _spirit_ of IPv6 flows (3-tuple
> 
> Now I 
> am surprised 6MAN proposes to modify the IPv6 Flow Label - what
> does 
> this mean to MEXT Mobile IPv6?  Is 6MAN proposing new Flow Label
> 
>> Besides the fact that I 
> find ROLL use of such spec of 6MAN not being
>> ready, i.e. in its 
> infance (I will suggest that to the ROLL WG), I
>> have a general 
> comment here in 6MAN.
>>
>>> 2010 18:15:02 -0800 (PST) From: > ymailto="mailto:[email-masked]" 
> href="mailto:[email-masked]">[email-masked] 
> Reply-To:
>>> > href="mailto:[email-masked]">[email-masked] To: > ymailto="mailto:[email-masked]" 
> href="mailto:[email-masked]">[email-masked]
>>>
>>> 
> IETF IPv6 working group mailing list > href="mailto:[email-masked]">[email-masked] Administrative
>>> 
> Requests: > >https://www.ietf.org/mailman/listinfo/ipv6
>>> 
> IETF IPv6 working group mailing list > href="mailto:[email-masked]">[email-masked] Administrative
>> 
> Requests: > >https://www.ietf.org/mailman/listinfo/ipv6
>> 
> > href="mailto:[email-masked]">[email-masked]
> Administrative Requests: 
> > >https://www.ietf.org/mailman/listinfo/ipv6
> 

IETF 
> IPv6 working group mailing list
> href="mailto:[email-masked]">[email-masked]
Administrative Requests: > href="https://www.ietf.org/mailman/listinfo/ipv6" target=_blank 
> >https://www.ietf.org/mailman/listinfo/ipv6

---

From: Philip Levis <[email-masked]>
Date: Wed, 14 Apr 2010 20:18:37 -0700

> enroute is possible as long as it is restored...)

Sure, it's possible, that doesn't mean RPL is going to do it. Doing so requires having somewhere in the packet to store the original value, which necessitates a header; if there's a header, there's no point in changing the flow label. It's my understanding there are some proposals out there for doing this, but in other domains -- this was mentioned at the mike in Hiroshima -- but that by no means indicates RPL will.

Phil

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 15 Apr 2010 11:14:31 +0200

Le 14/04/2010 23:51, Brian E Carpenter a écrit :
> But that's the problem. If you have read the -02 draft, you will
> understand that flow label usage today is essentially non-existent.

Ok, it is draft-carpenter-6man-flow-update-02 and I will comment on it
separately.

> Usage is not going to occur unless we make it desirable - and it's
> quite clear that RFC 3697 did not succeed in making it desirable. So
> either we do something, or we continue to carry 20 useless bits in
> every IPv6 packet.

I mainly agree to make Flow Labels desirable.  Towards that end one
would consider two other cases where Flow Labels were considered:

- MEXT' WG draft-ietf-mext-flow-binding-06 "Flow Bindings in Mobile
   IPv6 and NEMO Basic Support";
- ROLL WG's intention of use of Flow Labels in RPL
   protocol  draft-ietf-roll-rpl-07.

Currently their way of considering flows and Flow Labels respectively is
incoherent with old Flow Labels - and with new Flow Labels too.  Or
probably are they about to get in synch(?).

Why has MEXT WG defined a new flow id instead of reusing the IPv6 Flow
Label?  Is it because of security?  The new 6MAN Flow Labels don't
improve on security, they're still uncovered by IPsec.

Why has ROLL WG looked at mutable Flow Labels?  Is it to change it
enroute and restore it when getting out of the flow label domain?  The
new flow labels don't seem to impose the restoration, in my reading.

Are the new Flow Labels better adapted to MEXT and to ROLL?

Alex

>
> Please forget the -00 and -01 drafts, they were completely overtaken
> by the discussion at IETF77.
>
> Regards Brian
>
>> Besides the fact that I find ROLL use of such spec of 6MAN not
>> being ready, i.e. in its infance (I will suggest that to the ROLL
>> WG), I have a general comment here in 6MAN.
>>
>> comes with a price tag: obviously slower.  Generally speaking
>> writing takes much longer than reading.
>>
>>> student Qinwen Hu on some aspects of the flow label, it seemed
>>> like time for another look at the flow label standard, and Sheng
>>> Jiang was having similar thoughts.
>>>
>>>  2010 18:15:02 -0800 (PST) From: [email-masked]
>>> Reply-To: [email-masked] To: [email-masked]
>>>
>>> A New Internet-Draft is available from the on-line
>>> Internet-Drafts directories.
>>>
>>> draft-carpenter-6man-flow-update-00.txt Pages           : 9 Date
>>> : 2010-02-17
>>>
>>> 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.
>>>

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 15 Apr 2010 11:19:12 +0200

Le 15/04/2010 05:18, Philip Levis a écrit :
>>> described a few days ago. Changing the flow label enroute is not
>>> on the table in ROLL; it was a while ago as a crazy idea, then
>>> everyone realized the issues it would create.
>>
>> (only a day ago it was stated in ROLL list that changing the flow
>> label enroute is possible as long as it is restored...)
>
> Sure, it's possible, that doesn't mean RPL is going to do it. Doing
> so requires having somewhere in the packet to store the original
> value, which necessitates a header; if there's a header, there's no
> point in changing the flow label. It's my understanding there are
> some proposals out there for doing this, but in other domains --
> this was mentioned at the mike in Hiroshima -- but that by no means
> indicates RPL will.

Ok, this is a discussion about intentions.  I am not aware of the
discussions in Hiroshima and intentions of future text, thanks for
having clarified this.

The current text in the RPL 07 draft says bit O oh of Flow Label set to
0 zero by Host and reset and set again by several intermediary routers.
  I guess this text will change.

Alex

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 16 Apr 2010 10:24:42 +1200

Below...

> Are the new Flow Labels better adapted to MEXT and to ROLL?

Well, if we get to a stable proposal here, we cn ask them
exactly that.

   Brian