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

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Wed, 16 December 2020 12:38 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 882C63A0AAD; Wed, 16 Dec 2020 04:38:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.601
X-Spam-Level:
X-Spam-Status: No, score=-9.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, 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=gR82QNM/; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=UnD9teme
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 WaTWTL8GwrqD; Wed, 16 Dec 2020 04:38:38 -0800 (PST)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 470393A0AA7; Wed, 16 Dec 2020 04:38:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5646; q=dns/txt; s=iport; t=1608122318; x=1609331918; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=OQs2q9f41oDWytVjlrQgcrHhFv0XHj5ije5pehXXrko=; b=gR82QNM/EzBdPJSUfF94vGOohqNGxVUzV1QpS907Dq0CrOxslJs6h/zz RnlXUtyVwFcIFlHJnv+Nf0FPFvGh8aE09L2XGLMafKou5LFFSo/RIiUIy Zs/wVnMkedp6M7m8KAisrYDTOZs/cCOZYYTnFK1+wj6KHfXkfAq30ysA9 I=;
X-IPAS-Result: =?us-ascii?q?A0A5AAAo/tlfmIoNJK1iHQEBAQEJARIBBQUBQIE8BwELA?= =?us-ascii?q?YFRUYFXLy6EP4NIA41bA5kKgS6BJQNUCwEBAQ0BAS0CBAEBhEoCF4FZAiU1C?= =?us-ascii?q?A4CAwEBAQMCAwEBAQEFAQEBAgEGBBQBAQEBAQEBAYY2DIVyAQEBAwESEQQND?= =?us-ascii?q?AEBNwEECwIBCA4MAiYCAgIwFRACBAENDRqDBIJWAw4gAaFxAoE8iGl2fzODB?= =?us-ascii?q?AEBBYUlGIIQCYEOKgGCdIJqTkKCRINyJhuBQT+BEUOCVj6EQIMVM4IsgVlvY?= =?us-ascii?q?0MUEoErBwEKExoPH49uBIJrAT6TV5AwgQYKgnSbbaI9lAWcVQiESwIEAgQFA?= =?us-ascii?q?g4BAQWBWAMzgVlwFYMkUBcCDY4hGh2DOopYdDcCBgoBAQMJfIlFAQE?=
IronPort-PHdr: =?us-ascii?q?9a23=3AO5cf+xRKemg5+BEaO/10bf6EG9psv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESQBNmJ5PdNiu6QuKflCiQM4peE5XYFdpEEFx?= =?us-ascii?q?oIkt4fkAFoBsmZQVb6I/jnY21ffoxCWVZp8mv9PR1TH8DzNFLXq3y2qzUVH0?= =?us-ascii?q?a3OQ98PO+gHInUgoy+3Pyz/JuGZQJOiXK9bLp+IQ/wox/Ws5wdgJBpLeA6zR?= =?us-ascii?q?6arw=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.78,424,1599523200"; d="scan'208";a="653355281"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 16 Dec 2020 12:38:37 +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 0BGCcbal014820 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 16 Dec 2020 12:38:37 GMT
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 16 Dec 2020 06:38:36 -0600
Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 16 Dec 2020 07:38:35 -0500
Received: from NAM12-DM6-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 16 Dec 2020 06:38:35 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KcrXnzWDtyYnQp64AqccYFvP5B2fTWo9M1hHNX2pUKu9BNGYOck/hIr8yzGM18wOvNzVSRmTZjqNXUtUttoaAjIKF7Ghz+DfSR23gaEeYnoA0+YTnEg0YbuiKwut/dyUh8PXRa4oOqbD8b69bV8btOlB+XV5rDoPUm+zHgypbEC2T4jeWUWnifDs5NCUQ4pIe1TbC6/84MCa6cp+HCw8vYqOQMHIEugjyhq/8ACeRU9cr5vdS15Za58T+P23xqNHZWnmqzgLW8K06dCuB6+r4PYavJTEKPWSc7D7vqgOc7MXORegwPv/RdsdeFGL3xtuUVZX1jLAtUcWaB++R9XPBQ==
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=OQs2q9f41oDWytVjlrQgcrHhFv0XHj5ije5pehXXrko=; b=cAZTckOXrhI3XUVo+J35V8CWnXkoukNN0E01ktU6ftmSWTppQe8NsaUxiAHZnbnCsd8oSOUgcYBWCvVToH/ct/f6b4jQSNMvRdI5R5wUoPu9FdE9x33o6JBhIH3R9zCYsVVHNTaCwWu36+aqVEiGbbm7l7p4oOclDnHSmhMKUD0KSrka6uFJfLbyymXyOBbaeJo3bCmWo+JgKMXzXvfNidHvUq55sEY1zUae1d7vXv9WfdiQ15y3ZfCNn6vYshzyQwzsBz32Veo0MTtcJpMrIUcE/8T+3NISZv+av/9O8/vCsfVs4CqY6IW1zXe4gCS9F3k4cXoZqtwQnHa1LAKiEQ==
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=OQs2q9f41oDWytVjlrQgcrHhFv0XHj5ije5pehXXrko=; b=UnD9teme4DjjhZNmnVtgqItPpI6NYXUCu3tSuNLqeC5wEM+JKjXSrUL/d8WVK9vz+zwqBpBqZLJl/5wmRZtNqczmiUvGfXryOndoqfYpfAmeFl76PVsKX0RD0AWZwGLY+kOQJJA44VW7qdzrGOvBZkCZIhZAGzRnSEQlnDE0a+o=
Received: from CO1PR11MB4881.namprd11.prod.outlook.com (2603:10b6:303:91::20) by MWHPR11MB1775.namprd11.prod.outlook.com (2603:10b6:300:10e::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3654.12; Wed, 16 Dec 2020 12:38:34 +0000
Received: from CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::499:4510:59d6:8f61]) by CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::499:4510:59d6:8f61%4]) with mapi id 15.20.3654.020; Wed, 16 Dec 2020 12:38:34 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Erik Kline <ek.ietf@gmail.com>, The IESG <iesg@ietf.org>
CC: "draft-ietf-roll-useofrplinfo@ietf.org" <draft-ietf-roll-useofrplinfo@ietf.org>, "roll-chairs@ietf.org" <roll-chairs@ietf.org>, "roll@ietf.org" <roll@ietf.org>, Peter Van der Stok <consultancy@vanderstok.org>, "aretana.ietf@gmail.com" <aretana.ietf@gmail.com>
Thread-Topic: Erik Kline's Discuss on draft-ietf-roll-useofrplinfo-42: (with DISCUSS and COMMENT)
Thread-Index: AQHW027lA6s1+UY7JEO2hFM1mSKZJqn5anUw
Date: Wed, 16 Dec 2020 12:38:13 +0000
Deferred-Delivery: Wed, 16 Dec 2020 12:37:35 +0000
Message-ID: <CO1PR11MB48813C34B5BA6835A41656F2D8C50@CO1PR11MB4881.namprd11.prod.outlook.com>
References: <160809761379.22994.11202105892505044046@ietfa.amsl.com>
In-Reply-To: <160809761379.22994.11202105892505044046@ietfa.amsl.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [2a01:cb1d:4ec:2200:80f0:4acd:dde0:b36f]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 478f98e9-77d5-4a0c-647f-08d8a1bf80e6
x-ms-traffictypediagnostic: MWHPR11MB1775:
x-microsoft-antispam-prvs: <MWHPR11MB1775D63F3E56B4F0A657A437D8C50@MWHPR11MB1775.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: zQMne6zAXZ1tezxAW0WeOwlE0Gk3lJXmxrZIFEMHP2OqCEvlOgEJIk/DEbQ9Y3jUpUL0mLMNH/XXTMrpM5HPTTKDmMarTeNkxP1zgqg1xIsrnQJYrlWA5evJgSnQMnS8MHK+3pfV/QNHQqpi+JUgLdMaE0ACif8BhyBJK3gl6e5N2y5wcymE3KF0u8vcM0Om3dWwyvmh8G1pzkrPReui1bjkwE8mUAUp2/pt6oUPB10H2vwaeDGm1PAYgRByg+2kT+VQwckeBCYbmSHg8Cn1iJMkIkMk2qrSZiOINoJiB1QB8N9QlWSiv4DYtw2Jz2fzW180vpH1ptf3joYR+trP7Q==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CO1PR11MB4881.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(39860400002)(376002)(136003)(366004)(396003)(7696005)(8676002)(66574015)(33656002)(52536014)(66556008)(66946007)(110136005)(6506007)(186003)(478600001)(54906003)(64756008)(8936002)(6666004)(83380400001)(86362001)(66476007)(55016002)(66446008)(4326008)(5660300002)(316002)(76116006)(71200400001)(9686003)(2906002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?utf-8?B?b081K2RFRlQ1WWZaMHdwZDdGbHVuMUI4Q0M5ZzNYSkRodGV5aE5QMW1acWxU?= =?utf-8?B?bUJYTnZacnpZd3ovVjJYc3pFVit3OExKV1pYSnpXZzZXdkdOZS9DblV4UVRv?= =?utf-8?B?TVZOeVdpbWx6SmNwb0M2bkVibGJ4N3g1RXN2QWhhSUd0QnI5Umk0RkR2VDV1?= =?utf-8?B?WjZiNnNWM1Vqb3pIZlFrRXdxNFdMeExNM0ozblBYL1pBbFhpZEVEUEVVeno5?= =?utf-8?B?cklHZCtaVlJEV3dXaFRid25kemVhdjQycFN6S0ltTnQ0RC9zYVVMKytRWWxr?= =?utf-8?B?WlRHNmlxWkM5SEhLM1pHbVVkYnUweWkrMC9CUURWSlhsZStKRzhDSm9FbG1X?= =?utf-8?B?Nkw2bFdWSGxwSjdLd2lxRnY5UWx4WldFNUYwNjBSTVEvTWM5OVFuY0F0RHEy?= =?utf-8?B?NHJMQXdVdnUzcDU1cUdYTUZ3WVJ1S05QZGNoRU5NUkJxbVorak4vdGVNcTR1?= =?utf-8?B?RXpwSkV4Ukt4N1lBZWl3QjZjR3pLWlZVZVYyVGFIcHJXajRlTHhzWHUrZi9O?= =?utf-8?B?Z2w5bU5RNFl4dFRTYjhHSEhvSE1BRFVrMDhkek5SdnkyZFp4RnFTVTgyZjZw?= =?utf-8?B?eEFXdWEvbHptUmdSemdhU21SN2dZVk1INmlDcGlsTE9hbjlBZWZucHRrWlpP?= =?utf-8?B?aGF5WUdRbWZaMnhTZDRuNFRPMVFIQkl4L3AvOUw1RmpiM2UxaGdraSsxNVFu?= =?utf-8?B?aWJWcEFxMVNKdXNQNU1CeUdCM0FydjF2eG5sV1ZoRUhKRTIzUzB2dkdvV3FV?= =?utf-8?B?V2FoS2lwVmgvdnhmT0Yxbk5oZlgwb0swSnR2WVdXMmxCb2pQdFJ6NThVcWlY?= =?utf-8?B?L3dxV3lwOW9WVno3RGhMNWRneU1JMkRqTUJpVGNhenNNZnZRT0VzVEwwMDNX?= =?utf-8?B?SFZPN2FKcnJ3QWY5RzN0N3FyTEk3QzhqSHYweFJwRTFwTEJnTjVlN2NRUUVh?= =?utf-8?B?aWhRdnIvQ3IwUUJPNFJLUFdBY3RQRzVEZjVzWG9uVUJpSFUzU2FZdjlvbDFO?= =?utf-8?B?MnBid3pSODZOL1VIa25TOThkUE1Ocmp6QjJHMm9Xc3F6T0NXeW0xbEl0MDNv?= =?utf-8?B?RURWWUp5L0FHekkzaUVJTnVpZFJyRExaVXZEenNXc1JkYldjNHpZcUNEOEtE?= =?utf-8?B?NG5mc1RUUk5wR0YxYWk2bnVSUHFwZUFCaGt2TnhoZjhpcG5GQmxoeWhZa3lp?= =?utf-8?B?b0tlUzNDOHFRanN2Q1JFcTNvdmNBUmR1d0Y3SnZtMllEWFF6M2hJaDJ6MkVk?= =?utf-8?B?amNwSlRTMjNqV0FTZFU0MHN4RjdWVFdtc0xkTmpIT2lNek5lUWlQYVZWWkdE?= =?utf-8?B?MFNTb2J1Ulgzb1JKYWQ0TDZuUWhzcVZLNHJrcllqbC9Sdmhac3FBVkpCSUMw?= =?utf-8?B?QVRaYy9mZTdpRG9CQzRWekNUellOTEZlbi85R1BFeXhKOE5LNlN2K0ozazdm?= =?utf-8?Q?9eR/JZNn?=
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-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CO1PR11MB4881.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 478f98e9-77d5-4a0c-647f-08d8a1bf80e6
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Dec 2020 12:38:34.4979 (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: VgxkWxsGhabhuSx9cI/qyjn8gKkBBY/90hYDJysg4k29bVnpgSreKm68UcdOoZeNQuT+nYp8aDEUEpzVYD8/2g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1775
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/KpLDgXqG8ai0fVSdlTJj0yhk9gI>
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 12:38:43 -0000

Hello Erik

Many thanks for your review!

My 2 cents:

> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> [ section 12 ]
> 
> * Ignoring an invalid RH3 header by the end host (I'm assuming this
>   means that segments left > 0) doesn't specify whether the packet
>   should be processed (ignore the RH) or the whole packet should be
>   ignored.
> 
>   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.

On the one hand, this spec applies to RPL routers so implicitly it can dictate what a RAN does but not what a RPL unaware node does.

On the other hand, RFC 8200 has:
"
   If, while processing a received packet, a node encounters a Routing
   header with an unrecognized Routing Type value, the required behavior
   of the node depends on the value of the Segments Left field, as
   follows:

      If Segments Left is zero, the node must ignore the Routing header
      and proceed to process the next header in the packet, whose type
      is identified by the Next Header field in the Routing header.

      If Segments Left is non-zero, the node must discard the packet and
      send an ICMP Parameter Problem, Code 0, message to the packet's
      Source Address, pointing to the unrecognized Routing Type.
"

So maybe for RPL Unaware Nodes, we do node need to be normative, just mention the above as the generic protection for all RHs?



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

By consumed we mean segment left == 0; would you have a better term? 

On the side of this discuss and for consistency, draft-ietf-roll-unaware-leaves says:

"
                                                                [USEofRPLinfo] expects the
   RUL to support the basic "IPv6 Node Requirements" [RFC8504].  In
   particular the RUL is expected to ignore the RPL artifacts that are
   either consumed or not applicable to a host.

"

Based on your comments  I changed that text in -27 to 

"
                                                                       [USEofRPLinfo] expects the
   RUL to support the basic "IPv6 Node Requirements" [RFC8504] and in
   particular the mandates in Sections 4.2 and 4.4 of [RFC8200].  As
   such, the RUL is expected to ignore the RPL artifacts that may be
   left over, either an SRH with zero Segments Left or a RPL Option in
   the Hop-by-Hop Header, which can be skipped when not recognized, see
   Section 5."

draft-ietf-roll-unaware-leaves also indicates:

"
5.4.  Support of the Routing Header

   A RUL is expected to process an unknown Routing Header Type as
   prescribed by section 4.4 of [RFC8200].  This implies that the Source
   Routing Header with a Routing Type of 3 [RFC6554] is ignored when the
   Segments Left is zero.
"


> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> [ section 8.1.3 ]
> 
> * 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.
> 
>   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)?
> 

That would be good, I thought "consumed" was more common than it usually appears to be, at least in the RFCs.

Keep safe;

Pascal