Re: [Roll] Major change in RUL draft on the way => MUST the updated Target option in RUL's parent 6LR

Rahul Jadhav <nyrahul@outlook.com> Tue, 09 June 2020 10:32 UTC

Return-Path: <nyrahul@outlook.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 0FF153A0B05 for <roll@ietfa.amsl.com>; Tue, 9 Jun 2020 03:32:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-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=outlook.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 rhSzHKF5tVYz for <roll@ietfa.amsl.com>; Tue, 9 Jun 2020 03:32:02 -0700 (PDT)
Received: from APC01-PU1-obe.outbound.protection.outlook.com (mail-oln040092254095.outbound.protection.outlook.com [40.92.254.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABFDE3A0AF5 for <roll@ietf.org>; Tue, 9 Jun 2020 03:32:01 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=g6YVdkQGLXPLWZAbQycApe/qmuVyQ+BJQ79GDga552gibCLOHrNIhQy5yzIXDLYZbbmZDnefZJdlN7QWV6U23R3V62WeMPFsuEo4BNI4hz1U9z0G187tLqwoppEBGS9ta5i0EjueN+ul1ftie3SGtS/VQ8bXg3aODiZSbZvxYbyBHFFx6pQbjVMxfFlNos9gdF3kJrc5A+dO/c093emIQoSgciMHLpSTtBo2PfBWMq2G0cowi7GkufnxbpdHKHPoZXoRY+V156Gti0rewZuFzcLpTGAVSWyZKDvWzxpV7job9TDMuz+MRgQyxwCZ+eT2HLhuFkeWbq19ZBmD4j+NDQ==
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=ct0ufv56WSLsFTqWXn0V7yv4TNKEAXZQefmizG2upKg=; b=MJSvqPotAiRSSNIz73rPujJh8tGaxiPdvoVcbsXNtrrrN94q1az6zQ4yiPIREncdSLalu0jHgSL1gSGMNyP0o2n1AsVcwmP/fHHG3whsV9iq7GaL9mskfDJJTxgtJ1mV09oBjHDxXb65yD3/zc+8ryZbrLc2OgdA7fbXvBcWlpFenUq0RV6+CLc8/iUlodmSF839xRtmCEr7JAPPNTSVYvrGVh+1qUqNYKjmsaZRnGwn182kTcQWV6Ibj6M7qKs8SUIu61r+3fnNYXJpQ+tAT513G4occzCkcxe5w+Xklw1yR3PMP2LrHuOdtFF+MszLAnafoJfbmBIshMVNJTXoFA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ct0ufv56WSLsFTqWXn0V7yv4TNKEAXZQefmizG2upKg=; b=o1J23VKBXYXqtFhQsvh3ZMDmzLxahikQF03eOaNrHpufc8yWkqwSlmHdSlxwm2iO2wn4IYYHlgCfGVdc2XqvIHD2r1fhNZJMcmC3zameBuNGQ2ZhyWKFuBRQW16Fi7iIb63KagoODW2YLaRx8G5ImoWAAQ4KJHeQl0Lj4qe36RcJwPBFBN1GgFNZv9OgyYDNA2U190t2tR32JJKEqxMcRXBPWLUmShzAC74Q9spULaqABnRSuUOdbaioi+rifBpmXBd7kv0bmoW4Q7POUd7xkVA2JOhjq1haq0xvuzpD4wDNLY8we7/SS5a9xnQLjZ6hmpxKwV757gMbGnXd09RE5w==
Received: from HK2APC01FT130.eop-APC01.prod.protection.outlook.com (2a01:111:e400:7ebc::47) by HK2APC01HT117.eop-APC01.prod.protection.outlook.com (2a01:111:e400:7ebc::312) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.18; Tue, 9 Jun 2020 10:31:59 +0000
Received: from MAXPR01MB2493.INDPRD01.PROD.OUTLOOK.COM (10.152.248.58) by HK2APC01FT130.mail.protection.outlook.com (10.152.248.197) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.18 via Frontend Transport; Tue, 9 Jun 2020 10:31:59 +0000
Received: from MAXPR01MB2493.INDPRD01.PROD.OUTLOOK.COM ([fe80::e874:bbdb:9f9e:9564]) by MAXPR01MB2493.INDPRD01.PROD.OUTLOOK.COM ([fe80::e874:bbdb:9f9e:9564%7]) with mapi id 15.20.3066.023; Tue, 9 Jun 2020 10:31:59 +0000
From: Rahul Jadhav <nyrahul@outlook.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Thread-Topic: Major change in RUL draft on the way => MUST the updated Target option in RUL's parent 6LR
Thread-Index: AdY+LzBzhxymOQ5TQVC6CJUhb2B5rwAFxcFz
Date: Tue, 09 Jun 2020 10:31:59 +0000
Message-ID: <MAXPR01MB2493CA901DCD1B1E09640D67A9820@MAXPR01MB2493.INDPRD01.PROD.OUTLOOK.COM>
References: <MN2PR11MB35650274D05A6AEEF31B7846D8820@MN2PR11MB3565.namprd11.prod.outlook.com>
In-Reply-To: <MN2PR11MB35650274D05A6AEEF31B7846D8820@MN2PR11MB3565.namprd11.prod.outlook.com>
Accept-Language: en-IN, en-US
Content-Language: en-IN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-incomingtopheadermarker: OriginalChecksum:855E591B4D8F9D28B5601164F29FFC02E2DA0C3D059DDAFB88B397C75038D10F; UpperCasedChecksum:4E4A7480B79C6EF9B8DDDF98EBC03296BFD709D7FB4A418C9B6A776C8E7CA56F; SizeAsReceived:6987; Count:44
x-tmn: [Ny0qhef3Ij9R6c2W1ZGC84NLEg+YjLRX]
x-ms-publictraffictype: Email
x-incomingheadercount: 44
x-eopattributedmessage: 0
x-ms-office365-filtering-correlation-id: 89964b1f-f68b-4b60-4a87-08d80c605755
x-ms-traffictypediagnostic: HK2APC01HT117:
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: pxlKnrDzSxw0uq6McJzqYwLVN8wPXhPW983Rvnm10wEHwY7VBm3O+32nTYaGxaWbPnbve0z1ecSVumksfnWkjZbQji12Wemr6nxIhLkivby2PS6Xr24uLdApT4Z/N8eafNKIJWMU+xtRM8gHtHINQFB2te3pnxT5bsKvyo4yOVi1dX+zfraoZOKvLtVDefQbdHs4XAqRQvo8a0EQZVjs6g==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:0; SRV:; IPV:NLI; SFV:NSPM; H:MAXPR01MB2493.INDPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:; DIR:OUT; SFP:1901;
x-ms-exchange-antispam-messagedata: IuntHlynEHXfOrX93iyci9o86FlQXGtwwAua6r6Pk1mudrCEzqn/qHyIn5NmJRMseF6f465VK4OBX703hbnHMMkvPqpw+BUjYEywUjpIDHRbsEtzza68W1FG0FTw9I9gx8bO6gu+p3dZ7q101re69w==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_MAXPR01MB2493CA901DCD1B1E09640D67A9820MAXPR01MB2493INDP_"
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: 89964b1f-f68b-4b60-4a87-08d80c605755
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jun 2020 10:31:59.3936 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HK2APC01HT117
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/FphyY5GTLL2VWpP_H6gBN-g10is>
Subject: Re: [Roll] Major change in RUL draft on the way => MUST the updated Target option in RUL's parent 6LR
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: Tue, 09 Jun 2020 10:32:04 -0000

Just for the record, I am ok with this.
Use of updated target option (which adds ROVR field to the target option) to the root will not only simplify implementation but also reduce the control overhead. The 6LR can simply refresh the RUL route entry using DAO and depend on Root to refresh the EDAR to the 6LBR.
Secondly, ROVR can serve as a verifier for the target IPv6 address in general and its association to the Target is reasonable.

Best,
Rahul
________________________________
From: Roll <roll-bounces@ietf.org> on behalf of Pascal Thubert (pthubert) <pthubert=40cisco.com@dmarc.ietf.org>
Sent: 09 June 2020 03:35 PM
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Subject: [Roll] Major change in RUL draft on the way => MUST the updated Target option in RUL's parent 6LR


Dear all



Rahul and I are having a thread on the RUL draft. This started with the removal of deprecated text on storing mode that was still there by (my) mistake in the latest version (draft 16). The realization is that if the RUL’s parent uses the Updated Target Option, since we are using non-storing signaling only, the root will always get it, there will not be a storing mode grandparent on the way that may not understand it and loose it. As of now the root already supports it anyway



So one major possible simplification came up, quoting:

“

(PT] We allow the 6LR to use the old target option without the ROVR. The consequence is that we have all that text about anonymous EDAR. This complexity comes from the days we have storing mode signaling for the RUL’s DAO, since we had to live with legacy nodes in the path. This is gone with the non-storing mode used all the time for RULs. Since we are updating the 6LR can’t we mandate that it uses the updated target option?

If we mandate that it always does, the spec is considerably simpler (like 1 or 2 pages less).



[RJ] Mandating updated Target Option simplifies considerably. And like you mentioned the 6LR needs to be modified anyway. One more thing to point out is that the modified target option needs to be supported only by the RUL-attaching-6LR (not all 6LRs/6LNs) and the Root.





“



Since we passed WGLC, the question to the group is whether we all agree that the parent 6LR MUST use the Updated Target Option – a SHOULD right now. I’m doing it in my sandbox as an exercise. If there is no opposition I wish to commit it as 17 before the IESG rounds start.



Are we OK? Do I miss something?



Take care



Pascal