Re: [Roll] RUL and DAO ACK

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Tue, 09 June 2020 11:40 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 C8BEC3A07F2 for <roll@ietfa.amsl.com>; Tue, 9 Jun 2020 04:40:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.597
X-Spam-Level:
X-Spam-Status: No, score=-9.597 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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=P/iN96Lt; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=J6+XzXWN
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 H7OOcpHrP3n7 for <roll@ietfa.amsl.com>; Tue, 9 Jun 2020 04:40:41 -0700 (PDT)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 551293A07F5 for <roll@ietf.org>; Tue, 9 Jun 2020 04:40:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=119596; q=dns/txt; s=iport; t=1591702841; x=1592912441; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=fe/8ra5pV7hPltxzWpWeBHgQ+6JsUFOut9J9iOBxfOM=; b=P/iN96LtH9RkPDMlzKIoDlJ81UX5SUXatkBMne8rXF9YyKGz86cU5eVb JahVtIezKUOPOS7m7UC9G4kBmC2irNMYD7k9M7D/yBw+3EKbqz3fk99EF L25+4VHhXEzsTmBcUHXCz5fdXR0rGqcvaAhxYYaaj4GvwpoIYUinyZbQS g=;
IronPort-PHdr: 9a23:TulYHRDv1VY3ZFpGXumwUyQJPHJ1sqjoPgMT9pssgq5PdaLm5Zn5IUjD/qw01g3IUJnVrfVehLmev6PhXDkG5pCM+DAHfYdXXhAIwcMRg0Q7AcGDBEG6SZyibyEzEMlYElMw+Xa9PBtUFdrwIVrIrS764TsbAB6qMw1zK6z8EZLTiMLi0ee09tXTbgxEiSD7b6l1KUC9rB7asY8dho4xJw==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BFCAA7dN9e/4ENJK1mHQEBAQEJARIBBQUBggqBIwEuIy8Hb1gvLINkQINGA41AgQGIfo5TgUKBEANQBQsBAQEMAQEYAQwIAgQBAYREAheBfgIkOBMCAwEBCwEBBQEBAQIBBgRthVsMhXIBAQEBAgEBAQoGCAEIChMBASUHDAQLAgEGAhEEAQEhAQYDAgICHwYLFAkIAQEEEwgagn8EAoF+TQMOIAEOlGeQZwKBOYhhdoEygwEBAQWBNgIOQYNKDQuCDgMGgTiCZIJThxwagUE/gRFDgU9JNT6CHkkBAQIBARiBCwQcBBwDAx8GCYJeM4ItjmIRDoMShjKLGo9zTAqCWYg5hVKELIFxhQWCbYkThRWNPY89i1aCUY0rhBoCBAIEBQIOAQEFgWoiDB2BLXAVO4JpUBcCDZBACQMXg0+FFIVCdAIBNAIGAQcBAQMJfIxQAgUhB4IWAQE
X-IronPort-AV: E=Sophos;i="5.73,491,1583193600"; d="scan'208,217";a="507818971"
Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 09 Jun 2020 11:40:39 +0000
Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 059BedO5018030 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for <roll@ietf.org>; Tue, 9 Jun 2020 11:40:39 GMT
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 9 Jun 2020 06:40:39 -0500
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 9 Jun 2020 07:40:38 -0400
Received: from NAM12-MW2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 9 Jun 2020 06:40:38 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AqABDDbMzOAVl+tzybRzDSqfVne+VXlrA9WB2UtAA+WTc/OOSRjoP5e0H4XiTE5D8Cblwdb0AvbDDRSgZrLo2zl3HkFCYAhO4wRqPz8pcWRAYqBJT3cRHykH0cytDWslSr5kl6my1XCNhE8A+LMtPTYfv2SQ3Jtl/LvqGA3LDNaRLYTMvclUYdxWaMsKl0+Q0upyVzs2Lh1SD1ZGjZXtYpyBiUxhmNuKyg/onwJ8INb1JX7rrdh8RJHLQgvQ+pR3cNSYjVwvbWHJ5tC4FSx8QJOhpxPvzeQrWlGnY+Ox1NBc9pMjl+B+WSgrMUjd6J5QkQkfjEB1FwESvDNfZcoraA==
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=fe/8ra5pV7hPltxzWpWeBHgQ+6JsUFOut9J9iOBxfOM=; b=n2sFwpL2yTQr/bOu1E5GBCXbkOjON61wgPPdJptjJj+5LA0aFXPVGmm16cfa8HZ1LRcqVXRhNzfINt3kJ3KNrGPyMeVqeNVm6YkmuurJO44RU/aiU0lKGL9XGxDOTG/yEYdNlgzQ4VLg4IY0gzW+M6/ZEHV2KwYPFSsox457AaYqV3rRSBmva4goT4aBpbufDiCwTbyMVLG5SO0Am36zecSKSy5vdor2CTE66tupVkPsa4uXtRaQZoyGWJwE96nweW5wQTSY6cy/r7qUp0BANdLZeAHMCF2wV8hD1mzThGbDxhiLeIqOuWPCLArZs6NTAe8QjVD6nESGIbGL83qxmw==
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=fe/8ra5pV7hPltxzWpWeBHgQ+6JsUFOut9J9iOBxfOM=; b=J6+XzXWNZkv9IOmMgmEwQ6FI3L4NLu0XxPybo+o3H//6QI60o+gWCod85MCJAIzRE/duV6AoDromBPlt0+C959Z/Kp4Q4y5YMZVdrcYL14vCX40eT5M3QWGkCUwQHWHKGyiY04RacscuftDkREjnCnEMPvIUhPZCdifr8E/kMpE=
Received: from MN2PR11MB3565.namprd11.prod.outlook.com (2603:10b6:208:ea::31) by MN2PR11MB4047.namprd11.prod.outlook.com (2603:10b6:208:13a::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.18; Tue, 9 Jun 2020 11:40:36 +0000
Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::55bb:b065:86c1:1108]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::55bb:b065:86c1:1108%6]) with mapi id 15.20.3066.023; Tue, 9 Jun 2020 11:40:36 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Thread-Topic: [Roll] RUL and DAO ACK
Thread-Index: AdY+MKtEn8bGB13gTHanKJvl2mJdNgAEVACVAACblIAAAUkOvgACInOw
Date: Tue, 09 Jun 2020 11:39:10 +0000
Deferred-Delivery: Tue, 9 Jun 2020 11:39:09 +0000
Message-ID: <MN2PR11MB35655F72847864682D5CE1CAD8820@MN2PR11MB3565.namprd11.prod.outlook.com>
References: <MN2PR11MB3565E25A4EEF6EDF5FBE7DB9D8820@MN2PR11MB3565.namprd11.prod.outlook.com> <MAXPR01MB2493AC8DFB07D6147EC580F8A9820@MAXPR01MB2493.INDPRD01.PROD.OUTLOOK.COM>, <MN2PR11MB3565FD3E45A28DF3D5CDA17DD8820@MN2PR11MB3565.namprd11.prod.outlook.com> <MAXPR01MB249336D2DDF53FE7526100D8A9820@MAXPR01MB2493.INDPRD01.PROD.OUTLOOK.COM>
In-Reply-To: <MAXPR01MB249336D2DDF53FE7526100D8A9820@MAXPR01MB2493.INDPRD01.PROD.OUTLOOK.COM>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [2a01:cb1d:4ec:2200:98:def8:c4dc:aa12]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 229417be-21fd-4b2f-1d0b-08d80c69ed5e
x-ms-traffictypediagnostic: MN2PR11MB4047:
x-microsoft-antispam-prvs: <MN2PR11MB4047A8D22414338D801C2049D8820@MN2PR11MB4047.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 042957ACD7
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 97W4M+eheaysiVMsl3G4o+WyeX25JsPzRObnU0cvtQwpPFn2j0lHmIXDQDIdnFxlz08Xl5Nkf5Ga5R6Cb4bGlZkDKOEflklg/4Nf4guyhE53wyQ3BTQUoJfpsLV6brElFXWn+T1j9OOWlsOx3f3LeYox62ey+HL6L0vlTwV7MEInT6TqmuTRc2Ox+z0RJKxVJybhuZopho1keKX1lhaaYzwuYvUY54NRzICaz3DHjZ0vbT0o1JOw4Xc6MatBAV3KuwZox6XBL4gNddylM1Hlait9wDDfyuzYEJSFiznC9SzUAqamOV2UUG0ccm9pqbyha7PdQdwuHRZk8YCpSwmcSMUmiBKZencBS+BY3VvyRD0K8DY7+DvhOAmd9UefPrzpLLncESEq1PXeMQloKDuK2Q==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB3565.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(376002)(346002)(39860400002)(396003)(366004)(30864003)(86362001)(5660300002)(53546011)(6506007)(66556008)(66476007)(6666004)(83380400001)(76116006)(64756008)(66446008)(66946007)(52536014)(33656002)(71200400001)(66574014)(166002)(45080400002)(478600001)(316002)(966005)(7696005)(55016002)(8676002)(8936002)(2906002)(9686003)(6916009)(186003)(559001)(579004); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: adSRBmbN05xlK8/oEbJmND94X5EiKNjwk1eZuTNuzGFR864fexDAlPR+VRkRVT4oFVAt2L51CoISIs35KjCGs3AERupJNsiuuAm0bckR5YEC0g5DhWfnAtJfBHxx6t7hhL4RlrgHx+6yK+Pq2+PObZSluWvX6kc29A3khHIrfRsxGhMdlzjJClqs57q3Q+dU6pDGfPT10X77ByrE4uuYIpnSnbxCQsd2vumQP54Rnzq1dNkc48PRCbS9HzZNeLtCKpsKNYlqci3M69H7cYNZQSTD0Ly2XYQzcvK3fETXkDv95urfmg7UojabUvsWW44eppvu/ZZCgbHIsNW95irj5TYaBBANbWs2VgpqzZRUpsuuusTetG3C7TAOnnrqBO9ddgdVFeSPfHw3KzmGjV9B6RVkLWZLj+wj+KQtI9qSMsQKn0tDzAcbDOsxch930MokiC17H8ClS+Y++2hkIOo+l362uJQmqXoh+IqksNdIMy9g0AzzMw/oJMZ7Be6WgsigIcWMec1/3Sq+EDYINHJceRzeVn0FdzhEDOri7cC3US8=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_MN2PR11MB35655F72847864682D5CE1CAD8820MN2PR11MB3565namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 229417be-21fd-4b2f-1d0b-08d80c69ed5e
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jun 2020 11:40:36.5313 (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: nL9EcTNfa9ATOAZU6CqGZ4lE7fdyyrIGK2aj3FwpgNZSvoCYg8HZ5TEegYqgvTLzVcrvn7nZaq7+NWbPsatlQg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4047
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.13, xch-aln-003.cisco.com
X-Outbound-Node: alln-core-9.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/b7AuRq0b631UN5F718YrCjB_KKw>
Subject: Re: [Roll] RUL and DAO ACK
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 11:40:46 -0000


> The new flag and alignment are on the way, I agree. Note also that the original Target Info would not let you do what you asked for, which means that you will need to use the updated target information or stand on the border of the law.



> [RJ] The 6550 Target Option syntax supports what I need but I agree that there is no explicit wording in 6550 to do that. I have attached a sample pcap with DAO message with prefix-length=64 and the full IPv6 address is carried. The root can infer based on the Option Length that the full address is present and use prefix-length for routing entry handling.



See https://tools.ietf.org/html/rfc6550#section-6.7.7



   Target Prefix: Variable-length field identifying an IPv6 destination
         address, prefix, or multicast group.  The Prefix Length field
         contains the number of valid leading bits in the prefix.  The
         bits in the prefix after the prefix length (if any) are
         reserved and MUST be set to zero on transmission and MUST be
         ignored on receipt.





There are things you “can” do and yet violate the law. And there are cases when changing the law is a good idea…



Take care,



Pascal


From: Roll <roll-bounces@ietf.org> On Behalf Of Rahul Jadhav
Sent: mardi 9 juin 2020 12:44
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Subject: Re: [Roll] RUL and DAO ACK

Please find my rsp inline.


Well,



The new flag and alignment are on the way, I agree. Note also that the original Target Info would not let you do what you asked for, which means that you will need to use the updated target information or stand on the border of the law.



[RJ] The 6550 Target Option syntax supports what I need but I agree that there is no explicit wording in 6550 to do that. I have attached a sample pcap with DAO message with prefix-length=64 and the full IPv6 address is carried. The root can infer based on the Option Length that the full address is present and use prefix-length for routing entry handling.



I started a separate thread to confirm the change on MUSTing the use of the Updated target information in the RUL parent. You seemed to agree on that change, please reply on the new thread “Major change in RUL draft on the way…”.



[RJ] replied.



As for this I did not want to MUST the DCO. On the contrary I wanted to MUST the “K” flag in the DAO from the RUL parent so we always expect an ack (though it is SHOULD in RPL to send a DAO ACK upon “K” set). So, good, bad idea?



[RJ] Mandating "K" flag is good in this context. The way I see it, it is not a bad idea to clearly mandate the parameters required for a new mechanism such as RUL if it simplifies implementation and can reduce debugging issues. Imo, a RUL MUST never get an NA(EARO) till the path to the root for the RUL is established.





Take care,



Pascal









From: Roll <roll-bounces@ietf.org<mailto:roll-bounces@ietf.org>> On Behalf Of Rahul Jadhav
Sent: mardi 9 juin 2020 11:50
To: Routing Over Low power and Lossy networks <roll@ietf.org<mailto:roll@ietf.org>>
Subject: Re: [Roll] RUL and DAO ACK



Hi Pascal,



I believe we are on the same page with regard to DCO handling. All I was suggesting is not to change the existing text to MUST the DCO.

The only change expected, imo, is the new flag in the updated target option and the alignment fix as discussed.



Regards,

Rahul





Hello Rahul



[PT] We allow the 6LR not to request a DAO ack. This causes an async DCO in case of trouble. Should we MUST it?



[RJ] I am not sure if we should MUST it. The Root may want to use DCO only in async case and use DAO-ACK with negative status (even without explicit ACK request in DAO, 6550 allows this). Another point is, with Non-storing DAO, intermediate 6LRs do not install the routes for RUL. Thus, the need for explicit DCO is even less necessary. DCO will be used to only clear the NCE on the attaching-6LR. Depending on the deployment there may be other ways to handle that cleanup.

 [PT] I’m not sure what you want to tell us. Do you mean we should not use DCO?



As I see things:

- We already use the DCO for asynchronous errors, e.g., to indicate moved and removed in the backbone router. These are asynchronous errors that are beyond the scope of DAO-ACK. It seemed a lot cleaner to use DCO that is clearly asynchronous. I need to clarify that the DCO goes straight to the parent 6LR, it’s obvious but the words may be missing. Also the main spec indicates that only DAO and DAO ACK have a scope wider than link local

- The DAO-ACK is typically requested, using the ‘K’ flag in the DAO

- The DAO-ACK can be sent when not requested, upon error processing the DAO. Remember we did not have the DCO at the time so we needed something. But the 6LR will not wait for the ack if it did not ask for it, so it will send a positive EARO and then if the ack comes in with a bad status, it will have to break the just formed NCE => Not forcing the DAO ACK request creates additional code paths and error scenarios. The current text suggests to use DCO instead of DAO-ACK to avoid the need to support both the unexpected DAO-ACK (on error) and the DCO to trigger async clean up.

- There is no special mandate to set the ‘K’ flag in non-storing vs. storing though in the latter case it is more important since it can act as a root ack.

So:

I’m OK to change and send an async DAO-ACK upon error processing the DAO but I do not see that this eliminates the need for DCO, it just creates more code paths (complexity).

OTOH forcing the use of eth ‘K’ flag ensures that the positive EARO is only sent if the route was effectively injected. This is a considerably cleaner.

For now I’ll be adding the flag and the alignment change : )

