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

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 4 Jan 2015 11:59:52 -0000

Michael,

Thanks for continuing to try to wrangle this situation.

> someone wrote;
>     >> So, it seems prudent (to me) to look at each of the alternatives and
>     >> determine which warts everyone concerned is willing to live with.
>     >> Running code is a good way to do that.
> 
> Carsten Bormann <[email-masked]> wrote:
>     > I agree with Xavi here: This is a good way to gather data for
>     > implementation issues (such as the implementation complexity of the
>     > “efficient” variant of the NHC approach).  It is not so good
> 
> so, I think that we have consensus that this can not be left to the plugfest.

I understand that the plugfest has to have a baseline: you can't arrive at the plugfest with lots of implementations of different things!

On the other hand, I don't think that the WG has to agree what the plugfest will do. I think it is fine for some group of people to make that agreement (by all means point at existing I-Ds or even write a brief I-D or wiki page saying "this is what we will test").

If everyone has energy, the plugfest could even test more than one approach.

> A number of people have not replied; some ADs and some WG chairs.
> (I realize that Gabriel Montenegro is new in this position; maybe he can
> bring a fresh viewpoint?)

Is there a specific question you'd like this AD to answer?

> I am going to put up a doodle poll for the week of Jan. 12.
> My goal is not to need it, that we will have a plan for the Jan 9, 6tisch
> call.

I didn't see anything further on this.

> Please: how do we proceed?

Consensus can sometimes be hard-won and slow. It is one of the things that makes people claim the IETF is slow. On the other hand, the alternative to consensus is, erm, no consensus.

In agreeing consensus, however, we may need to declare minority opinions "in the rough" [RFC7282] if there is a body of opinion that one way of doing things is preferred and if the drawbacks of that approach are clearly recognised and accepted.

I see the plugfest as an important way of reaching consensus on this issue. That is, if the plugfest shows that a particular approach is functional and not harmful it provides a strong case for documenting and standardising the mechanism.

Beyond that it may be most helpful to note the objections to the "preferred" approach and to write text that explains the concerns and how they are mitigated (for example, not sending traffic out of admin domains without applying some magic policy).

Adrian

---

From: Ralph Droms <[email-masked]>
Date: Mon, 5 Jan 2015 17:29:36 -0500

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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 6 Jan 2015 06:22:11 +0000

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.

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.

Makes sense?

Pascal

> Le 5 janv. 2015 à 23:29, Ralph Droms <[email-masked]> a écrit :
> 
> Do I have it right that:
> 
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: Ralph Droms <[email-masked]>
Date: Tue, 6 Jan 2015 09:33:01 -0500

(Adding 6man because of architecture issues)

> 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…

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

> 6lo mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lo

---

From: Ralph Droms <[email-masked]>
Date: Tue, 6 Jan 2015 10:30:39 -0500

> Thanks for continuing to try to wrangle this situation.

Agreeing - thanks.

> [...]

Yes, and, in this particular case, there are at least 4 working groups involved, which will make determining and declaring consensus even more difficult.

> I see the plugfest as an important way of reaching consensus on this issue. That is, if the plugfest shows that a particular approach is functional and not harmful it provides a strong case for doc…

Another outcome of the plugfest would be to assess the quality of the existing drafts (can an implementation be built from just the text in the draft) and the impact of the new mechanisms on other parts of the IPv6 suite as well as network operation.

