Re: [Roll] Erik Kline's Discuss on draft-ietf-roll-useofrplinfo-42: (with DISCUSS and COMMENT)

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 16 December 2020 18:01 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 829843A0A70 for <roll@ietfa.amsl.com>; Wed, 16 Dec 2020 10:01:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 9gCCtD-M3DaS for <roll@ietfa.amsl.com>; Wed, 16 Dec 2020 10:01:38 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72CC63A0A50 for <roll@ietf.org>; Wed, 16 Dec 2020 10:01:38 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 2978638981; Wed, 16 Dec 2020 13:04:18 -0500 (EST)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id snn2fqTuTRsX; Wed, 16 Dec 2020 13:04:16 -0500 (EST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 441403899C; Wed, 16 Dec 2020 13:04:16 -0500 (EST)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 7F54BAA9; Wed, 16 Dec 2020 13:01:34 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Erik Kline <ek.ietf@gmail.com>, Routing Over Low power and Lossy networks <roll@ietf.org>
In-Reply-To: <160809761379.22994.11202105892505044046@ietfa.amsl.com>
References: <160809761379.22994.11202105892505044046@ietfa.amsl.com>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Wed, 16 Dec 2020 13:01:34 -0500
Message-ID: <9337.1608141694@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/3ruNdntO3ftidqF_d2wUwLTlfPA>
Subject: Re: [Roll] Erik Kline's Discuss on draft-ietf-roll-useofrplinfo-42: (with DISCUSS and COMMENT)
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, 16 Dec 2020 18:01:41 -0000

Erik Kline via Datatracker <noreply@ietf.org> wrote:
    >   I might recommend instead referring to RFC 6554 S4.2 for how to
    > handle RH3's if the node is also a RPL-aware router and say it MUST
    > drop the packet if segments left is non-zero and it's not a RPL-aware
    > router.

    >   Related: I'd also recommend:

    >   "It should just be noted that an incoming RH3 must be fully consumed,
    > or very carefully inspected."

    ->

    >   "It should just be noted that an incoming RH3 MUST be fully
    > consumed."

I think that Pascal and I, when we write the "carefully inspected", is
that we are imagining situations where the topology is a bit subtle.
Perhaps there are firewalls involved.
Perhaps a device has multiple interfaces (many radios for instance) and the
extra segments address the other interfaces.

Also draft-ietf-anima-autonomic-control-plane uses storing mode, so never has
RH3 headers, but imagine if it did.

One could have a situation where the physical system containing one or more
layers of container was not the ultimate last hop from a logical point of
view.  Rather than inner container was.  So, it's all the same stack
actually.  In that case, an optimization might be to process more than
one segment in that stack.
(The ANIMA ACP definitely supports having VMs and containers inside routers)

So, I can live with your suggestion, because in my case above,
we can argue that it's still "consumed"

    > * I'm confused by the use of "consumed" here.  Is the final RH3 entry
    > RUL's address?  I guess you could say RH penultimate hop "consumes" the
    > header because the ultimate destination address is put in the header DA
    > field.  Seems a bit odd though.

Yes, that's what we mean.
Once that ultimate destination is in the DA, then the RH3 is a dummy, but one
we are aren't supposed to remove.

    >   I assume 6LR_n gets RUL's address from the last segment in RH3.

    >   "Consumed" means segments left == 0, I guess?  I suppose should have
    > picked up on this terminology when it was first used in Section 2.
    > Maybe clarify what it means in that section (2)?

Yes.


--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide