Re: [Roll] New Version Notification for draft-ietf-roll-unaware-leaves-10.txt

Rahul Jadhav <nyrahul@outlook.com> Thu, 12 March 2020 17:06 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 E5AE03A0DBE for <roll@ietfa.amsl.com>; Thu, 12 Mar 2020 10:06:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, 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 M2ZYx_yberDI for <roll@ietfa.amsl.com>; Thu, 12 Mar 2020 10:06:07 -0700 (PDT)
Received: from APC01-SG2-obe.outbound.protection.outlook.com (mail-oln040092253043.outbound.protection.outlook.com [40.92.253.43]) (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 C25563A0DBD for <roll@ietf.org>; Thu, 12 Mar 2020 10:06:06 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; =?utf-8?q?b=3DVSo1VUSPYO11Honfm5fnIszNGK0Nvrnij6uum0aX/1mih9LcLBD1si9+LmaRg?= =?utf-8?q?vGsSakLRaYBWDrMbjsrH7X6Q1XFclfM79eTIjs1L4ABi6tYZuVowRdUFywYSJr0sz?= =?utf-8?q?wN4ht8FqAsyo0ORnx9csCioFtlqXNWv2v0a8BKrPxJN4XGG6euGB946avKuDZtcxY?= =?utf-8?q?FBj4ki4tJdcZo3HQECAGZI13+joGUD2ujrutooKrxMTEAC+hVg9jkS44hwXwiqvJz?= =?utf-8?q?JA5deQhxWhikbizsEEDGU12W94aKlolvP7Z7lhcTcMkU3xHD1bXXtC5apSlLhgNu6?= =?utf-8?q?WcGvPjAXkspVRo793LAng=3D=3D?=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; =?utf-8?q?h=3DFrom=3ADate=3ASubject=3AMessage-ID=3ACont?= =?utf-8?q?ent-Type=3AMIME-Version=3AX-MS-Exchange-SenderADCheck=3B?= =?utf-8?q?bh=3D4OGS4dpFWrQOHCQJkSOt1qSu0/JDpq1tu++ZUuqZyDM=3D=3B_b=3DCSH9xW?= =?utf-8?q?ltw0yu7RFT8FRBTPzqdwZjN8dZ1PDuaXqi+xT6ue7Jjk2K6I8p2yAK2azu+EOf0Y3?= =?utf-8?q?spxShNUV9JomsHEkz8MM+hsKl2E6qixGpWV7lWSnHj44pkQtfMQ5dTIu7U+CzTieU?= =?utf-8?q?Sspwucm/lz9pIVYu8kCZuPqYbqTlGQ9DNv0bIuCI+70PYyDNgBMh/KzzgrlpfhW+B?= =?utf-8?q?EpxL/fTKaDfh0dDjtXlMdjTfXymp6XLaB/EK63J2HOfycJ1BXp5NaZIPJoGv/TXLL?= =?utf-8?q?LM5yhuWGZepr8tQMoKnSVu0lLI9aM+dlawWWL2+xK4zfGXK/xWOXTGWjwjhZhZthN?= =?utf-8?q?tty57+MyICQ=3D=3D?=
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; =?utf-8?q?h=3DFrom=3ADate=3ASubject=3AMessage-ID=3AContent-Typ?= =?utf-8?q?e=3AMIME-Version=3AX-MS-Exchange-SenderADCheck=3B?= =?utf-8?q?bh=3D4OGS4dpFWrQOHCQJkSOt1qSu0/JDpq1tu++ZUuqZyDM=3D=3B_b=3Dc4KZxe?= =?utf-8?q?tmHKSDzZYojCm06Y/m9Q3FJYRfTHUQ86WR7CTyzOp5zq9iNCYmzA7r93Q5v4xNp9k?= =?utf-8?q?VCfxPc+84XuI+TTh+7kWIcFVC2Aa/YaBZ/2Y62dOeMz1Wfjsniw0qUHNaQpNxezGV?= =?utf-8?q?99SsGyqLZgwvROPpZqgFc2lfd1OBwijvddNDciyKTyNkkUbKo1H2+2EfCjMXESugJ?= =?utf-8?q?+29sk4d4KPLiiSbjEh42IL2vAhEQZbrm/T/qba3s+YrsepIbOueJPgfqodZTv/95t?= =?utf-8?q?WgHwwOfNhlWev5lOFBBy+BTuKJ0nDxMoi8tMtFwe0c7JaIuRa8wEQBEW+qg7UphX4?= =?utf-8?q?ichSUUO7vvg=3D=3D?=
Received: from SG2APC01FT058.eop-APC01.prod.protection.outlook.com (2a01:111:e400:7ebd::3c) by SG2APC01HT057.eop-APC01.prod.protection.outlook.com (2a01:111:e400:7ebd::294) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2814.13; Thu, 12 Mar 2020 17:05:59 +0000
Received: from BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM (10.152.250.52) by SG2APC01FT058.mail.protection.outlook.com (10.152.251.117) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2814.13 via Frontend Transport; Thu, 12 Mar 2020 17:05:59 +0000
Received: from BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM ([fe80::a1ff:5c53:dc37:c050]) by BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM ([fe80::a1ff:5c53:dc37:c050%6]) with mapi id 15.20.2793.013; Thu, 12 Mar 2020 17:05:59 +0000
From: Rahul Jadhav <nyrahul@outlook.com>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>, Routing Over Low power and Lossy networks <roll@ietf.org>
Thread-Topic: New Version Notification for draft-ietf-roll-unaware-leaves-10.txt
Thread-Index: AQHV+Hcezq3im2uH30CiF/oY8K2vzahE/ZyggAAFM7yAAAXZkIAABcnzgAAN4ICAABIong==
Date: Thu, 12 Mar 2020 17:05:59 +0000
Message-ID: =?utf-8?q?=3CBM1PR01MB4020B60754F0C74EBBF9270EA9FD0=40BM1PR01MB4?= =?utf-8?q?020=2EINDPRD01=2EPROD=2EOUTLOOK=2ECOM=3E?=
References: <158402183564.18056.13091739917212256438@ietfa.amsl.com>, =?utf-8?q?=3CMN2PR11MB35659E2E557B7E6F2F4C6DFFD8FD0=40MN2PR11MB3565=2Enampr?= =?utf-8?q?d11=2Eprod=2Eoutlook=2Ecom=3E_=3CBM1PR01MB402062FCAC1CD1E53AED21A?= =?utf-8?q?DA9FD0=40BM1PR01MB4020=2EINDPRD01=2EPROD=2EOUTLOOK=2ECOM=3E=2C_?= =?utf-8?q?=3CMN2PR11MB35650FF2A4E469144D14A7C8D8FD0=40MN2PR11MB3565=2Enampr?= =?utf-8?q?d11=2Eprod=2Eoutlook=2Ecom=3E_=3CBM1PR01MB40209B0841CF999B21B15C2?= =?utf-8?q?FA9FD0=40BM1PR01MB4020=2EINDPRD01=2EPROD=2EOUTLOOK=2ECOM=3E=2C_?= =?utf-8?q?=3CMN2PR11MB35650F3660760BACE22AA9DDD8FD0=40MN2PR11MB3565=2Enampr?= =?utf-8?q?d11=2Eprod=2Eoutlook=2Ecom=3E?=
In-Reply-To: =?utf-8?q?=3CMN2PR11MB35650F3660760BACE22AA9DDD8FD0=40MN2PR11MB?= =?utf-8?q?3565=2Enamprd11=2Eprod=2Eoutlook=2Ecom=3E?=
Accept-Language: en-IN, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-incomingtopheadermarker: =?utf-8?q?OriginalChecksum=3A5595ECB376D7927BF527?= =?utf-8?q?A8C46491A80C954616417CF3449696BEE26EB76C3406=3B_UpperCasedChecksu?= =?utf-8?q?m=3AE4BB7ADD7C4464EA8858231C2E56B13E0104927FBA8D5AA34EA9AD40530D4?= =?utf-8?q?1CE=3B?= SizeAsReceived:7418; Count:44
x-tmn: [2KgqyJYNVj+SLMq9r1SHUWiH7x5rG9pW]
x-ms-publictraffictype: Email
x-incomingheadercount: 44
x-eopattributedmessage: 0
x-ms-office365-filtering-correlation-id: ee3310f1-c6d9-4a96-f8d1-08d7c6a7a301
x-ms-traffictypediagnostic: SG2APC01HT057:
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: =?utf-8?q?GCCoQdb5iaGsNN5NZI/IkEc9qVgTBTq?= =?utf-8?q?SZS09ECX42GIqrw116P3jnkU/WrBSUHRLEc2+luMLmlEhJU1wzq5sFB68akpX76qI?= =?utf-8?q?8SbqJ/er8BZTleCXnxuQI7sIS17yFKvX1Nnrk9tzhVT6pdNnwQYnStJEZvio3Lk0e?= =?utf-8?q?OLYGHqFUTUSV/z4k0LfBE2CJiW6ABzwnqZ6+F6wyKbos82tHGATztRt52HznaiZ6X?= =?utf-8?q?jMcLA3CGA=3D?=
x-ms-exchange-antispam-messagedata: =?utf-8?q?tlDk09FhUxFVcyMiV09kC4C9NRmapQ?= =?utf-8?q?4N/eTDW3nepM6iYlUpX/AO9NcuQccx/M3jpXNJe9v424FVllxvU0JNE5BfZuKFSPj?= =?utf-8?q?HFZH/vlMzRH6VeCxv1LVhukRvl8aYHkZduRRRGKRlXU6squj2rUrmxQ=3D=3D?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_BM1PR01MB4020B60754F0C74EBBF9270EA9FD0BM1PR01MB4020INDP_"
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: ee3310f1-c6d9-4a96-f8d1-08d7c6a7a301
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Mar 2020 17:05:59.2108 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SG2APC01HT057
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/xAVlk9VhUVyBAqRkQa4Zvsq7anY>
Subject: Re: [Roll] New Version Notification for draft-ietf-roll-unaware-leaves-10.txt
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: Thu, 12 Mar 2020 17:06:10 -0000

???? Yes, looks like i have been violating the rfc in our internal implementation to fulfill the use case.
Regarding the use of non storing dao in storing mode for RUL nodes, I am now clear about the whole picture and appreciate the discussion.

Thanks,
Rahul
________________________________
From: Pascal Thubert (pthubert) <pthubert@cisco.com>
Sent: Friday, March 13, 2020 12:49:30 AM
To: Rahul Jadhav <nyrahul@outlook.com>om>; Routing Over Low power and Lossy networks <roll@ietf.org>
Subject: RE: New Version Notification for draft-ietf-roll-unaware-leaves-10.txt


Hello Rahul



RFC 6550 says:



“



9.8<https://tools.ietf.org/html/rfc6550#section-9.8>.8>.  Storing Mode





   In Storing mode, RPL routes messages Downward by the IPv6 destination

   address.  The following rules apply to nodes that are in Storing

   mode:



   1.  The DODAG Parent Address subfield of a Transmit Information

       option MUST be empty.





“



So even if it is a good idea it requires new specs to override RFC 6550.



More below (using P2>)





From: Rahul Jadhav <nyrahul@outlook.com>
Sent: jeudi 12 mars 2020 16:32
To: Pascal Thubert (pthubert) <pthubert@cisco.com>om>; Routing Over Low power and Lossy networks <roll@ietf.org>
Subject: Re: New Version Notification for draft-ietf-roll-unaware-leaves-10.txt









Please find below inline answers. Also, I did not get any objection from 6lo so I added a IANA section that reduces the EARO status range to 0-63, which solves the issue you raised.



[RJ] Yep, that indeed takes care of a major point ??. Please find my [RJ] responses inline.







Regarding this statement,

"Non-Storing Mode DAO messages are used to signal external routes to
   the Root, even if the DODAG is operated in Storing Mode."



I couldn't find any text which provides reasoning to do so. Why non-storing mode DAO is needed and why storing mode DAO won't work?



Pascal> We need the address of the 6LR to terminate the tunnel and remove the artifacts, and the NS signaling will give us that. This is how we removed the hassle of hop by hop link local tunnels that was in the old useofrplinfo.



There is this text which says, "The Non-Storing Mode DAO messaging enables to advertise the 6LR that serves the RUL and injects the route to the Root." This can be achieved even with storing mode DAO with the target as RUL address and transit information containing parent address as anchor 6LR address.



Pascal > Which is not the normal storing mode signaling.



[RJ] Yes, but 6550 does not stop us from doing it. Interestingly, I have a use-case in my deployment wherein I need to send this parent address info even in storing MOP. It helps the root get the complete network graph even in storing mode for visualization purposes (if the admin wants to check how the network is formed, how many hops etc on the root in storing mode).



P2> It does actually, see above



It would be an hybrid. The cool thing with NS is that the external prefixes are not visible inside the RPL domain. Legacy nodes do not have to know they exist. Only the 6LR at the border that inject the external routes and the Root are aware and need to know about the new signaling. Using an hybrid impacts every node.



[RJ] The hybrid may not necessarily impact every node. An intermediate 6LR may decide to ignore that external target in the DAO and that would still be ok. In this case, the signaling will work through next common ancestor which has to capability to hold/process that kind of info.



P2> which is still an impact; new code to recognize the ‘E’ flag and decide to ignore the address. A legacy node would not do the right thing.



Trying to understand the reason because this mode of signaling has implications (already covered in the draft), particularly that, when the DAG is operating in storing mode, the communication to RUL from other RANs would mandatorily have to be routed through root only. If we use storing mode DAO then this could be optimized. Not sure if I am missing anything?



Pascal > Well, yes, we could have done that as well. The path could be optimized but

*  it would mean that the common parent has to encapsulate to the 6LR, which is an additional function there

* It would also mean that the network has ot be aware of external routes, which may be too many for the SM tables.



[RJ] I am just keen on doing this because it makes things flexible. Anchor 6LR has both options of sending NS-DAO or storing DAO. Intermediate 6LRs also have both options, honor the external target info or ignore it and just pass it on.



P2> I’m happy to discuss it and see if and how we open RPL in that direction. But for short term we’re shipping useofrplinfo and RUL with the low hanging fruit.



Pros and cons I guess. We went for the simple and backward compatible way.



[RJ] Yes, Backward compatibility may be an issue because intermediate 6LRs operating in pure storing mode will try to cache the external target and may not be able to do IP-in-IP at their point. However, handling this compatibility may not be a big challenge. The flexibility this provides is very compelling to me. With DAO projection, we have already entered that zone where the nodes could be hybrid in nature.



PT2> with the capability work we’ll be able to introduce this and more : )





