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

[Ines Robles <[e-mail]>]

Thank you Pascal for adding the terminology clarification.

Then, following my understanding when you say a "RPL Leaf" it is a node
that do not necessarily implement RPL. It is just a node that is attached
to the DODAG (with the features that you mentioned below).
If I refer to a RPL Leaf that implements RPL I should call it,
RPL-aware-leaf, otherwise is a RPL-unaware-leaf. Is this correct?

Thanks,
Ines.

On Mon, Nov 4, 2019 at 12:24 PM Pascal Thubert (pthubert) <
[e-mail]> wrote:

> Well noted though a technical reason has more weight than a preference.
>
>
>
> Editors: I made a pull request to define the Leaf.
>
>
>
> The draft already has text like
>
>
>
> “
>
>                                                                Further
> details about
>
>    this are mentioned in [I-D.thubert-roll-unaware-leaves], which
>
>    specifies RPL routing for a 6LN acting as a plain host and not being
>
>    aware of RPL.
>
> “
>
>
>
> This is very close to make the RUL draft a normative ref anyway. We need
> to change the name to draft-ietf by the way.
>
>
>
> Is we ship UseOfRPLinfo without the Normative ref to the RUL draft, this
> makes it the draft the place where the term RUL is defined.
>
>
>
> I need slight changes to the RUL draft to adapt to that and I’d like to be
> done either before cutoff so we can present to the group at IETF 106.
>
>
>
> Please let me know!
>
>
>
> Pascal
>
>
>
> *From:* Roll <[e-mail]> *On Behalf Of *Abdussalam Baryun
> *Sent:* lundi 4 novembre 2019 09:05
> *To:* Routing Over Low power and Lossy networks <[e-mail]>
> *Cc:* Michael Richardson <[e-mail]>; Ines Robles <
> [e-mail]>
> *Subject:* Re: [Roll] Making RUL draft normative reference in useofrplinfo
>
>
>
>
>
>
>
> On Sun, Nov 3, 2019 at 4:34 PM Pascal Thubert (pthubert) <
> [e-mail]> wrote:
>
> I do not think we concluded on this and we need to publish tomorrow.
>
>
>
> *On the one hand, we need to add a definition of a leaf in useofrpl
> information as a node that is attached to a RPL DODAG and as an IPv6 node
> is expected to handle consumed RH and HbH so it can receive a packet that
> went though the RPL domain with consumed RPL artifacts. That is needed, we
> are missing the definition of a leaf today..*
>
>
>
> *On the other hand, we need to decide if the definition of a RUL is 1)
> that in the useofrplinfo draft as it stands today in the repo
> https://raw.githubusercontent.com/roll-wg/useofrplinfo/master/roll-useofrplinfo.txt
> <https://raw.githubusercontent.com/roll-wg/useofrplinfo/master/roll-useofrplinfo.txt>
> (a leaf that does not speak RPL) or 2) the one in the RUL draft today (adds
> support to talk to the router using RFC 8505). If we leave as is I’ll
> update the RUL draft to say that the RUM draft plays with RUL that supports
> that additional stuff. *
>
>
>
>    1. *Is simple, no reference to RUL draft is needed, can go to RFC
>    quickly*
>    2. *Makes the RUl draft a normative reference, guarantees to keep the
>    2 specs homogeneous*
>
>
>
> *I’m OK either way, cutoff is tomorrow. Any clue?*
>
>
>
> I prefer (1), but me too, I'm OK either way,
>
>
>
> Thanks
>
> AB
>
>
>
>
>
>
>
>
>
> *From:*
>
>
>
> * Ines Robles <[e-mail]
> <[e-mail]>> Sent: vendredi 25 octobre 2019 13:18 To:
> roll <[e-mail] <[e-mail]>> Cc: Pascal Thubert (pthubert)
> <[e-mail] <[e-mail]>>; Michael Richardson
> <[e-mail] <[e-mail]>> Subject: Making RUL draft
> normative reference in useofrplinfo*
>
>
>
> *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.*
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *_______________________________________________ Roll mailing list
> [e-mail] <[e-mail]> https://www.ietf.org/mailman/listinfo/roll
> <https://www.ietf.org/mailman/listinfo/roll>*
>
>