Subject: [Roll] Making RUL draft normative reference in useofrplinfo

From: Ines Robles <[email-masked]>
Date: Fri, 25 Oct 2019 14:18:18 +0300

Dear all,

Discussing with Pascal and Michael, we would like to know if you think that
unaware-leaves draft should be normative in useofrplinfo.

Please find below some discussion points:

The RUL draft introduces a new beast to the RPL family, a
“Leaf-that-does-not-speak-RFC-6550“ but can now attach to the network and
benefit from special forwarding rules, provided that it implements the RUL
draft and some dependencies listed therein. Use-Of-RPL-Info aligned to the
WIP but there’s still a risk if it is published too soon that it is not
100% aligned. The misalignment we noted is mostly a terminology thing: is a
RUL a “Leaf-that-does-not-speak-RFC-6550“, or should we carry additional
meaning like support of the RUL draft and/or the dependencies.

The behavior for a RUL in Use-Of-RPL-Info world for the is correct but it
could apply to a slightly wider definition of a RUL than what the RUL draft
considers. E.g., a node that 1) does not implement the RUL draft and even
RFC 8505, but 2) never moves (tethered to the router or embedded therein),
could also attach to a RPL network provided that the router does a new set
of things, like handles the sequence counter and  stuff, and there could be
tons of variations of that guy e.g.,  whether that guy could provide an
“opaque” RPL-aware RPLinstanceID though it does not speak RFC 6550. The
description of the operation of a RUL in Use-Of-RPL-Info would work for
that guy as well, but that operation is not defined. IOW that guy is does
not (yet) belong to the RPL family, and will hopefully never do, because
the original 6LoWPAN ND is obsoleted by RFC 8505, so why not just do that?

To maximize the coverage of Use-Of-RPL-Info, we should need to include that
guy in the generic “RUL” definition. I’m not too interested in defining all
the variations of “that guy” and even less to give a name to all the
variations, and/or ensure that it could be doable to do RPL on their behalf
based on new hypothetic features in the router. Personally I’m happy enough
if the RUL that the Use-Of-RPL-Info describes has a scope that is reduced
to nodes that obey the RUL draft, because they are the only ones for which
we have a defined behavior in the router. Thus the proposal to make the RUL
draft a normative reference and live a few months with a missref.

Changes were done in the RUL draft to ensure that the operation described
for a RUL in Use-Of-RPL-Info is compatible with the new beast that the RUL
draft considers, making the new beast a subset of the RUL considered by
Use-Of-RPL-Info. Because when the doc became WG doc a RUL was any sort of
external route. the doc made it more specific. The price to pay was to
introduce a different behavior for the RUL and other “external
destinations”. As the text was changed for other “external destinations”
indicating e.g., the need to route via the parent and thus to use
Non-Storing signaling.

Then that text was stripped off the RUL draft and placed it in the
Use-Of-RPL-Info because it was really text on the forwarding behavior,
which is different if some assumptions cannot be made on the external
destination (need to encaps to the parent when it is not necessarily needed
for a RUL). That new text also fills a gap in Use-Of-RPL-Info and is
completely localized in a  new section. the  text was moved about routing
from the RUL draft to that section. Since it is not published yet, please
find that text inline below:

“

4.1. Updates to RFC6550: Advertise External Routes with Non-Storing

Mode Signaling.

Section 6.7.8. of [RFC6550] introduces the 'E' flag that is set to

indicate that the 6LR that generates the DAO redistributes external

targets into the RPL network. An external Target is a Target that

has been learned through an alternate protocol, for instance a route

to a prefix that is outside the RPL domain but reachable via a 6LR.

Being outside of the RPL domain, a node that is reached via an

external target cannot be guaranteed to ignore the RPL artifacts and

cannot be expected to process the [RFC8138] compression correctly.

This means that the RPL artifacts should be contained in an IP-in-IP