Please let me know your thoughts.

Pascal







From: Roll <roll-bounces@ietf.org<mailto:roll-bounces@ietf.org>> On Behalf Of Rahul Jadhav
Sent: mardi 9 juin 2020 04:25
To: Routing Over Low power and Lossy networks <roll@ietf.org<mailto:roll@ietf.org>>
Subject: Re: [Roll] RUL and RootACK



Hi Pascal, Please find my comments inline.



________________________________

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: 09 June 2020 01:10 AM
To: Routing Over Low power and Lossy networks <roll@ietf.org<mailto:roll@ietf.org>>
Subject: Re: [Roll] RUL and RootACK



Hello Rahul:



All good questions, I’d like the group to consider this.



There’s complexity in the draft for 2 reasons:

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



  1.  We allow the 6LR not to request a DAO ack. This causes an async DCO in case of trouble. Should we MUST it?

[RJ] I am not sure if we should MUST it. The Root may want to use DCO only in async case and use DAO-ACK with negative status (even without explicit ACK request in DAO, 6550 allows this). Another point is, with Non-storing DAO, intermediate 6LRs do not install the routes for RUL. Thus, the need for explicit DCO is even less necessary. DCO will be used to only clear the NCE on the attaching-6LR. Depending on the deployment there may be other ways to handle that cleanup.



