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

[Rahul Jadhav <[e-mail]>]

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:

"

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.

"
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:



“



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.