Re: [Roll] [6man] #7 (draft-thubert-6man-flow-label-for-rpl): draft-thubert-6man-flow-label-for-rpl-03 Relation with RFC 6294

["6man issue tracker" <[e-mail]>]

#7: draft-thubert-6man-flow-label-for-rpl-03 Relation with RFC 6294


Comment (by [e-mail]):

 From: Adrian Farrel Date: 2014-08-05 17:07 GMT+03:00


 “In as much as this I-D diverges from the statements in the IETF consensus
 document RFC 6294, I will have a relatively high bar for the demonstration
 of consensus on this document.



 I understand that RPL runs in a walled garden. In particular, while there
 may be control flows from outside the RPL network to inside it, those
 flows *currently* run through an intermediate application (such as a
 server). I also understand that in the future, when flows run direct
 between external and internal nodes they will still run through a gateway
 router. In the former case the flow label is terminated at the server and
 so we can safely describe the RPL network as a walled garden. In the
 latter case, however, it is not possible for the flow label to be
 preserved end-to-end, and the gateway router must impose a flow label on
 outgoing packets, while the flow label delivered to an end device will be
 meaningless.



 In order that this document be successful one of two things is going to be
 needed.

 1. A clear statement that packets from within a RPL network that use the
 RPL flow label MUST NOT flow out of the RPL network, together with an
 explanation of how this is policed and guaranteed. More precisely: how
 will a router in the Internet know that the flow label on a packet was not
 applied by the source host?

 2. A change to the flow label architecture has to be considered acceptable
 by the IETF community. It needs to be written up clearly stating that it
 is OK for a gateway router to proxy the source host and insert a flow
 label, how the gateway router determines what value to set, and why it
 will not matter to a receiving RPL host that the flow label has been lost.

 Furthermore, I think some consideration of end-to-end traffic that
 transits a RPL network may be needed.



 I don't believe that any of that should be presented as an Update to 6294.
 Rather, I think that this document needs to be completely clear *and* a
 new revision of 6294 will be required with the associated changes.



 Of course, an answer to all this would by IPv6-in-IPv6 encapsulation, but
 I doubt that that is considered acceptable in a world that is so short of
 bits.



 Cheers,
 Adrian

-- 
-------------------------------------------------+-------------------------
 Reporter:  [e-mail]            |       Owner:
     Type:  defect                               |  [e-mail]
 Priority:  major                                |      Status:  new
Component:  draft-thubert-6man-flow-label-for-   |   Milestone:
  rpl                                            |     Version:
 Severity:  In WG Last Call                      |  Resolution:
 Keywords:                                       |
-------------------------------------------------+-------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/6man/trac/ticket/7#comment:1>
6man <http://tools.ietf.org/wg/6man/>