Now in details to your points

  1.  Section 9 says that all the section flows assume "P" flag to be set essentially meaning that Root has Proxy capability... also meaning that 6LR should refrain from sending EDAR directly (as per section 5). However, the first registration flow Figure 5 in sub-section 9.1 shows that the 6LR is sending the EDAR.

Yes, this is a summary, I can fix it easily by adding “refresh”. The normative text indicates that the first and possibly the last EDARs must be sent directly. The extra complexity in the last depends on whether the 6LR uses the updated target option. If it does, the 6LR only sends the first EDAR (for DAD) and no more.



[RJ] Yes, I feel "refresh EDAR" as a term will help.

  1.  Figure 4: Do we need alignment to 4-byte boundary? Octet alignment should be enough and will save bytes for odd prefixes.

Can do.

  1.  Updated Target Option: There is one restriction with updated target option. Earlier it was possible to send partial prefix but full target address, for e.g., Let's say the target address is fd00::1234/128 but the target node also manages the prefix fd00::/64. It was possible to send full fd00::1234 but set the prefix length to 64. This syntax is needed for future extensions such as RootACK wherein the Root needs to send the RootACK to the Target node even though the target node has advertised only a prefix (and not the full address). With updated target option, this is no more possible!

Hum; maybe we could add a flag that says that the address is in full 128 bits and is a valid address of the originator of the DAO? This would avoid implicits…



