Re: [Roll] AD Review of draft-ietf-roll-efficient-npdao-16

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Fri, 25 October 2019 18:08 UTC

Return-Path: <pthubert@cisco.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 A02B1120088; Fri, 25 Oct 2019 11:08:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=SQcirKz7; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=VrMHDZlt
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 KTG3oTEPPC6n; Fri, 25 Oct 2019 11:08:48 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 315FE120043; Fri, 25 Oct 2019 11:08:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10560; q=dns/txt; s=iport; t=1572026928; x=1573236528; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=fpyzdezq0sC7cXX55tqeq1ywV7u7uZEw3hUOr/8gJqQ=; b=SQcirKz7NCsO9RM4L9KwXrDI8X36jctizUh1S3bemD5k1G+Mz8d7Ta0T PPVJ8aF6Su1+5AiWOeCSgLSl1AgyKKjj8lBPxJMNgS9wVr6pk0D0icjXH raH9ha6hzEHFujOI6zXW6XLX/yzrY+jIsZL0hsKQH3H0UAHvZnOo0RMHb E=;
IronPort-PHdr: =?us-ascii?q?9a23=3AQsaxSxLoEMnRzIs68dmcpTVXNCE6p7X5OBIU4Z?= =?us-ascii?q?M7irVIN76u5InmIFeBvKd2lFGcW4Ld5roEkOfQv636EU04qZea+DFnEtRXUg?= =?us-ascii?q?Mdz8AfngguGsmAXFXnLOPgYjYmNM9DT1RiuXq8NBsdFQ=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ApAACcObNd/4oNJK1bChoBAQEBAQE?= =?us-ascii?q?BAQEDAQEBAREBAQECAgEBAQGBagIBAQEBCwGBSiknBWxXIAQLKoQog0cDim2?= =?us-ascii?q?CXn+XBoJSA1QJAQEBDAEBIwoCAQGEQAIXgygkNwYOAgMJAQEEAQEBAgEFBG2?= =?us-ascii?q?FNwyFUAEBAQECARIREQwBATcBBAsCAQgODAImAgICMBUQAgQBDQ0agwGCRgM?= =?us-ascii?q?OIAECDKdMAoE4iGF1gTKCfgEBBYUOGIIXAwaBDigBhRWGeRiBQD+BEUaBTkk?= =?us-ascii?q?1PoJiAQECAYEzLYMOMoIsjQ8ygjeOb44UbgqCJIcQiTcFhHyCPIdUiw6ENY4?= =?us-ascii?q?8gUCGapEiAgQCBAUCDgEBBYFoI4FYcBWDJ1AQFIMGDBeBBAEHgkSFFIU/dAE?= =?us-ascii?q?BgSePOAEB?=
X-IronPort-AV: E=Sophos;i="5.68,229,1569283200"; d="scan'208";a="350439875"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 25 Oct 2019 18:08:44 +0000
Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by alln-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id x9PI8ix9030580 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 25 Oct 2019 18:08:44 GMT
Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 25 Oct 2019 13:08:43 -0500
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 25 Oct 2019 13:08:42 -0500
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 25 Oct 2019 14:08:42 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DFDJYSfU2uLr+tafjnb35qHfbVeDHPpgX6EDY0ddXah97ehODvb1s8jigfZBaaYfYARwCGfZZ1AwJs56nYWjZkOmnt25MJRwC6MGCEns/pWgo7tnGbrEdgLD1Zr5Q8Z60eOfqxoCUPXcWekAMBKScPcNJ0NsyxtklRxqyZUrX3eAxY8E410EbqlLSdPSY/9/9ROrbIVlEormbUY/WNdwmM0kkrCPNf8WTl1x6HTZmeiI35ktHirsBveX/ordauILdcFh+tTnforLHp+chrnNgPNlP6U5vh/kLYF+1kvMTI1UbsMNfsa1uoNiWBLM072mjvvtFC/WVTO42ThpxorNDA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fpyzdezq0sC7cXX55tqeq1ywV7u7uZEw3hUOr/8gJqQ=; b=YKBrgOaAtwWKjBJ9/o0+AcmW9/FKlQ6Trojl4elc7NAshG0+OePWpukzAiHZqwMNahDmgGPSZJP0zLHMAXShQH9zIo86Idw7z+FTXYmVPHLI66vhPyV/TysM1kKeno4jK6/ZUCEPZY6n0ZBfDUHbN5muwMl38c5Y+s7bmlTE+iQDEKrOT7ul/0h7L1RGMJC98qJf3LpDXppqao+qc0w13nAaWhpdMhqw1mlQNPGhu8GS96IETi/HZwI8zdUGnUcsdpp0gA/PtTuXr6NQ/RWZaAwZVQl7Zjd1OhidQt12CdbKtASrUmnTj0dzfMcbKJOtFdHRCmlz4hi3XvgCiteUAA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fpyzdezq0sC7cXX55tqeq1ywV7u7uZEw3hUOr/8gJqQ=; b=VrMHDZltPlnhVFRep954I+iaT5Iem7eiivRN8ff0gwz/rxAFbPLwV6+7JoB0NmgHfXrjJ9Oasc/ub+IktXfKah9klvJ/LV00aBOZEEFjyEVR/its9u8NnFbCXnlu67ZX7llI6zErxbgZhltOTfYE5EXgmM/+BQ2V/+8E9i7l3n0=
Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB4205.namprd11.prod.outlook.com (52.135.39.87) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2387.22; Fri, 25 Oct 2019 18:08:40 +0000
Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::31c9:3a31:3c07:a920]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::31c9:3a31:3c07:a920%6]) with mapi id 15.20.2387.023; Fri, 25 Oct 2019 18:08:39 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Alvaro Retana <aretana.ietf@gmail.com>, "draft-ietf-roll-efficient-npdao@ietf.org" <draft-ietf-roll-efficient-npdao@ietf.org>
CC: "roll-chairs@ietf.org" <roll-chairs@ietf.org>, roll <roll@ietf.org>, Peter van der Stok <consultancy@vanderstok.org>
Thread-Topic: AD Review of draft-ietf-roll-efficient-npdao-16
Thread-Index: AQHVhRpHdCR3gF1qN0eG33Ksa1+m8KdlJ+hggATdowCAARmQUA==
Date: Fri, 25 Oct 2019 18:07:30 +0000
Deferred-Delivery: Fri, 25 Oct 2019 18:02:33 +0000
Message-ID: <MN2PR11MB3565998D4CD88FF786E892AED8650@MN2PR11MB3565.namprd11.prod.outlook.com>
References: <CAMMESswgX8YynN=tehXDMg+suOiiaCTpnoP9LxoH3orG06_Trw@mail.gmail.com> <MN2PR11MB3565181C2DDC7A3FB7DFCB2FD8690@MN2PR11MB3565.namprd11.prod.outlook.com> <CAMMESsz_MJSC+Sx5hPsTFVufqEGUYjuTJFt7pJs7mut_7nHRxA@mail.gmail.com>
In-Reply-To: <CAMMESsz_MJSC+Sx5hPsTFVufqEGUYjuTJFt7pJs7mut_7nHRxA@mail.gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com;
x-originating-ip: [2001:420:c0c0:1007::c3]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: cf680bb2-ee6e-463e-6677-08d759765d21
x-ms-traffictypediagnostic: MN2PR11MB4205:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <MN2PR11MB420504A6E133F3CED46F4349D8650@MN2PR11MB4205.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 02015246A9
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(39860400002)(376002)(346002)(366004)(136003)(189003)(199004)(66446008)(74316002)(486006)(66946007)(6246003)(229853002)(6666004)(81156014)(81166006)(6116002)(71200400001)(446003)(71190400001)(66574012)(76116006)(8676002)(46003)(6436002)(86362001)(966005)(25786009)(8936002)(52536014)(4326008)(2906002)(2501003)(476003)(54906003)(55016002)(6506007)(316002)(102836004)(14454004)(478600001)(305945005)(33656002)(7736002)(11346002)(110136005)(14444005)(9686003)(6306002)(7696005)(99286004)(256004)(76176011)(64756008)(66476007)(186003)(5660300002)(66556008); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4205; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: UsSX6eeKNz/aQWm44BS6MYts8Aqfsyj/MKuMWT3mltGIjaVytluGz0a39yr+am5w0hy92Q6sRCrSzB2r5F+rN3Yvio/8XR6J254RN1TcEoBnTr+m4fSfoE3TndHDqx33Yuo170gwNt3fWOWeKafLStP+y7SA5V3n2dFkmhTR4KTYr4rwaKkp/TLaWtqbhQXikWp2d41ujcgxRQNnlcVjW7B4r3FtK7x3zzzdfDZWXCTQQ+QBSj+77sN7OkEDzk9qFpLtf5j3MvnifZXE17WCX6DENzOVLuIYUYUoKLEqWhJ8gZQP/vWXsor9BqXHmMHdjy/S8szSiircEEiorUerlSB6/zsn20kj09FEYmClikNIPciTXCyiCcXUnNWq+BElKhEzAVF2nQnJ+CwtscutaxqpKXJqurSwYMcLmf+yNpaW6kGMn4qN+Spk4BgXhxLcJBPikGBab8uD7qF5br1YANKWE8jvBsdlBntByIJA4eI=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: cf680bb2-ee6e-463e-6677-08d759765d21
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Oct 2019 18:08:39.7228 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 6FdESh5mqHWNOSIKZmNi00JBMY1I6RQpp3mZgcLCH9hSZyD2SyUFu9s9F/Fdgrdy9T+DIqvZWZtikdddDsGp8A==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4205
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.13, xch-aln-003.cisco.com
X-Outbound-Node: alln-core-5.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/lOHiS-fjJzIxcnFJlcIz1ERqSvY>
Subject: Re: [Roll] AD Review of draft-ietf-roll-efficient-npdao-16
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: Fri, 25 Oct 2019 18:08:50 -0000