encapsulation that is removed by the 6LR, and that any remaining

compression should be expanded by the 6LR before it forwards a packet

outside the RPL domain.

This specification updates RPL [RFC6550] to RECOMMEND that external

targets are advertised using Non-Storing Mode signaling even in a

Storing-Mode network. This way, all packets to an external target

reach the Root that can encapsulate them, and the Root is informed of

the address of the 6LR that terminates the IP-in-IP tunnel. In case

of an external target, the Root SHOULD use the same IP-in-IP

encapsulation for packets that it generates or that are originated

within the RPL domain as if the packets were coming from the

Internet.

A RUL is a special case of external target when the target is

actually a host and it is known to support a consumed Routing Header

and to ignore a HbH header as prescribed by [RFC8200]. The target

may have been learned through as a host route or may have been

registered to the 6LR using [RFC8505]. IP-in-IP encapsulation MAY be

avoided for Root to RUL communication if the RUL is known to process

the packets as forwarded by the parent 6LR without decapsulation.

In order to enable IP-in-IP all the way to a 6LN, it is beneficial

that the 6LN supports decapsulating IP-in-IP, but that is not assumed

by [RFC8504]. If the 6LN is a RUL, the Root that encapsulates a

packet SHOULD terminate the tunnel at a parent 6LR unless it is aware

that the RUL supports IP-in-IP decapsulation.

A node that is reachable over an external route is not expected to

support [RFC8138]. Whether a decapsulation took place or not and

even when the 6LR is delivering the packet to a RUL, the 6LR that

injected an external route MUST uncompress the packet before

forwarding over that external route.

“

So where are we?

We need to agree on what we place in the definition of a RUL for which
Use-Of-RPL-Info
presents a special behavior. Do we limit to the ground common with the RUL
draft for which there is a defined RPL behavior, or do we define a new
different thing where Use-Of-RPL-Info handles an unclear superset of the
nodes that support the RUL draft and for which there is a defined RPL
operation? I do not see the need because if (ever, though doubtful) a new
draft defines the RPL operation for one version of “that guy” then is can
also say whether “that guy” should be handled as a RUL or as an “external
destination” in Use-Of-RPL-Info.

Thus the proposal to that that the operation of a “RUL” in Use-Of-RPL-Info
is for a node that supports the RUL draft, and make the RUL draft a
normative reference to define what that exactly mean. If we do so, MISSREF
will play its guardian role to ensure that Use-Of-RPL-Info is consistent
with the RUL draft till the last minute because it is not published too
hastly.

Looking forward to your reactions,

Ines, Pascal and Michael.

---

From: Rahul Jadhav <[email-masked]>
Date: Sun, 27 Oct 2019 04:48:18 +0000

Thank you for clarifying the thoughts in the mail. I am sure I would not have caught a drift if this would have been talked about directly (without a mail) during the 106-session.

Specifically, I want to talk about the following text:

"

the address of the 6LR that terminates the IP-in-IP tunnel.

"
I understand the reason why we need IP-in-IP tunnel terminating at the 6LR advertising the external-target. But when we say that only external targets are advertised using non-storing mode signaling even in a storing MOP, what we are asking is that all the 6LRs en-route (and not only the 6LR to which the external target is attaching) handle the external target in non-storing mode.
This means that all 6LRs in the network need to be capable of non-storing and storing mode even though the MOP advertised was for storing MOP only. This has implications for behaviour during parent switching. The text opens up a lot of room for interpretations and uncovered-scenarios. I am apprehensive of adding such text to useofrplinfo.

Regarding following, "Do we limit to the ground common with the RUL draft for which there is a defined RPL behavior, or do we define a new different thing where Use-Of-RPL-Info handles an unclear superset of the nodes that support the RUL draft and for which there is a defined RPL operation? "

I certainly feel that we should limit the ground common for which there is a defined RPL behavior.

In general, unaware-leaves seem to have a much broader impact than I initially thought.