[RJ] This works great for me.

  1.  Section 9.1 says, " If it is successful, the 6LR creates an NCE and injects the Registered Address in RPL using DAO/DAO-ACK exchanges all the way to the RPL DODAG Root." This wording reflects DAO storing MOP behavior.

Agreed, I’ll fix that to “using a DAO/DAO-ACK exchange with the RPL DODAG Root”



[RJ] Works great.



Please let me know your thoughts;

Pascal







From: Roll <roll-bounces@ietf.org<mailto:roll-bounces@ietf.org>> On Behalf Of Rahul Jadhav
Sent: lundi 8 juin 2020 18:02
To: Routing Over Low power and Lossy networks <roll@ietf.org<mailto:roll@ietf.org>>
Subject: Re: [Roll] RUL and RootACK



Thanks Pascal,



Few comments:

  1.  Section 9 says that all the section flows assume "P" flag to be set essentially meaning that Root has Proxy capability... also meaning that 6LR should refrain from sending EDAR directly (as per section 5). However, the first registration flow Figure 5 in sub-section 9.1 shows that the 6LR is sending the EDAR.
  2.  Figure 4: Do we need alignment to 4-byte boundary? Octet alignment should be enough and will save bytes for odd prefixes.
  3.  Updated Target Option: There is one restriction with updated target option. Earlier it was possible to send partial prefix but full target address, for e.g., Let's say the target address is fd00::1234/128 but the target node also manages the prefix fd00::/64. It was possible to send full fd00::1234 but set the prefix length to 64. This syntax is needed for future extensions such as RootACK wherein the Root needs to send the RootACK to the Target node even though the target node has advertised only a prefix (and not the full address). With updated target option, this is no more possible!
  4.  Section 9.1 says, " If it is successful, the 6LR creates an NCE and injects the Registered Address in RPL using DAO/DAO-ACK exchanges all the way to the RPL DODAG Root." This wording reflects DAO storing MOP behavior.

