Return-Path: 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 ; 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 ; 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 ; 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 To: Routing Over Low power and Lossy networks 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, 9 Jun 2020 10:31:59 +0000 Message-ID: References: In-Reply-To: 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2020 10:32:04 -0000 --_000_MAXPR01MB2493CA901DCD1B1E09640D67A9820MAXPR01MB2493INDP_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Just for the record, I am ok with this. Use of updated target option (which adds ROVR field to the target option) t= o the root will not only simplify implementation but also reduce the contro= l overhead. The 6LR can simply refresh the RUL route entry using DAO and de= pend on Root to refresh the EDAR to the 6LBR. Secondly, ROVR can serve as a verifier for the target IPv6 address in gener= al and its association to the Target is reasonable. Best, Rahul ________________________________ From: Roll on behalf of Pascal Thubert (pthubert) <= pthubert=3D40cisco.com@dmarc.ietf.org> Sent: 09 June 2020 03:35 PM To: Routing Over Low power and Lossy networks Subject: [Roll] Major change in RUL draft on the way =3D> 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 rem= oval of deprecated text on storing mode that was still there by (my) mistak= e in the latest version (draft 16). The realization is that if the RUL=92s = parent uses the Updated Target Option, since we are using non-storing signa= ling only, the root will always get it, there will not be a storing mode gr= andparent 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: =93 (PT] We allow the 6LR to use the old target option without the ROVR. The co= nsequence is that we have all that text about anonymous EDAR. This complexi= ty comes from the days we have storing mode signaling for the RUL=92s DAO, = since we had to live with legacy nodes in the path. This is gone with the n= on-storing mode used all the time for RULs. Since we are updating the 6LR c= an=92t 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-at= taching-6LR (not all 6LRs/6LNs) and the Root. =93 Since we passed WGLC, the question to the group is whether we all agree tha= t the parent 6LR MUST use the Updated Target Option =96 a SHOULD right now.= I=92m doing it in my sandbox as an exercise. If there is no opposition I w= ish to commit it as 17 before the IESG rounds start. Are we OK? Do I miss something? Take care Pascal --_000_MAXPR01MB2493CA901DCD1B1E09640D67A9820MAXPR01MB2493INDP_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Just for the record, I am ok with this.
Use of updated target option (which adds ROVR field to the target option) t= o the root will not only simplify implementation but also reduce the contro= l overhead. The 6LR can simply refresh the RUL route entry using DAO and de= pend on Root to refresh the EDAR to the 6LBR.
Secondly, ROVR can serve as a verifier for the targ= et 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=3D40cisco= .com@dmarc.ietf.org>
Sent: 09 June 2020 03:35 PM
To: Routing Over Low power and Lossy networks <roll@ietf.org><= br> Subject: [Roll] Major change in RUL draft on the way =3D> MUST th= e updated Target option in RUL's parent 6LR
 

Dear all

 

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

 

So one major possible simplification came up, quoting:

=93

(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= =92s 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=92t 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).

 <= /p>

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

 

 

=93

 

Since we passed WGLC, the question to the group is whether= we all agree that the parent 6LR MUST use the Updated Target Option =96 a = SHOULD right now. I=92m 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

--_000_MAXPR01MB2493CA901DCD1B1E09640D67A9820MAXPR01MB2493INDP_--