> Beyond that it may be most helpful to note the objections to the "preferred" approach and to write text that explains the concerns and how they are mitigated (for example, not sending traffic out o…

I don't know that we have enough detail and discussion, yet, to have determined a "preferred" approach. 

- Ralph

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 6 Jan 2015 16:07:58 +0000

> in draft-thubert-6lo-rpl-nhc...

[PT] Yes, by design. The NHC draft has a more pragmatic and limited scope. 
It covers the compression of the RPL option. 
Whatever is used for IP in IP compression and RH3 is unchanged by that draft.

> 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?

[PT] That would not be the goal, Ralph. 

The idea is that there is a biunivocal correspondence between the compressed and the uncompressed format.
The outter header with the RPL option and the RH3 (whichever are needed) would be placed in the new dispatch. 
But the 6LoWPAN expansion would result in the packet as it stands today.

Makes sense?

Pascal
> >> 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
> >>
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch

---

From: Michael Richardson <[email-masked]>
Date: Tue, 06 Jan 2015 12:01:54 -0500

Ralph Droms <[email-masked]> wrote:
    > 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 answer is that a sub-IP protocol can encapsulate arbitrary layer-3 packets.
In particular, one can have overlapping IP addressing contexts, and there is
no implicit l3-routing assumed between sub-IP protocols.
In the LLN case, the l3-layer is constrained; the additional "tag" (the RPL
Instance ID) is used to select a particular QoS much like the DSCP can do.
Routing between instanceIDs is assumed; but potentially not every node has
the specific routes that permits it to do that.

    > 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.

I think that all of the HC methods *can* be implemented as Bump-in-the-Stack
activities; and in particular the loop LLN->ethernet->LLN should be
lossless(%). (ethernet->LLN->ethernet is both out of scope [the LLN is never
a transit network], and also potentially lossy as some generality of 6553 and
6554 may sacrificed.

(%)-lossless definition assumes flow label is always zero.

A think that concerns me is that I think that most constrained devices will
not implement HC as a bump in the stack, but will uncompress the headers
directly into internal control structures, and may have loose the ability to
process uncompressed 6553/6554 headers.

One could view this as a vestigal appendix-like thing that evolved away.
This could be regarded as good: less unused/untested code that will get
exploited.   This could be regarded as bad: as frame sizes in LLN radios grow
(802.15.4g, I'm told, has much larger frames) some systems might have no
6lowpan layer, and interoperation opportunities might become difficult.

(I picked the appendix on purpose: some say that it was used to digest
grasses/cellulose. If we had a useful appendix, humans might never starve...)

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Tue, 06 Jan 2015 12:03:43 -0500

An experiment which I have yet to do is to see what happens if one applies
GHC (https://tools.ietf.org/html/rfc7400) to 6553 and 6554.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Ralph Droms <[email-masked]>
Date: Tue, 6 Jan 2015 14:40:41 -0500

On Jan 6, 2015, at 12:01 PM 1/6/15, Michael Richardson <[email-masked]> wrote:

> In particular, one can have overlapping IP addressing contexts,

"addressing contexts"?

> and there is

OK.

> Routing between instanceIDs is assumed;

..instanceIDs covering intersecting sets of nodes; i.e., some nodes are part of multiple instances?

> but potentially not every node has

Not sure how that relates to a sub-IP protocol for carrying source routes and RPL tags?

> activities;

That statement gets to part of my question about draft-thubert-6lo-routing-dispatch: in the abstract, is draft-thubert-6lo-routing-dispatch intended to provide a mechanism through which the original RPI, RH3 and IP-in-IP headers can be reconstructed before sending the resulting IPv6 datagram up to the IPv6 stack?  At the risk of being overly concerned with the details, I really mean "reconstruct the header" as opposed to "carry information that can be used to perform the same function".

> and in particular the loop LLN->ethernet->LLN should be
> lossless(%).

...where both LLNs and ethernet are part of the same RPL instance?

> (ethernet->LLN->ethernet is both out of scope [the LLN is never

Yeah.  We already see a side-effect of this form of implementation in the desire for compression techniques that do not result in expansion during transit, because such expansion can require re-fragmentation of a datagram that might otherwise be forwarded in place without explicitly uncompressing to the full IPv6 representation.

> 6lowpan layer, and interoperation opportunities might become difficult.

I think there are also important issues to think about the interaction between a sub-IP protocol and the rest of the IPv6 protocol.  If the abstraction is that the sub-IP bits reconstruct into IPv6 headers, we may have less collateral damage to worry about.  Documents defining that behavior will beed to be careful to show the details and that the conversions are lossless.

- Ralph

---

From: Michael Richardson <[email-masked]>
Date: Tue, 06 Jan 2015 18:13:31 -0500

> "addressing contexts"?

It's a meaningless and ambiguous term, particularly in IPv6.  Perhaps there
is a better one in some BEHAVE document.
What I mean is that you can run ten different 10.0.0.0/8 RFC1918 networks
simultaneously on the same link using one of the sub-IP protocols...

    > part of multiple instances?

Correct, any node could be part of multiple DODAGs which have been optimized
differently.  Whether those nodes will route traffic along a shorter path
than going to (respective) DODAG roots, and then out again is really outside
of our scope, let's just agree that it is a reasonable.
(Consider a powered light bulb router that participates in both the light
control DODAG, and also the TV remote control DODAG)

    > Not sure how that relates to a sub-IP protocol for carrying source routes and RPL tags?

I guess it depends upon what you mean by "sub-IP".
I think that we are speaking about it in the former IETF AREA sense; things
which are below IP, which have a layering distinction from IP, and which
can simultaenously carry a multitude of layer-3 protocols.  MPLS for
instance.

Are you considering 6lowpan HC to be a sub-IP protocol?
Is PPP a sub-IP protocol?
Is PPP VJ compression a sub-IP protocol?

    > That statement gets to part of my question about
    > draft-thubert-6lo-routing-dispatch: in the abstract, is
    > draft-thubert-6lo-routing-dispatch intended to provide a mechanism
    > through which the original RPI, RH3 and IP-in-IP headers can be
    > reconstructed before sending the resulting IPv6 datagram up to the IPv6
    > stack?  At the risk of being overly concerned with the details, I
    > really mean "reconstruct the header" as opposed to "carry information
    > that can be used to perform the same function".

I think that this is the intent, and I see this as a good thing.

    > ...where both LLNs and ethernet are part of the same RPL instance?

Yes, exactly: ethernet bridge of LLN between metal floors or other radio
opaque barriers.

    > Yeah.  We already see a side-effect of this form of implementation in
    > the desire for compression techniques that do not result in expansion
    > during transit, because such expansion can require re-fragmentation of
    > a datagram that might otherwise be forwarded in place without
    > explicitly uncompressing to the full IPv6 representation.

    > I think there are also important issues to think about the interaction
    > between a sub-IP protocol and the rest of the IPv6 protocol.  If the
    > abstraction is that the sub-IP bits reconstruct into IPv6 headers, we
    > may have less collateral damage to worry about.  Documents defining
    > that behavior will beed to be careful to show the details and that the
    > conversions are lossless.

I agree completely.
One of the concerns I realized with rpl-flow-label was that it created an
alternative to 6553 which was not equivalent.  It's better actually, even on
Ethernet-like media.  It's also easier to implement in ASICs and current
protocol stacks because filters which match the flow label area available
already.  As such, if we go the rpl-flow-label way, we should probably
obsolete 6553 since we have present way to negotiate or announce what
should be used for a given network.

---

From: Tom Taylor <[email-masked]>
Date: Tue, 06 Jan 2015 18:20:06 -0500

> simultaneously on the same link using one of the sub-IP protocols...

[PTT] The Behave term is "address domain". Initial definition in RFC 
2663, repeated in subsequent documents.
....

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 7 Jan 2015 12:54:20 +0000

Hi:

6LoWPAN HC and the new draft proposals (NHC, dispatch, all apart from the flow label) are encoding procedures that can be reversed so as to restore the original packet.
The term sub IP, should it refer to an encapsulation like a vlan, would be inappropriate. If it refers to an adaptation layer below IP, it would apply. 
But if the meaning is unclear, then we need to clarify before using it. 

Cheers,

Pascal

> -----Original Message-----
> From: ipv6 [mailto:[email-masked]] On Behalf Of Michael Richardson
> Sent: mercredi 7 janvier 2015 00:14
> To: Ralph Droms
> Cc: [email-masked]; [email-masked]; 6man WG; Routing
> Over Low power and Lossy networks; [email-masked] WG; [email-masked];
> [email-masked]
> Subject: Re: [6tisch] [6lo] [Roll] call for consensus for the RPL RPI / RH3
> compression
> 
> 
> It's a meaningless and ambiguous term, particularly in IPv6.  Perhaps there is a
> better one in some BEHAVE document.
> differently.  Whether those nodes will route traffic along a shorter path than
> going to (respective) DODAG roots, and then out again is really outside of our
> scope, let's just agree that it is a reasonable.
> (Consider a powered light bulb router that participates in both the light control
> DODAG, and also the TV remote control DODAG)
> 
> I think that we are speaking about it in the former IETF AREA sense; things which
> are below IP, which have a layering distinction from IP, and which can
> simultaenously carry a multitude of layer-3 protocols.  MPLS for instance.
> 
> Yes, exactly: ethernet bridge of LLN between metal floors or other radio opaque
> barriers.
> 
> Ethernet-like media.  It's also easier to implement in ASICs and current protocol
> stacks because filters which match the flow label area available already.  As
> such, if we go the rpl-flow-label way, we should probably obsolete 6553 since
> we have present way to negotiate or announce what should be used for a given
> network.
> 
> --
> Michael Richardson <[email-masked]>, Sandelman Software Works  -=
> IPv6 IoT consulting =-
> 
>

---

From: Michael Richardson <[email-masked]>
Date: Wed, 07 Jan 2015 09:59:01 -0500

Thank you Tom for point at RFC2663 for "address domain". 

Pascal Thubert (pthubert) <[email-masked]> wrote:
    > 6LoWPAN HC and the new draft proposals (NHC, dispatch, all apart from
    > the flow label) are encoding procedures that can be reversed so as to
    > restore the original packet. 
    > The term sub IP, should it refer to an encapsulation like a vlan, would
    > be inappropriate. If it refers to an adaptation layer below IP, it
    > would apply.  

So, again, I think a key reason why the various HC are not a sub-IP protocol
is because rfc6553 does not create new addressing domains with the RPL
InstanceID.

Can we agree that this is not a sub-IP signalization problem.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 7 Jan 2015 15:15:20 +0000

Yes, Michael.

I think it would help to take that out of the equation.

Cheers,

Pascal

> From: 6tisch [mailto:[email-masked]] On Behalf Of Michael Richardson
> Sent: mercredi 7 janvier 2015 15:59
> To: [email-masked]; [email-masked]; 6man WG; Routing
> So, again, I think a key reason why the various HC are not a sub-IP protocol is
> because rfc6553 does not create new addressing domains with the RPL
> InstanceID.
>

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 07 Jan 2015 17:43:27 +0100

> GHC (https://tools.ietf.org/html/rfc7400) to 6553 and 6554.

Little point -- there is very little inherent redundancy on the byte 
sequence level.

Gruesse, Carsten

---

From: Robert Cragie <[email-masked]>
Date: Mon, 12 Jan 2015 20:38:18 +0000

My views on what I think are the salient points in the discussion so far:

1) Use of interop to validate a way forward

I don't agree that a specification has to be set in stone for an 
interop. The whole point of an interop sometimes is to test the 
specification and expect it to change afterwards. If there are a number 
of proposals, then it doesn't seem unreasonable to clearly specify each 
proposal and implement all proposals. This in itself will give an idea 
of complexity; the interop will give an idea of issues arising and 
therefore it should help in deciding which one is the best as clearly 
there doesn't seem to be consensus based solely on the drafts.

2) Choice of proposals

Assuming elimination isn't going to occur via the mailing list, the 
three options are:

a. draft-thubert-roll-flow-label-02 (RPI only)
b. draft-thubert-6lo-rpl-nhc-02 but pick one of the three (greedy, 
conservative, efficient) first (RPI only)
c. draft-thubert-6lo-routing-dispatch-01 (RPI and RH3)

This implies the current method would be used for RH3 in cases (a) and (b).

3) Compression of RH3 using NHC

This could be developed as an alternative. I don't recall the NHC 
approach being abandoned.

4) Time schedule

Carsten gave a good summary earlier. I can't see why 
draft-thubert-6lo-routing-dispatch-01 would take any longer to finalise 
than draft-thubert-6lo-rpl-nhc-02, especially if the latter would 
include RH3 as well.

5) Sub-IP protocol

The mesh header as it stands is not significantly different to what is 
being proposed for 6LoRH as it too could be used to carry IPv6 addresses 
in a compressed format on the basis that link layer addresses are 
already used with autoconfigured IPv6 addresses. I would therefore see 
6LoRH as a general more flexible replacement for the mesh header and 
therefore 6LoRH used in conjunction with RPI/RH3 would not be a sub-ip 
protocol.

In essence, the difference is really this:

RFC4944:
mesh[0..a] | FRAG1 | IPHC | {IPHC[0..b] | NHC[0..c]}[0..d] | Payload
mesh[0..a] | FRAGN | Payload

draft-thubert-6lo-routing-dispatch-01:
6LoRH[0..a] | FRAG1 | 6LoRH[0..b] | IPHC | {IPHC[0..c] | 
NHC[0..d]}[0..e} | Payload
6LoRH[0..a] | FRAGN | Payload

All the above really shows is that 6LoRH can be used in place of a mesh 
header for sub-ip purposes simply as a "less greedy" way or it can be 
used to replace an IPHC header as used currently in conjunction with a 
more efficient header extension. If I have one issue, it is calling them 
all "6LoRH" - the RPI can sit a "6LoRH-style" header extension alongside 
an IPHC header if there is no encapsulation, I believe?

This is where I have some sympathy with James Woodyatt's e-mail - the 
options start to look a little hairy and it becomes significantly more 
complex to figure out what goes where.

6) Bump-in-the-stack

I have seen both bump-in-the-stack and full decompression/recompression. 
In addition to what Pascal points out, there are some other subtle 
considerations which need to be applied for BITS, especially with regard 
to eliding what look like padding fields - I have seen one issue where a 
value of 0 was considered to be padding and not included correctly.