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

[Abdussalam Baryun <[e-mail]>]

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