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

Ines Robles <mariainesrobles@googlemail.com> Wed, 30 October 2019 11:16 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 0EF97120099 for <roll@ietfa.amsl.com>; Wed, 30 Oct 2019 04:16:42 -0700 (PDT)
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 tjdBWiOeQWfz for <roll@ietfa.amsl.com>; Wed, 30 Oct 2019 04:16:38 -0700 (PDT)
Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (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 6B8E4120046 for <roll@ietf.org>; Wed, 30 Oct 2019 04:16:38 -0700 (PDT)
Received: by mail-io1-xd35.google.com with SMTP id r144so2044483iod.8 for <roll@ietf.org>; Wed, 30 Oct 2019 04:16:38 -0700 (PDT)
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=mYU2JKHMKKSxcsF7la5LwIc6rElASRXUY3qtYAQTMpI=; b=ZqHmnrhVNPN2qCfcmuTM166+DtzZROfjhS36XA1ESjgSRO+iAzhF6+QEg9lM1i6hYq WVa9mj/1WC3nmWL29Ra3QX/hN+1O3siQQ51rtXYwgQAxllFg2/qEEL1cnoWKVnIxZoz1 bXcvu0QnkNzTrgT2UoSVYcdA5Fok7JaO6gFyI4M19XkLp+OaR8WdO5puUBeyT75pqqi6 5YM5NqBWDCffj0zbgRU8DIY9U2zpg0tNAgMeB0/AWoHq+aVVxaYO32CWluUR0yPteRsR 2sC6ioFFfnE3sbY9iWStpf3SJoOLJTxKSUVUzNW5JXG1zpWY3eSuJWtAVsSkz99bEAaI iTRg==
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=mYU2JKHMKKSxcsF7la5LwIc6rElASRXUY3qtYAQTMpI=; b=DJu6G8YA3vUukDsSLD28MaXZzYJv2T2D0rQBhG0Onz/hgN3A4w7W8JjGyot0mxBL9y SB91OhOJLSAKFDzOtJcgAe+AqpL4ZmCP16ZtommZACWRax68ypv3kXroBHgT3Y6r9rxZ PJtShcTGV8zs57HXmRu9hVxZktKZ0Qcbc2OliCDKKR9I5TpQ/K6qmmbEnJIIFBddnhB+ Pfowg/QoGzAqjIeGyDhlO5iRSsj3D/3WXYfi99x59hEQPur9CJoFVPtoeBubDvUxv3DK zs8UYJ7RJuIusZlmO5ZPfrMF8lMpk5HKaytqMxv6Cc/3Z6PrT3fHcvHJb7+zWc8iIDHS Ae6A==
X-Gm-Message-State: APjAAAXxndSvNsPGOODfVZb4n+RUxAgtt6Q9qPYXnPIO8PGTlIafbjyB 5jSo7EKolknxhlAsDeE17cijIl9zSgDGAZQ/o6kOvA==
X-Google-Smtp-Source: APXvYqxS3fCe7omBhh8FIPMDK/2SCeAQ9EuVg0NAMveywMn6nBXkWb089KZyq7ypjDOzSzmGYScmSfv5HPQGqESC9Fs=
X-Received: by 2002:a02:8793:: with SMTP id t19mr27941950jai.44.1572434197206; Wed, 30 Oct 2019 04:16:37 -0700 (PDT)
MIME-Version: 1.0
References: <CAP+sJUffg9x7Wcuj-BTCO9nJ8mdDXndMCpGNGc6u3xMj2NckxA@mail.gmail.com> <BM1PR01MB2612EC4F16CB281160899285A9670@BM1PR01MB2612.INDPRD01.PROD.OUTLOOK.COM>
In-Reply-To: <BM1PR01MB2612EC4F16CB281160899285A9670@BM1PR01MB2612.INDPRD01.PROD.OUTLOOK.COM>
From: Ines Robles <mariainesrobles@googlemail.com>
Date: Wed, 30 Oct 2019 13:15:59 +0200
Message-ID: <CAP+sJUdy5=8FsWt5c4Yq62509rbDCod0XK2x=5bPxJyagC+u8g@mail.gmail.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Cc: Michael Richardson <mcr+ietf@sandelman.ca>
Content-Type: multipart/alternative; boundary="000000000000c1db6e05961edd4c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/Yfzi_sQNu7QaNkb0m7r7LeSBmkE>
Subject: Re: [Roll] Making RUL draft normative reference in 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: Wed, 30 Oct 2019 11:16:42 -0000

Hi Rahul,

Thank you very much for the detailed review,  few comments in-line.



On Sun, Oct 27, 2019 at 6:49 AM Rahul Jadhav <nyrahul@outlook.com> wrote:

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

We are going to improve that text, to avoid wrong interpretations, and
clarifying the methodology when the traffic is directed to the RUL.

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

Ok,  thank you.

>
> In general, unaware-leaves seem to have a much broader impact than I
> initially thought.
>

Agree :)

Best, Ines.

>
> 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.
>
>
>
>
>
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>