Re: [Roll] using the flow label instead of hop by hop

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Phil:

> [Pascal] Which  I'd suggest exemplifies what must not be done.  The SPI is an end-to-end information that is useless to the network. Thus is does not belong to the IPv6 header. I hope we are not discussing this are we?

I don't understand -- simply because fields are used end-to-end and "useless" to the network doesn't mean it shouldn't belong in the IPv6 header. For example, the protocol field in IPv4 (or next header in IPv6 denoting a transport header). Or the offset/MF in IPv4. 

[Pascal] let's talk about that over a drink. It has to do with architecture, but also with footprint. You can always add destination option space for end to end chat, but the space in the packet that the router can look at is definitely constrained, mostly to the header though for load balancing purposes the router sometimes looks deeper.

-----


 [Pascal] Now, if in some future we do need so save the flow label in order to echo it back to the source in an ICMP error, then we can carve a little room for 20 bits in the 6LoWPAN compression. But so far that need was not identified and/or cost-justified. So, no, I do not see that we need IP in IP when we use the flow label for the RPL information.

Pascal, I think the issue is really simple. IMHO, any reasonable interpretation of RFC6537 is that a flow label generated outside a RPL instance MUST be delivered unchanged to a node inside a RPL instance. Full stop. Applications and other protocols using IPv6 and reading RFC6537 might make this assumption: suddenly they might break working when they hit a RPL network.

I mean, please explain, in a single sentence, how the proposed use does not violate this statement:

"A forwarding node MUST either leave a non-zero flow label value unchanged or change it only for compelling operational security reasons as described in Section 6.1."

[Pascal] I'm modifying / adding the following text in the draft to amend 6437:

   In a LLN, each transmitted bit represents energy and every saving
   counts dearly.  Considering that the value for which the Flow Label
   is used in the IPv6 Flow Label Specification [RFC6437] is to serve
   load balancing in the core, it is unlikely that LLN devices will
   consume energy to generate and then transmit a Flow Label to serve
   interests in some other place.  On the other hand, it makes sense to
   recommend the computation of a stateless Flow Label at the root of
   the LLN towards the Internet.

   Reciprocally , [RFC6437] requires that once set, a non-zero flow
   label value is left unchanged.  The value for that setting is
   consumed once the packet has traversed the core and reaches the LLN.
   Then again, there is little value but a high cost for the LLN in
   spending 20 bits to transport a Flow Label from the Internet over the
   constrained network to the destination node.  It results that the
   MUST in [RFC6437] should be alleviated for packets coming from the
   outside on the LLN, and that it should be acceptable that the
   compression over the LLN erases the original flow label.  It should
   also be acceptable that the Flow Label field is reused in the LLN as
   proposed in this draft.

What do you think?


Basically, if 6man is willing to change the flow label specification such that nodes need to assume it might be changed along a route, then this seems like a reasonable use of the flow label. But to go against a prior specification (in a way that can break interoperability) for an as-of-yet-unsubstantiated optimization effort seems like poor engineering to me.

[Pascal] You'll note that 6550 has externalized the location of the RPL information to other drafts and thus 6550 is not changed. 
But really, the point is that the actual standards that get deployed are not 6LoWPAN or RPL. 
They are the likes of ZigBee IP, ISA100.11a, WiHART, etc... which mandate a list of RFC and then come with interop testing (HCF, WCI).
As it goes, the industrial standards did not pick the larger frames from 802.15.4G, and RPL cannot succeed there with the HbH option and the IP in IP encapsulation. Simple as that.

Cheers,

Pascal