Hello Alvaro : )

Please see below

> > When the address moves on the backbone, the RPL state in the old DODAG
> > is Cleaned from the 6LBR down. And the status from 6BBR to 6LBR is
> > moved so the expectation is that it percolates down. The rejection is
> > mostly to cleanup RPL since the leaf is expected to be long gone and
> > registered in a different DODAG across the backbone.
> 
> I think I understand -- homogenizing is not a bad thing. :-)
> 
> However, I am still concerned about a couple of things:
> 
> (1) the values are not the same...for example, "moved" in rfc8505 has a value
> of 3, not 130.  Why not use the same value?  The answer to this question
> overflows into my second concern...

It cannot be a convergence because RPL had rules in https://tools.ietf.org/html/rfc6550#section-6.5.1 whereby the status below 128 are warning. 
That provision was not really used so far to my best knowledge. So we could drop it. We chose not to so far. Could be done though if that's your recommendation.

> 
> (2) draft-ietf-roll-unaware-leaves doesn't update the allocation guidelines
> from rfc6550 (§6.5.1) for the Status, which then lands "moved" in the
> "Rejection" range.  IOW, the meaning is changed, but the original meaning of
> the DAO-ACK Status is not updated...
> 
> [We are not reviewing draft-ietf-roll-unaware-leaves here, so some of these
> comments can be saved for later. ;-)]

