Re: [Roll] [6lo] call for consensus for the RPL RPI / RH3 compression

(Adding 6man because of architecture issues)

On Jan 6, 2015, at 1:22 AM 1/6/15, Pascal Thubert (pthubert) <pthubert@cisco.com> wrote:

> Hello Ralph 
> 
> You certainly got it all right.
> 
> To your question we started through the NHC and found that path less efficient than Laurent's initial suggestion to place all the LLN routing artifacts in a different header/dispatch whatever the correct term is for that object.
> 
> One additional concern that doesn't show in your mail is the need for IP encapsulation when the artifacts are added by a router on the way or must be removed at LLN egress. By leaving the original IPv6 packet intact we simplify that matter and optimize the overall result by providing an improved compression for the outter header.

Yeah, I noticed the issue of IP encap hasn't been addressed (if I recall correctly) in draft-thubert-6lo-rpl-nhc...

But ... in my opinion, moving the LLN artifacts to the header/dispatch in the way defined in draft-thubert-6lo-routing-dispatch raises, implicitly, an important architectural issue: is the information in the dispatch header compressed IPv6 headers or headers for an independent, sub-IP protocol?

My understanding is that the IETF has made an architectural decision to do all the mesh network forwarding and routing in IPv6, so as to reuse as much as possible existing technology and associated infrastructure such as OAM.  If the dispatch header does not contain compressed IPv6 headers, per se, then this architectural question would lead me to investigate the completeness of the new protocol and the impacts of the new protocol on IPv6 and network operations.  

> 
> The new proposal also reopens the dispatch space (1/3 of the total) that is used is mesh under for mesh header, so it can also be use AND extended as TLV in route over.

There are both architectural and pragmatic issues in the design of the RPL-in-dispatch protocol.

The upcoming bakeoff might be a way to stimulate some running code that would check out all the potential impacts of moving the RPL information to a sub-IP protocol.

- Ralph

> 
> Makes sense?
> 
> Pascal
> 
>> Le 5 janv. 2015 à 23:29, Ralph Droms <rdroms.ietf@gmail.com> a écrit :
>> 
>> Do I have it right that:
>> 
>> 1) draft-thubert-roll-flow-label-02 compresses RPL RPI but not RH3
>> 2) draft-thubert-6lo-rpl-nhc-02 compresses RPL RPI and might be extended to compress RH3
>> 3) draft-thubert-6lo-routing-dispatch-01 compresses both RPL RPI and RH3
>> 
>> In discussion during the IETF-91 6lo working group meeting, a concern was raised about further consumption of NHC codepoints beyond what is defined in draft-thubert-6lo-rpl-nhc-02 for a future RH3 compression scheme.
>> 
>> Pascal, Carsten - as you have devised a mechanism for RH3 compression in draft-thubert-6lo-routing-dispatch-01, would you be able to retrofit a version of that mechanism into draft-thubert-6lo-rpl-nhc-02?  This extension to NHC compression would provide an explicit proposal for evaluation of RPL header compression in NHC.
>> 
>> - Ralph
>> 
>> _______________________________________________
>> Roll mailing list
>> Roll@ietf.org
>> https://www.ietf.org/mailman/listinfo/roll
> 
> _______________________________________________
> 6lo mailing list
> 6lo@ietf.org
> https://www.ietf.org/mailman/listinfo/6lo