Best,

Rahul



________________________________

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: 08 June 2020 10:11 PM
To: Routing Over Low power and Lossy networks <roll@ietf.org<mailto:roll@ietf.org>>
Subject: Re: [Roll] RUL and RootACK



Dear Rahul (as Shepherd), and all



I just submitted a correction of the RUL draft that removes the storing mode section.

Since the publication was already requested, can you please make a pass to validate the diffs?





The IETF datatracker status page for this draft is:

https://datatracker.ietf.org/doc/draft-ietf-roll-unaware-leaves/



There are also htmlized versions available at:

https://tools.ietf.org/html/draft-ietf-roll-unaware-leaves-16

https://datatracker.ietf.org/doc/html/draft-ietf-roll-unaware-leaves-16



A diff from the previous version is available at:

https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-unaware-leaves-16



Many thanks indeed!



Pascal



From: Roll <roll-bounces@ietf.org<mailto:roll-bounces@ietf.org>> On Behalf Of Rahul Jadhav
Sent: vendredi 5 juin 2020 09:45
To: Routing Over Low power and Lossy networks <roll@ietf.org<mailto:roll@ietf.org>>
Subject: Re: [Roll] RUL and RootACK



This clarifies all for me. Thanks Pascal, Rabi.

________________________________

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: 05 June 2020 02:46 PM
To: Routing Over Low power and Lossy networks <roll@ietf.org<mailto:roll@ietf.org>>
Subject: Re: [Roll] RUL and RootACK