I see: we need to indicate that we update/extend the semantics of a the DAO-ACK status.
Should that be indicated in npdao draft or in unaware leaves, where the IANA is done for all?

> 
> Needless to say, I don't like this approach.  

What would your recommendation be? The need is to transport the 6LoWPAN status back in DAO-ACK and DAR messages.
The whole game is to divide the amount of recurrent messages by 2, by implicitly transport the periodic ND DAR in a periodic RPL DAO.
The DAO-ACK is pretty small and pretty full already so stealing the leftover bits to transport both separately seems difficult.

>                                                                                      But if the WG wants to go
> forward this way, then I want to make this document Normatively depend on
> draft-ietf-roll-unaware-leaves because that is where the registry and
> meaning for the Status values are defined.  I also think that because of that,
> we will want to hold sending this document back to the RFC Editor until we
> get the final text for draft-ietf-roll-unaware-leaves (and decide that we don't
> need additional review for this document).
 
That works for me, we can speed up unaware-leaves, it is mostly done.

> 
> One more thing, in reading through rfc8505, I found this text (which I had
> completely missed before):
> 
>    If the receiver of the message has registration state corresponding to the
> related address, it SHOULD propagate the status down the forwarding path
> to the Registered Node (e.g., reversing an existing RPL [RFC6550] path as
> prescribed in [Efficient-NPDAO]).
> 
> So...if the rfc8505 status is "moved" (which is actually the topic of the
> paragraph from where the text above was taken in §5.7), what should be
> propagated using the DCO?  130?  Where is that specified?
> 

