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

Abdussalam Baryun <abdussalambaryun@gmail.com> Mon, 04 November 2019 08:05 UTC

Return-Path: <abdussalambaryun@gmail.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 9C98E1200B1 for <roll@ietfa.amsl.com>; Mon, 4 Nov 2019 00:05:08 -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=gmail.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 yzJaZDGEr2MG for <roll@ietfa.amsl.com>; Mon, 4 Nov 2019 00:05:06 -0800 (PST)
Received: from mail-ot1-x32a.google.com (mail-ot1-x32a.google.com [IPv6:2607:f8b0:4864:20::32a]) (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 0278F12006D for <roll@ietf.org>; Mon, 4 Nov 2019 00:05:06 -0800 (PST)
Received: by mail-ot1-x32a.google.com with SMTP id u4so2670160otq.10 for <roll@ietf.org>; Mon, 04 Nov 2019 00:05:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CUkRpEidi3r6lG9anA6Bju9QrISOzQ7nyOyGIeRECMA=; b=chy1N+LqbZCQXZT3PHHBhbR+QoaZbC/Jbbuw71qhEQ7aS2Aa1TsRrg8sy0Kigrh2Tx uoWeMttChRe+/doWeyIk/KhkGREmzbt2nZvLEER32rpR4XKrPJ8z5qEHuiEzI3xEzwcw j0YjYTHJAQ2L3qxZxXuitjkeAjWstuafqsi7Vi8JWAkaZ3uGEywQHv1l1S8HgTBS/M5+ jiEZNG+3KqqktGzmjwEj2y07TRyJvlu8fuSlcMNDYPjhdKnw4IHVrkzApvKvj1ldQDWg PCk48cuQP94GXlyESwKM8rDkc5blbcWpJvxp+nMlyTl4nUSVWyNwC8CTIQbShoxhDSyF 8Y0A==
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=CUkRpEidi3r6lG9anA6Bju9QrISOzQ7nyOyGIeRECMA=; b=VcRIcsxHEnZd5bZOyyF0ZanVTONWb+quBbKOqzWemGcRazVTBVTBu7BGYyJWdNNLYk LaODIQYxA/E3x5rjhvkcdyio5I9uh7Ip3JYV8epSJhycAYC9li2p6d1h1FAZZoZrShMi giNaREYeXDQWf+ZVmS8ovfER1Fl1g6kx3G8FiBFYER7WD41aXZlwqg6EU13PiUD8usg4 THRX5Mja0WyPl4gEEVPNpF4+Z0c4vj0t35Mz756zwMI4EXzUxoWNlHCqDU4xdGlyDghS VCGqUZDPhBxV3ZsnLO/yhYIGphHg7YOAXZopJMwSY6u5tbMpDSBn3rg2awvNFN/5VLrg YJ7A==
X-Gm-Message-State: APjAAAUy1+CB2ajkP2dKrnXdrVBnlvzzWDEXRpOryP5EWwDWxEOFfT8z e7FBgjawv0cdm6KPI6wIx+izZM8TaVG4XPIaULGceA==
X-Google-Smtp-Source: APXvYqwPH1vvN7mmDHKaJ9jBD7LPSjsnrkLwLdidken10u0zIKnwegC5JAi6pmn1DjJ1X0T8XiDe0J6WAbffrOjeKWs=
X-Received: by 2002:a9d:7dda:: with SMTP id k26mr16855862otn.223.1572854705224; Mon, 04 Nov 2019 00:05:05 -0800 (PST)
MIME-Version: 1.0
References: <CAP+sJUffg9x7Wcuj-BTCO9nJ8mdDXndMCpGNGc6u3xMj2NckxA@mail.gmail.com> <MN2PR11MB356587802AC06A9EDA483143D87C0@MN2PR11MB3565.namprd11.prod.outlook.com>
In-Reply-To: <MN2PR11MB356587802AC06A9EDA483143D87C0@MN2PR11MB3565.namprd11.prod.outlook.com>
From: Abdussalam Baryun <abdussalambaryun@gmail.com>
Date: Mon, 4 Nov 2019 10:04:50 +0200
Message-ID: <CADnDZ884Het9gehR4eLoZzzd4tL_NQ10cLrcTRh6S98VMT-a_w@mail.gmail.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Cc: Ines Robles <mariainesrobles@googlemail.com>, Michael Richardson <mcr+ietf@sandelman.ca>
Content-Type: multipart/alternative; boundary="000000000000fcff71059680c5f2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/Jq6JAEcG3p38Cu2ItEZgxthbBuo>
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: Mon, 04 Nov 2019 08:05:08 -0000

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