Regards,
Rahul

________________________________
Then that text was stripped off the RUL draft and placed it in the Use-Of-RPL-Info because it was really text on the forwarding behavior, which is different if some assumptions cannot be made on the external destination (need to encaps to the parent when it is not necessarily needed for a RUL). That new text also fills a gap in Use-Of-RPL-Info and is completely localized in a  new section. the  text was moved about routing from the RUL draft to that section. Since it is not published yet, please find that text inline below:

“

Mode Signaling.

outside the RPL domain.

Internet.

and to ignore a HbH header as prescribed by [RFC8200].. The target

“

So where are we?

We need to agree on what we place in the definition of a RUL for which Use-Of-RPL-Info presents a special behavior. Do we limit to the ground common with the RUL draft for which there is a defined RPL behavior, or do we define a new different thing where Use-Of-RPL-Info handles an unclear superset of the nodes that support the RUL draft and for which there is a defined RPL operation? I do not see the need because if (ever, though doubtful) a new draft defines the RPL operation for one version of “that guy” then is can also say whether “that guy” should be handled as a RUL or as an “external destination” in Use-Of-RPL-Info.

Thus the proposal to that that the operation of a “RUL” in Use-Of-RPL-Info is for a node that supports the RUL draft, and make the RUL draft a normative reference to define what that exactly mean. If we do so, MISSREF will play its guardian role to ensure that Use-Of-RPL-Info is consistent with the RUL draft till the last minute because it is not published too hastly.

---

From: Ines Robles <[email-masked]>
Date: Wed, 30 Oct 2019 13:15:59 +0200

Hi Rahul,

Thank you very much for the detailed review,  few comments in-line.

On Sun, Oct 27, 2019 at 6:49 AM Rahul Jadhav <[email-masked]> wrote:

> Thank you for clarifying the thoughts in the mail. I am sure I would not
> have caught a drift if this would have been talked about directly (without
> a mail) during the 106-session.
>
> I understand the reason why we need IP-in-IP tunnel terminating at the 6LR
> advertising the external-target. But when we say that only external targets
> are advertised using non-storing mode signaling even in a storing MOP, what
> we are asking is that all the 6LRs en-route (and not only the 6LR to which
> the external target is attaching) handle the external target in non-storing
> mode.
> This means that all 6LRs in the network need to be capable of non-storing
> and storing mode even though the MOP advertised was for storing MOP only.
> This has implications for behaviour during parent switching. The text
> opens up a lot of room for interpretations and uncovered-scenarios. I am
> apprehensive of adding such text to useofrplinfo.
>

We are going to improve that text, to avoid wrong interpretations, and
clarifying the methodology when the traffic is directed to the RUL.

>
> Regarding following, "Do we limit to the ground common with the RUL draft
> for which there is a defined RPL behavior, or do we define a new different
> thing where Use-Of-RPL-Info handles an unclear superset of the nodes that
> support the RUL draft and for which there is a defined RPL operation? "
>

Ok,  thank you.

> In general, unaware-leaves seem to have a much broader impact than I

Agree :)

Best, Ines.

>
> Regards,
> Rahul
>
>
> ------------------------------
> We need to agree on what we place in the definition of a RUL for which Use-Of-RPL-Info
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 30 Oct 2019 12:59:28 +0000

Hello Rahul, all

From: Roll <[email-masked]> On Behalf Of Rahul Jadhav
Sent: dimanche 27 octobre 2019 05:48
To: roll <[email-masked]>
Cc: Michael Richardson <[email-masked]>
Subject: Re: [Roll] Making RUL draft normative reference in useofrplinfo

"

<Pascal>
( : Misunderstanding warning : )

The 'signaling' discussed in that text is the control plane, more specifically the DAO that is sent by the 6LR directly to the root as opposed to percolating child to parent like other internal DAO message in storing mode. In the data plane you have IP in IP to the 6LR and no RH, so the intermediate routers just see a packet to the 6LR and need not worry whether there's an IP packet inside.

