[Roll] New version useofrplinfo

Ines Robles <mariainesrobles@googlemail.com> Mon, 04 November 2019 18:29 UTC

Return-Path: <mariainesrobles@googlemail.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6868612004A for <roll@ietfa.amsl.com>; Mon, 4 Nov 2019 10:29:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=googlemail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OU3d2FWGVwog for <roll@ietfa.amsl.com>; Mon, 4 Nov 2019 10:29:34 -0800 (PST)
Received: from mail-il1-x134.google.com (mail-il1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EA57120019 for <roll@ietf.org>; Mon, 4 Nov 2019 10:29:34 -0800 (PST)
Received: by mail-il1-x134.google.com with SMTP id n18so8730835ilt.9 for <roll@ietf.org>; Mon, 04 Nov 2019 10:29:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HNNs5TGFQHdSWakYWDaivML7Kjvulr05G2dMOqgQoDE=; b=mqgZsA3Jf1qjoemjKffF0JV1AhO5K69Ec/NYcjDV868RQcZ4pFZk1k6CV4RUHA9nr+ Po5IRBJQOY9wG6NlOuVk+crLDoAsg+iwEkywtkmIlD0zhTmbZ6jCqAkSiPi0rVoHchSn bjUnNRs+Xh9C++dwk//G9jK9kt9UBjHWiuwyyp1F3/vzZlln6mMA2VopsBhkal28dnBW 5ldrUl4rKMJNGVl19hj6bf28MlF48m/oqptXrQepdFmg2glTsYEj5h150wRd2rOcRmjD UIFA3leLpxCCIvNyGiAx5ZuIM32L4kKV7AwDagplk9zVSvUrBrNPvlO5a9KWs6OnKCpz 8ZTQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HNNs5TGFQHdSWakYWDaivML7Kjvulr05G2dMOqgQoDE=; b=X978e78D6FIJzz02ZGBQd9eLR3ZXZGP0f3S5SX6Bwn3MFAN8WAT45ttPb7H306wIex V+0o/uINQSWz0tqS9j+dSGAo9GDeDHimnAkCRMSL5QQQ1CU7w6CXghcAPjRPj5s83svu e8OAX9rqkZiNZiDF3nBlnm835YZuS/1MNNpM/gKkNzCej/4/82F99LCRhmQFFCMwBN5L QxrRLrBJMjy552QnTdRYQ1C89RV4fIADPTYNzjQIJ5zOL/o0gykU9bXe4f1Gd9MVjw90 tgzONsbxyYn1Dzysq1P+bnRst2IuHRgGYZSJZb+y4F2J6otWBZxrGcQ3WZY+9EDFDAkF zx7g==
X-Gm-Message-State: APjAAAWw9B58SrhsEYd1pwitDrcIOWuOGJ7TLG5FluCHlRAUcghVaUdj 5sPs8WeYH/mqcZp2DgNY+puOnCkEbikmsQSnbiY=
X-Google-Smtp-Source: APXvYqyK7KkuQsgS3Te1sQdySDhtZo7ci60mUCLo3RMpObrU02lpmMc1gkDE++GXMZ11rFwGBjBEF6CvoD/AZHMdpAs=
X-Received: by 2002:a92:8604:: with SMTP id g4mr27020500ild.50.1572892172889; Mon, 04 Nov 2019 10:29:32 -0800 (PST)
MIME-Version: 1.0
References: <CAP+sJUffg9x7Wcuj-BTCO9nJ8mdDXndMCpGNGc6u3xMj2NckxA@mail.gmail.com> <MN2PR11MB356587802AC06A9EDA483143D87C0@MN2PR11MB3565.namprd11.prod.outlook.com> <CADnDZ884Het9gehR4eLoZzzd4tL_NQ10cLrcTRh6S98VMT-a_w@mail.gmail.com> <MN2PR11MB35652B34E6F9A22F3B9C05C3D87F0@MN2PR11MB3565.namprd11.prod.outlook.com> <CAP+sJUeiLjn=kwnL+cbFgx6Rxmwn+JGGwEK+XkcAuAFJnrKOqg@mail.gmail.com> <MN2PR11MB356526E186F2970F3A520C44D87F0@MN2PR11MB3565.namprd11.prod.outlook.com>
In-Reply-To: <MN2PR11MB356526E186F2970F3A520C44D87F0@MN2PR11MB3565.namprd11.prod.outlook.com>
From: Ines Robles <mariainesrobles@googlemail.com>
Date: Mon, 4 Nov 2019 20:28:54 +0200
Message-ID: <CAP+sJUd2eW37FgJgNZwPr9nbJ0jnjF+HRMpV-1-YSwMC_5B0bA@mail.gmail.com>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
Cc: Routing Over Low power and Lossy networks <roll@ietf.org>, Michael Richardson <mcr+ietf@sandelman.ca>
Content-Type: multipart/alternative; boundary="0000000000003c33df0596897f09"
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/naOJbLC1V8RszcsSSBGhaHrjcoU>
Subject: [Roll] New version useofrplinfo
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Nov 2019 18:29:37 -0000

Thank you Pascal :)

