Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03

[Ray Hunter <[e-mail]>]

> Brian E Carpenter <mailto:[e-mail]>
> 17 August 2014 21:58
> On 17/08/2014 21:52, Ray Hunter wrote:
>>> Brian E Carpenter<mailto:[e-mail]>
>>> 16 August 2014 21:55
>>> Ray,
>>>
>>> On 16/08/2014 18:49, Ray Hunter wrote:
>>>>> Philip Levis<mailto:[e-mail]>
>>>>> 16 August 2014 02:33
>>>>>
>>>>> 1) There is an extension header already; the problem is that it can
>>>>> introduce a significant (ballpark estimates are, in well engineered
>>>>> networks, up to 5-10%) cost. The proposal is to replace the extension
>>>>> header with using the flow label.
>>>>>
>>>>> 2) There'a already significant IP header compression in the cases
>>>>> we're talking about.
>>>>>
>>>>> Phil
>>>> I'm sympathetic to the needs of low power devices.
>>>>
>>>> However, to be clear, we are reengineering a standards track document
>>>> that is around 2 years old (http://tools.ietf.org/html/rfc6553), and
>>>> which works technically, and we are proposing an additional encoding of
>>>> exactly the same information to achieve theoretical efficiency gains
>>>> that are still only rough estimates?
>>>>
>>>> Where's the experimental proof that this will really pay off in
>>>> increased battery life?
>>>>
>>>> You write "replace". Will 6553 now be deprecated?
>>>>
>>>> If not we'll have:
>>>>
>>>> 6553 to carry RPL information as an option header.
>>>>
>>>> draft-thubert-6man-flow-label-for-rpl-03 to carry RPL information as a
>>>> flow label
>>>>
>>>> flow label information used to select patch and load balancing in
>>>> multi-path networks. e.g.
>>>> http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=5349203&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D5349203
>>>>
>>>>
>>>> http://tools.ietf.org/html/rfc6438
>>>> http://tools.ietf.org/html/rfc7098
>>>>
>>>> I do not see that these applications for this one field are mutually
>>>> compatible, and worse still, the only way to decode the semantics of the
>>>> overloaded field is by applying some unknown external context ("within
>>>> RPL domain"/ "on the Internet").
>>> No, I don't see a problem there. The boundary of a RPL domain is
>>> very well defined and flow-label-for-rpl clearly specifies that
>>> outside that boundary, RFC 6437 applies (which enables RFC 6438
>>> and 7098).
>> But inside an RPL domain, you cannot use any RFC's that reference the
>> flow label as per 6437, because all of the entropy has gone.
>
> Correct. But isn't that a trade-off that might be reasonable in
> the low-power lossy environment? (That's not intended as a rhetorical
> question - I just don't have enough knowledge of that environment
> to answer it.)
I would prefer to avoid making the trade off if we don't have to. Who 
knows what future application will use the flow label?

I'm no RPL expert, but 
http://tools.ietf.org/html/draft-bormann-6lo-rpl-mesh-01 seems more 
elegant and avoids all of this discussion.
>> And what happened to our end to end architecture?
>
> There are various views of what e2e means, but I still like the
> phrase "certain required end-to-end functions can only be performed
> correctly by the end-systems themselves". Load balancing and adaptive
> routing are not actually e2e functions in that sense.
>
>> I just do not like the concept of parsing a packet, and then having to
>> determine the semantics of the contents of a particular field based on a
>> "domain" that is not carried anywhere in the packet.
>
> I see the objection, but we've been doing it for years; diffserv does
> it by definition.
>
>     Brian
Agreed. But that is also largely being overtaken by MPLS Traffic 
Engineering, precisely so you can have an extensible label stack, or 
nest QoS domains, whilst still easily accessing the required label info 
at all points along the forwarding path.
>> e.g. think about decoding offline captures
>
>>>> The hidden "cost" here is that we will have 3 different overlapping
>>>> solutions = code bloat and potentially a lot of additional processing to
>>>> locate the correct information and then process it, which is also a hit
>>>> on energy efficiency.
>>>>
>>>> IMHO the bar should be pretty high for accepting this proposal, as it is
>>>> not actually solving a tangible issue.
>>> Whether ROLL wants to endorse alternative methods within RPL
>>> domains is not a 6man question.
>>>> Also my prediction of the next request for field overloading will be:
>>>> My ISP only delegates one /64 with PD
>>>> I have multiple links in my Homenet
>>>> All my media is EUI48 based. No one really uses EUI64.
>>>> I want to rewrite the 16 spare bits in SLAAC ("FF:FE") and use this for
>>>> routing in Homenet by encoding a (V)LAN ID in it.
>>>> It's OK though. Homenet is a walled garden and I'll rewrite the field at
>>>> the exit so no one will ever know.
>>> Nice strawman, but why is it relevant? There's no need to rewrite
>>> the bits, BTW. As RFC 7136 says:
>>> "However, the method of generating IIDs for specific link types MAY
>>> define some local significance for certain bits... the whole IID value
>>> MUST be viewed as an opaque bit string by third parties, except possibly
>>> in the local context."
>>>
>>>      Brian
>>>
>>>> As an alternative: if this information is really RPL specific, why not
>>>> just add the RPL Information as a tag to the front of the packet e.g.
>>>> via an MPLS label?
>>>>
>>>> MPLS labels are only 4 octets, and are designed to be very efficient and
>>>> fast.
>>>> You can easily strip them at egress, and munge it/set it on ingress.
>>>> It's clear where an MPLS domain ends and starts: no chance of RPL
>>>> information leaking onto the Internet, or entering from the Internet.
>>>> The MPLS label also transports the 20 bits of information you need.
>>>> MPLS labels are at a clear fixed position in the packet and are easy and
>>>> efficient to parse.
>>>> You could also then nest RPL domains if you ever wanted to do that.
>>>> It's also extensible, as you can push more labels on the stack in the
>>>> future if you ever want to extend the RPL Information transported,
>>>> whereas the flow label is a single fixed field.
>>>> It does not require any new standard, except maybe an informational RFC
>>>> on how to encode the RPL Information into MPLS labels.
>>>> And it doesn't overload anything.
>>>>
>>>> regards,
>>>>
>>>>> Ray Hunter<mailto:[e-mail]>
>>>>> 15 August 2014 21:49
>>>>>
>>>>>
>>>>>
>>>>> +1
>>>>>
>>>>> Apologies for tardy response (holidays)
>>>>>
>>>>> After reading the draft it seems to me that what is being attempted is
>>>>> 1) to add some stuff to the IPv6 header that is RPL domain specific
>>>>> 2) to reduce the overall packet length to reduce active radio time and
>>>>> thus save energy
>>>>> by
>>>>> 3) overloading an existing well-defined and used IPv6 header field
>>>>>
>>>>> My simple logic tells me that
>>>>> 1) could be best solved at an architecture level via an extension
>>>>> header http://tools.ietf.org/html/rfc2460#page-11 +
>>>>> http://tools.ietf.org/html/rfc7045
>>>>> 2) could be best solved at an architecture level via IP header
>>>>> compression http://tools.ietf.org/html/rfc2507.html with or without
>>>>> additional tweaks
>>>>> and that overloading an opaque field in 3) by incorporating values
>>>>> with low entropy (as per the RPL flow label) gives additional security
>>>>> risks to http://tools.ietf.org/html/rfc7098
>>>>>
>>>>> So what's wrong with my simple logic?
>>>>>
>>>>> "But if we consider the whole RPL domain as a large virtual host from
>>>>> the standpoint of the rest of the Internet" would suggest to me that
>>>>> the cost of stripping out the additional IPv6 hop by hop extension
>>>>> header at the edge of the domain is a bogus argument, as you'll anyway
>>>>> have to provide some adaption and security at the root of each RPL
>>>>> domain to detect and bounce spoofed RPL Information from entering, or
>>>>> private RPL Information leaking out of each domain. Whether this
>>>>> domain-specificRPL Information is encoded in an explicit hop by hop
>>>>> option or an overloaded flow label would seem largely irrelevant to
>>>>> that operation at the RPL root (especially since the RPL root anyway
>>>>> has to be a high power node to be able communicate with the rest of
>>>>> the Internet).
>>>>>
>>>>> IMHO If you overload the flow label you're looking at creating an
>>>>> incompatible walled garden, with competing IETF standards that are
>>>>> mutually exclusive.
>>>>>
>>>>> ------------------------------------------------------------------------
>>>>>
>>> ------------------------------------------------------------------------
>

-- 
Regards,
RayH