We certainly need to clarify. What about:

"

targets are advertised using Non-Storing Mode DAO messaging even in a

Storing-Mode network. This way, external routes are not advertised within

the DODAG and all packets to an external target reach the Root like normal

non-storing mode traffic. The Non-Storing Mode DAO informs the Root of the

address of the 6LR that injects the external route, and the root uses IP-in-IP

encapsulation to that 6LR, which terminates the IP-in-IP tunnel and forwards

the original packet outside the RPL domain.

"
</Pascal>

<Pascal>
Cool, we agree : )
</Pascal>

Regards,
Rahul

"

Mode Signaling.

outside the RPL domain.

Internet.

"

So where are we?

We need to agree on what we place in the definition of a RUL for which Use-Of-RPL-Info presents a special behavior. Do we limit to the ground common with the RUL draft for which there is a defined RPL behavior, or do we define a new different thing where Use-Of-RPL-Info handles an unclear superset of the nodes that support the RUL draft and for which there is a defined RPL operation? I do not see the need because if (ever, though doubtful) a new draft defines the RPL operation for one version of "that guy" then is can also say whether "that guy" should be handled as a RUL or as an "external destination" in Use-Of-RPL-Info.

Thus the proposal to that that the operation of a "RUL" in Use-Of-RPL-Info is for a node that supports the RUL draft, and make the RUL draft a normative reference to define what that exactly mean. If we do so, MISSREF will play its guardian role to ensure that Use-Of-RPL-Info is consistent with the RUL draft till the last minute because it is not published too hastly.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 31 Oct 2019 13:44:34 +0000

It's getting urgent to publish with the coming freeze. As for the RUL draft I'm suggesting a clearer language to address the below:

"
6.2.  External Routes and RPL Artifacts

   Section 4.1. of [USEofRPLinfo] provides a set of rules that MUST be
   followed when forwarding packets over an external route:

  ...

   Non-Storing Mode DAO messages are used to signal external routes to
   the Root, even if the DODAG is operated in Storing Mode.  This
   enables to advertise the 6LR that injects the route for use as tunnel
   endpoint in the data path.  For all external routes, the Root should
   use an IP-in-IP tunnel to that 6LR, with the RPL artifacts in the
   outer header to be stripped by the 6LR.  The IP-in-IP encapsulation
   may be avoided in storing mode if the path to the external
   destination beyond the 6LR is known to handle or ignore the RPL
   artifacts properly [RFC8200].  A RUL is an example of a destination
   that is reachable via an external (host) route for which IP-in-IP
   tunneling may be avoided as it ignores the RPI and the consumed SRH
   artifacts.  The use of Non-Storing mode signaling in Storing Mode and
   the associated IP-in-IP encapsulation are transparent to intermediate
   routers that only see packets back and forth between the Root and the
   6LR and do not need a special support for external routes.

...

"

I'll also make a PR for the change below in useofrplinfo.

All the best,

Pascal

From: Pascal Thubert (pthubert)
Sent: mercredi 30 octobre 2019 13:59
To: Routing Over Low power and Lossy networks <[email-masked]>
Cc: Michael Richardson <[email-masked]>
Subject: RE: [Roll] Making RUL draft normative reference in useofrplinfo

Hello Rahul, all

From: Roll <[email-masked]<mailto:[email-masked]>> On Behalf Of Rahul Jadhav
Sent: dimanche 27 octobre 2019 05:48
To: roll <[email-masked]<mailto:[email-masked]>>
Cc: Michael Richardson <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Roll] Making RUL draft normative reference in useofrplinfo

"

<Pascal>

"

"
</Pascal>

<Pascal>
Cool, we agree : )
</Pascal>

Regards,
Rahul

"

Mode Signaling.

outside the RPL domain.