...And for this I’m the one confused. I’m confused that I never removed that section when we decided to use NS signaling for RULs. It’s like that typo that the author can read 10 times and never see.  I need to make a pass!

Great catch Rahul !!!



Pascal



Le 5 juin 2020 à 04:08, Rahul Jadhav <rahul.ietf@gmail.com<mailto:rahul.ietf@gmail.com>> a écrit :



Thanks Rabi, I missed/forgot the IP-in-IP encap part. So source routing is not needed to be supported in RPL network even if RUL is advertised to root in NS-MOP.



But still, I don't understand Figure 9 in unaware-leaves draft. It shows RUL target advertisement using DAO in storing MOP.



On Fri, 5 Jun 2020 at 09:18, rabi narayan sahoo <rabinarayans0828@gmail.com<mailto:rabinarayans0828@gmail.com>> wrote:

Hi

I think here we have two things to address

1- Advertise the RUL address to DODAG root.

2- Data plane communication between the DODAG root and RUL.



Irrespective of RPL network operate in storing and non-storing mode advertisement of RUL target address to the DODAG root will happen using Non-Storing mode DAO.

For data packets, from DODAG root to RUL, the root needs to use Ipv6-in-Ipv6 encapsulation if the RPL network is operating in storing mode of operation and Source routing in case of a non-storing mode of operation.



Thanks

Rabi



On Fri, Jun 5, 2020 at 6:23 AM Rahul Jadhav <rahul.ietf@gmail.com<mailto:rahul.ietf@gmail.com>> wrote:

Thanks Pascal,



But I am more confused now.

Figure 5 [1] attaches the RUL in the RPL network in Non-storing mode.

Figure 9 attaches the RUL in the RPL network using storing mode.

This is what I always thought.



If RUL "always" uses non-storing signalisation then what does figure 9 represent?



Also if RUL always uses NS-MOP even if the RPL network is in storing mode, doesn't it raise a basic question that the RPL network has to mandatorily support source-routing regardless of the MOP? Currently in my network source-routing is not enabled if RPL is operating in storing MOP.



[1] https://tools.ietf.org/html/draft-ietf-roll-unaware-leaves-15#section-9.1.1



On Thu, 4 Jun 2020 at 23:34, Pascal Thubert (pthubert) <pthubert=40cisco.com@dmarc..ietf.org<mailto:40cisco..com@dmarc.ietf.org>> wrote:

Hello Rahul



You should look at fig. 5 in https://tools.ietf.org/html/draft-ietf-roll-unaware-leaves-15#section-9.1.1 not fig. 9 since we are using Non Storing signalisation for RULs in all cases. IOW the root ack problem does not exist for RULs.



More details:



The idea is for the root to answer a non storing DAO with a DAO ack to the sender.



Normally In NS mode the sender is the RAL that advertises its parent as transit and the DAO Ack serves as root ack and confirms reachability.



In the RUL case, the Root answers to the parent. That answer confirms to the parent that the RUL is reachable and serves as root ack. Then the parent sends the NA(EARO) which confirms reachability to the RUL.

Are we good or do I miss something?



Pascal



Le 4 juin 2020 à 15:00, Rahul Jadhav <nyrahul@outlook.com<mailto:nyrahul@outlook.com>> a écrit :



Hi Pascal,



Last we discussed handling storing mode RUL flow with RootACK in a way that NA is sent to the RUL after it gets the RootACK. This way RUL can initiate its app traffic once e2e path is established.



Figure 9 in https://tools.ietf.org/html/draft-ietf-roll-unaware-leaves-15#section-9.1.2 handles Storing mode First registration flow for RULs.



My problem is (consider the figure 9), how will the Root know whom to send the RootACK. In the regular cases, the target node in DAO is the destination for RootACK. But in this case, the target is RUL and RootAck cannot be sent to RUL. For external targets, can we use ParentAddr in Transit Information Option to send this field? Anyways the 6LR indeed is the parent node for RUL.



Any thoughts/suggestions?



Thanks,

Rahul

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

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

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

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