Take care,



Pascal

________________________________

From: Roll <roll-bounces@ietf.org<mailto:roll-bounces@ietf.org>> on behalf of Pascal Thubert (pthubert) <pthubert=40cisco..com@dmarc.ietf.org<mailto:pthubert=40cisco..com@dmarc.ietf.org>>
Sent: 12 March 2020 07:38 PM
To: Routing Over Low power and Lossy networks <roll@ietf.org<mailto:roll@ietf.org>>
Subject: [Roll] FW: New Version Notification for draft-ietf-roll-unaware-leaves-10.txt



Dear all

As discussed with the IOT DIR, this draft is not the gating factor for all cluster C310.
In order to progress I made a full pass on it and fixed a few bugs and misalignments with useofrplinfo.

I believe the doc is ripe for WGLC.

Many thanks

Pascal

-----Original Message-----
From: internet-drafts@ietf.org<mailto:internet-drafts@ietf.org> <internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>>
Sent: jeudi 12 mars 2020 15:04
To: Michael Richardson <mcr+ietf@sandelman.ca<mailto:mcr+ietf@sandelman.ca>>; Michael C. Richardson <mcr+ietf@sandelman.ca<mailto:mcr+ietf@sandelman.ca>>; Pascal Thubert (pthubert) <pthubert@cisco.com<mailto:pthubert@cisco.com>>
Subject: New Version Notification for draft-ietf-roll-unaware-leaves-10.txt


A new version of I-D, draft-ietf-roll-unaware-leaves-10.txt
has been successfully submitted by Pascal Thubert and posted to the IETF repository.

Name:           draft-ietf-roll-unaware-leaves
Revision:       10
Title:          Routing for RPL Leaves
Document date:  2020-03-12
Group:          roll
Pages:          32
URL:            https://www.ietf.org/internet-drafts/draft-ietf-roll-unaware-leaves-10.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-roll-unaware-leaves/
Htmlized:       https://tools.ietf.org/html/draft-ietf-roll-unaware-leaves-10<https://tools.ietf..org/html/draft-ietf-roll-unaware-leaves-10>
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-roll-unaware-leaves
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-unaware-leaves-10

Abstract:
   This specification extends RFC6550 and RFC8505 to provide unicast and
   multicast routing services in a RPL domain to 6LNs that are plain
   Hosts and do not participate to RPL, and enables the RPL Root to
   proxy the EDAR/EDAC flow on behalf of the RULs and RANs in its DODAG.




Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


_______________________________________________
Roll mailing list
Roll@ietf.org<mailto:Roll@ietf.org>
https://www.ietf.org/mailman/listinfo/roll