We are specifying it right now in Efficient-NPDAO. RFC 8505 was forward looking to that respect. It had to indicate the ND status for that case and that status is "moved".
- It means the guys was down there but is no more. Which is exactly the topic of NPDAA, cleanup a downwards path that leads to a location from which the target has moved away.
- But it could not discuss how RPL translates it back and forth. The generic spec for that is unaware-leaves. DCO is a special case of RC/status that matches "moved" in RFC 8505.
 


> 
> > > [major] "the RPL Status MUST NOT be changed...is informative and
> > > does not affect the behavior of the receiver...unknown values are
> > > ignored...Only Rejection Codes (values of 128 and above) are expected in
> a DCO."
> > >
> > > If the value doesn't matter (informative) and unknown ones are
> > > ignored, why specify that it MUST NOT change? What is the Normative
> value of that?

Because in some cases it will be turned into ND again and in those cases the meaning must be conveyed unmodified. NPDAO is the only vector we have in storing mode to convey something all the way down since the DAO-ACK is one hop.

> > > Specifically, if the value was changed to something < 128, what
> > > should the receiver do?
> >
> > We wish the information to be known by all nodes, and this is a
> > provision that we can reliably act differently per status value all
> > the along the DODAG in the future. So we see this as protecting the future.
> Is that a problem?
> 
> Sorry...let me try again.  I see two problems:
> 
> (1) The values are informative, but Normatively are not to change.
> How can the "MUST NOT" be enforced in the network?  How would a
> receiver know if the value was changed (or not)?  You added that "we can
> reliably act differently per status value" (but the text currently
> reads: "value is informative and does not affect the behavior of the
> receiver") -- having a consistent/reliable behavior can be achieved only if it
> can be guaranteed that the value didn't change.  If it did change, what is the
> expected behavior?

The meaning we wanted to convey is that when propagating down the DCO, the status from the parent MUST be repeated unchanged to the children.
Suggestion to reword from the perspective of the intermediate router.

> (2) If only values > 128 are expected, then what should a receiver do if a
> value < 128 is received?  Should the DCO not be propagated further?

Yes, the DCO should be propagated and as done today, it causes the destruction of the path regardless of the value of the status, even a warning <128.
Should we change that so a warning is propagated but the route is conserved or something? There is no known usage of that today, does that protect the future better?

> 
> 
> > > ...
> > 574 4.5. Unsolicited DCO
> >
> > 576 A 6LR may generate an unsolicited DCO to unilaterally cleanup the
> > 577 path on behalf of the target entry. The 6LR has all the state
> > 578 information, namely, the Target address and the Path Sequence,
> > 579 required for generating DCO in its routing table. The conditions
> > why
> > 580 6LR may generate an unsolicited DCO are beyond the scope of this
> > 581 document but some possible reasons could be:
> >
> > 583 1. On route expiry of an entry, a 6LR may decide to graciously
> > 584 cleanup the entry by initiating DCO.
> > 585 2. 6LR needs to entertain higher priority entries in case the
> > 586 routing table is full, thus resulting in eviction of an existing
> > 587 routing entry. In this case the eviction can be handled
> > 588 graciously using DCO.
> >
> > 590 Note that if the 6LR initiates a unilateral path cleanup using DCO
> > 591 and if it has the latest state for the target then the DCO would
> > 592 finally reach the target node. Thus the target node would be
> > 593 informed of its invalidation.
> >
> > > [] This section wasn't changed, but it seems to me that there's an
> > > opportunity to indicate these known reasons as Status in the DCO.
> > > Among other things, the target node would be able to identify the
> > > reason for the unsolicited DCO...
> >
> > Agreed, let's look at this.
> 
> Perfect!


Cool, we'll propose text for all the above once we agree on the other points.

Enjoy the week end!

PAscal
> 
> Thanks!
> 
> Alvaro.