Subject: [Roll] FW: New Version Notification for draft-thubert-6man-flow-label-for-rpl-02.txt

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 13 May 2014 09:26:16 +0000

Dear all:

This new version addresses Brian's concerns, in particular the language that relates this proposal with the Flow Label Specification (RFC 6437).
It is made clearer that this is a deviation such as already tolerated for security reasons, and that the compelling reason is energy saving.
The proposal only impacts the use of the flow label inside the LLN and does not result in a deterioration of the application of RFC 6437 inside the Internet. 
The proposal is supported by individuals participating to LLN related groups at the IETF (cc'ed) and external SDOs (ISA100).

The question is now whether we should complete the work at 6MAN or move back to ROLL.

What do you think?

Pascal

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: mardi 13 mai 2014 11:19
To: Pascal Thubert (pthubert); Pascal Thubert (pthubert)
Subject: New Version Notification for draft-thubert-6man-flow-label-for-rpl-02.txt

A new version of I-D, draft-thubert-6man-flow-label-for-rpl-02.txt
has been successfully submitted by Pascal Thubert and posted to the IETF repository.

Name:		draft-thubert-6man-flow-label-for-rpl
Revision:	02
Title:		The IPv6 Flow Label within a RPL domain
Document date:	2014-05-13
Group:		Individual Submission
Pages:		11
URL:            http://www.ietf.org/internet-drafts/draft-thubert-6man-flow-label-for-rpl-02.txt
Status:         https://datatracker.ietf.org/doc/draft-thubert-6man-flow-label-for-rpl/
Htmlized:       http://tools.ietf.org/html/draft-thubert-6man-flow-label-for-rpl-02
Diff:           http://www.ietf.org/rfcdiff?url2=draft-thubert-6man-flow-label-for-rpl-02

Abstract:
   This document present how the Flow Label can be used inside a RPL
   domain as a replacement to the RPL option and provides rules for the
   root to set and reset the Flow Label when forwarding between the
   inside of RPL domain and the larger Internet, in both direction.
   This new operation saves 44 bits in each frame, and an eventual IP-
   in-IP encapsulation within the RPL domain that is required for all
   packets that reach outside of the RPL domain.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 16 May 2014 13:39:48 +1200

> The proposal is supported by individuals participating to LLN related groups at the IETF (cc'ed) and external SDOs (ISA100).

I'm happy with the new Applicability section. However, there is an editing
problem with the first sentence of its final paragraph (some words need to
be deleted, I suspect).

> The question is now whether we should complete the work at 6MAN or move back to ROLL.

IMHO, since this does not formally update a 6man document, I don't think
it's required to be processed by 6man - but a special WGLC in 6man would be
reasonable in any case, to avoid unexpected issues at IETF Last Call.
However, that's only one person's opinion.

Since 6man is not meeting in Toronto, please let us know if the draft
will be discussed elsewhere.

    Brian

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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 20 May 2014 05:49:58 +0000

Thanks a bunch Brian!

Since this changes a MAY NOT in a MUST NOT, I published an 03.

The text is now:

   This specification also allows that regardless of its original
   setting, a root of a RPL domain MAY set the Flow Label of IPv6
   packets that exit the RPL domain in a manner that SHOULD conform to
   the prescriptions in [RFC6437].  Therefore a source in the RPL domain
   MUST NOT assume that its setting of the Flow Label be preserved end-
   to-end.  From there, the capability by RPL routers inside the LLN to
   alter a non-zero Flow Label between the source and the root is
   another minor deviation to [RFC6437] that is also acceptable since it
   is transparent to the core of the Internet.

Again, many thanks.

I'll follow up with the chairs about the idea of a special WGLC in 6man.

Pascal

> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: vendredi 16 mai 2014 03:40
> To: Pascal Thubert (pthubert)
> Cc: [email-masked]; roll; [email-masked]; Pat Kinney
> Subject: Re: FW: New Version Notification for draft-thubert-6man-flow-label-
> for-rpl-02.txt
> 
> > This new version addresses Brian's concerns, in particular the language
> that relates this proposal with the Flow Label Specification (RFC 6437).
> > It is made clearer that this is a deviation such as already tolerated for
> security reasons, and that the compelling reason is energy saving.
> > The proposal only impacts the use of the flow label inside the LLN and
> does not result in a deterioration of the application of RFC 6437 inside the
> Internet.
> > The proposal is supported by individuals participating to LLN related
> groups at the IETF (cc'ed) and external SDOs (ISA100).
> 
> it's required to be processed by 6man - but a special WGLC in 6man would
> be reasonable in any case, to avoid unexpected issues at IETF Last Call.
> Since 6man is not meeting in Toronto, please let us know if the draft will be
> discussed elsewhere.
> 
>     Brian
> 
> >
> > Pascal
> >
> >
> > Subject: New Version Notification for
> > draft-thubert-6man-flow-label-for-rpl-02.txt
> >
> >
> > Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at tools.ietf.org.
> >
> > The IETF Secretariat
> >