Internet.

"

So where are we?

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 31 Oct 2019 14:20:14 +0000

Dear Ines and all

I made a PR as promised https://github.com/roll-wg/useofrplinfo/pull/4

You'll find that the proposed change clarifies the issue that Rahul was raising:
"
   This specification updates [RFC6550] to RECOMMEND that external
   targets are advertised using Non-Storing Mode DAO messaging even in a
   Storing-Mode network.  This way, external routes are not advertised
   within the DODAG and all packets to an external target reach the Root
   like normal Non-Storing Mode traffic.  The Non-Storing Mode DAO
   informs the Root of the address of the 6LR that injects the external
   route, and the root uses IP-in-IP encapsulation to that 6LR, which
   terminates the IP-in-IP tunnel and forwards the original packet
   outside the RPL domain free of RPL artifacts.  This whole operation
   is transparent to intermediate routers that only see traffic between
   the 6LR and the Root, and only the Root and the 6LRs that inject
   external routes in the network need to be upgraded to add this
   function to the network.
<

I hope this helps.  Can you please consider publishing before cutoff?

All the best

Pascal

To: Routing Over Low power and Lossy networks <[email-masked]<mailto:[email-masked]>>

Hello Rahul, all

"

<Pascal>

"

"
</Pascal>

<Pascal>
Cool, we agree : )
</Pascal>

Regards,
Rahul

"

Mode Signaling.

outside the RPL domain.

Internet.

"

So where are we?

---

From: Ines Robles <[email-masked]>
Date: Thu, 31 Oct 2019 17:20:27 +0200

Thank you Pascal for adding the clarification.

I will add the modifications to the use cases related: 1- Storing Mode:
Example of Flow from Internet to RUL. and 2- Storing Mode: Example of Flow
from RUL to RUL. and publish it.

Best,

Ines.

On Thu, Oct 31, 2019 at 4:20 PM Pascal Thubert (pthubert) <
[email-masked]> wrote:

> You’ll find that the proposed change clarifies the issue that Rahul was
> raising:
>
> “
>
> «
> *From:* Pascal Thubert (pthubert)
> *Sent:* mercredi 30 octobre 2019 13:59
> *To:* Routing Over Low power and Lossy networks <[email-masked]>
> *Cc:* Michael Richardson <[email-masked]>
> *Subject:* RE: [Roll] Making RUL draft normative reference in useofrplinfo
>
>
>
> Hello Rahul, all
>
>
>
> *From:* Roll <[email-masked]> *On Behalf Of *Rahul Jadhav
> *Sent:* dimanche 27 octobre 2019 05:48
> *To:* roll <[email-masked]>
> *Cc:* Michael Richardson <[email-masked]>
> *Subject:* Re: [Roll] Making RUL draft normative reference in useofrplinfo
>
>
>
> This has implications for behaviour during parent switching. The text opens
> up a lot of room for interpretations and uncovered-scenarios. I am
> The ‘signaling’ discussed in that text is the control plane, more
> specifically the DAO that is sent by the 6LR directly to the root as
> opposed to percolating child to parent like other internal DAO message in
> storing mode. In the data plane you have IP in IP to the 6LR and no RH, so
> the intermediate routers just see a packet to the 6LR and need not worry
> whether there’s an IP packet inside.
>
>
>
> We need to agree on what we place in the definition of a RUL for
> which Use-Of-RPL-Info presents a special behavior. Do we limit to the
> ground common with the RUL draft for which there is a defined RPL behavior,
> or do we define a new different thing where Use-Of-RPL-Info handles an
> unclear superset of the nodes that support the RUL draft and for which
> there is a defined RPL operation? I do not see the need because if (ever,
> though doubtful) a new draft defines the RPL operation for one version of
> “that guy” then is can also say whether “that guy” should be handled as a
> RUL or as an “external destination” in Use-Of-RPL-Info.
>
>
>