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

[Ines Robles <[e-mail]>]

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) <
[e-mail]> wrote:

> 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
>
>
>
>
>
>
>
> *From:* Pascal Thubert (pthubert)
> *Sent:* mercredi 30 octobre 2019 13:59
> *To:* Routing Over Low power and Lossy networks <[e-mail]>
> *Cc:* Michael Richardson <[e-mail]>
> *Subject:* RE: [Roll] Making RUL draft normative reference in useofrplinfo
>
>
>
> Hello Rahul, all
>
>
>
> *From:* Roll <[e-mail]> *On Behalf Of *Rahul Jadhav
> *Sent:* dimanche 27 octobre 2019 05:48
> *To:* roll <[e-mail]>
> *Cc:* Michael Richardson <[e-mail]>
> *Subject:* Re: [Roll] Making RUL draft normative reference in useofrplinfo
>
>
>
> 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.
>
>
>
>
>
> <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:
>
>
>
> “
>
>
>
> This specification updates RPL [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.
>
>
>
> “
>
> </Pascal>
>
>
>
>
>
>
>
>
>
> 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.
>
>
>
>
>
> <Pascal>
>
> Cool, we agree : )
>
> </Pascal>
>
>
>
> 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.
>
>
>
>
>
>
>
>
>
>
>