Dear all, new version was updated including:

- Terminology clarifications

- New Section on Updates to RFC6550: Advertise External Routes with Non-
Storing Mode Signaling

- Assumptions Lists updated

- Uses cases in SM related with RUL as dst updated.

Please review and comments.

Much appreciated,

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-roll-useofrplinfo/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-roll-useofrplinfo-32
https://datatracker.ietf.org/doc/html/draft-ietf-roll-useofrplinfo-32

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-useofrplinfo-32

Ines.


On Mon, Nov 4, 2019 at 6:34 PM Pascal Thubert (pthubert) <pthubert@cisco.com>
wrote:

> Yes, Ines
>
>
>
> RPL awareness and the position of leaf are now orthogonal properties. A
> RAL has both.
>
>
>
> Can you please publish? I think cutoff is on us now.
>
>
>
> All the best
>
>
>
> Pascal
>
>
>
> *From:* Ines Robles <mariainesrobles@googlemail.com>
> *Sent:* lundi 4 novembre 2019 15:51
> *To:* Pascal Thubert (pthubert) <pthubert@cisco.com>
> *Cc:* Routing Over Low power and Lossy networks <roll@ietf.org>rg>; Michael
> Richardson <mcr+ietf@sandelman.ca>
> *Subject:* Re: [Roll] Making RUL draft normative reference in useofrplinfo
>
>
>
> 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) <
> pthubert@cisco.com> 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 <roll-bounces@ietf.org> *On Behalf Of *Abdussalam Baryun
> *Sent:* lundi 4 novembre 2019 09:05
> *To:* Routing Over Low power and Lossy networks <roll@ietf.org>
> *Cc:* Michael Richardson <mcr+ietf@sandelman.ca>ca>; Ines Robles <
> mariainesrobles@googlemail.com>
> *Subject:* Re: [Roll] Making RUL draft normative reference in useofrplinfo
>
>
>
>
>
>
>
> On Sun, Nov 3, 2019 at 4:34 PM Pascal Thubert (pthubert) <
> pthubert@cisco.com> 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 <mariainesrobles@googlemail.com
> <mariainesrobles@googlemail.com>> Sent: vendredi 25 octobre 2019 13:18 To:
> roll <roll@ietf.org <roll@ietf.org>> Cc: Pascal Thubert (pthubert)
> <pthubert@cisco.com <pthubert@cisco.com>>m>>; Michael Richardson
> <mcr+ietf@sandelman.ca <mcr%2Bietf@sandelman.ca>> 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
> Roll@ietf.org <Roll@ietf.org> https://www.ietf.org/mailman/listinfo/roll
> <https://www.ietf.org/mailman/listinfo/roll>*
>
>