Re: [Roll] P-DAO request

"Turner, Randy" <Randy.Turner@landisgyr.com> Wed, 09 June 2021 23:47 UTC

Return-Path: <Randy.Turner@landisgyr.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 4E6F83A2B52 for <roll@ietfa.amsl.com>; Wed, 9 Jun 2021 16:47:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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_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 (1024-bit key) header.d=landisgyr.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 ZDXXK3g4NPCU for <roll@ietfa.amsl.com>; Wed, 9 Jun 2021 16:47:50 -0700 (PDT)
Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2124.outbound.protection.outlook.com [40.107.22.124]) (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 3F5833A2B55 for <roll@ietf.org>; Wed, 9 Jun 2021 16:47:49 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XeIdR1g1JUksS4rNrIpR8WMItEnPo4Z9J5HbVH6sSRgKM0JY9ybfllx3S/rM2st52VwNqAen/s/DUGam4derh7EJBQPROJquyc127a5A7l93j+jACEfLhXxZVTQWYdJb+8MjHaGojYZNlKOjHogH9Vyp8eZMuML/UDMQPWvFWazAUHfI7XLmgAIG00AxJ3vWeFQPX2eoyY0uvWj/nfX4OuEDl59jkgfABQ4ig0aYIb1nyvfSXdZsD4MeOfdaoMX+W4VfxDzeX91eRwAyBpy4upTpuNWsh3zrSxTeIWSvCVZAp/Ml+ES5n4Riv1314qNCdg1MU3ufRN91zuHf5C/IOg==
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=lTl+W8tAp58qKwdH9sP8huJ67M351zS8kExPqOGDOmE=; b=bWEHzn907+D1gBrsHFUu9K9JHLwUCbpUz5AxqJCZ9sD7Lj02EhAsURVWpAChxhZGCCnVG5omn1X873fObqf5X+payaHXSoxwrA/IJhsTGbQrGsh0fNCdB5QnaA77HK3lfgSqrWiVsmu6w6DJodOgx88I3huv5on+m1/p8JBybvvFHQH5lO7fbVEB/lP1pra8cIVznU6CqKABTPrN7ntWVbnkUZ1bj9GN6y7sHsyNDGtVR6t1VeUCXu6KNdUsrNU4rexBQvvjZiulq7LRBw+yh232yuIso5dZNk7T7PgjYqSmfisXt4qUPVlmGqSz+uPoMpxWY6aQOeslisYIyojypA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=landisgyr.com; dmarc=pass action=none header.from=landisgyr.com; dkim=pass header.d=landisgyr.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=landisgyr.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lTl+W8tAp58qKwdH9sP8huJ67M351zS8kExPqOGDOmE=; b=sp+/VQTbY0bd/cJqShyMokM2Q5W9EOX9n/TnJ4tVg0jikoHpl68zsTnQLySLBizV1vzXjqDHMqruUAgxttHeA+Yels7wGV9N7oygKTVKpmaev1x/1GDyMLdyi33Cr0r0oX2fTZKS8LbPQF6XmiwUEC1tJuOh/f6CnlFKzZklRH4=
Received: from PR3PR01MB8114.eurprd01.prod.exchangelabs.com (2603:10a6:102:179::6) by PR3PR01MB8038.eurprd01.prod.exchangelabs.com (2603:10a6:102:175::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4219.20; Wed, 9 Jun 2021 23:47:46 +0000
Received: from PR3PR01MB8114.eurprd01.prod.exchangelabs.com ([fe80::f5fb:fe0d:8414:2818]) by PR3PR01MB8114.eurprd01.prod.exchangelabs.com ([fe80::f5fb:fe0d:8414:2818%9]) with mapi id 15.20.4219.021; Wed, 9 Jun 2021 23:47:46 +0000
From: "Turner, Randy" <Randy.Turner@landisgyr.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Thread-Topic: P-DAO request
Thread-Index: AQHXXI4xD2FCa7DVekerV59EhPefUKsLmT6wgAC51LM=
Date: Wed, 9 Jun 2021 23:47:46 +0000
Message-ID: <PR3PR01MB8114E955B8E566839DA0844380369@PR3PR01MB8114.eurprd01.prod.exchangelabs.com>
References: <PR3PR01MB8114EC6BFD17F649810E772580379@PR3PR01MB8114.eurprd01.prod.exchangelabs.com>, <CO1PR11MB488137400B0BE37477F81B3CD8369@CO1PR11MB4881.namprd11.prod.outlook.com>
In-Reply-To: <CO1PR11MB488137400B0BE37477F81B3CD8369@CO1PR11MB4881.namprd11.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_724d29b2-602f-4b77-ba15-b7b42511c7c5_Enabled=True; MSIP_Label_724d29b2-602f-4b77-ba15-b7b42511c7c5_SiteId=ee2cd48b-958f-4be4-9852-b8f104c001b9; MSIP_Label_724d29b2-602f-4b77-ba15-b7b42511c7c5_SetDate=2021-06-08T17:46:22.1745247Z; MSIP_Label_724d29b2-602f-4b77-ba15-b7b42511c7c5_ContentBits=0; MSIP_Label_724d29b2-602f-4b77-ba15-b7b42511c7c5_Method=Standard
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=landisgyr.com;
x-originating-ip: [2601:c6:c780:1e1d:5858:2871:e89:a7bc]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: a169927e-594a-45b0-e0d7-08d92ba0fb86
x-ms-traffictypediagnostic: PR3PR01MB8038:
x-microsoft-antispam-prvs: <PR3PR01MB8038E9FCBCFDF84214D0DD5880369@PR3PR01MB8038.eurprd01.prod.exchangelabs.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 6C8JN6t/8vF4Lw1eRsMozk4MhaMvBNg9efGaScQe+zn64qSk/+wVbb4ax2ZQmFEIb/JlXMmCIYCO7+mRR9BpBMxcn6cj+V7y7739zQxSv8pj4hJ9bpkbzFHLd4rj3GblMukyoZ5Anl9u1xDOElmKiOQw00hvmDMXKPzoht/L+4ScRoEDR9u6rnPVgqtjpwgA1iywI7ulcGcKEVe4LU00uP18UG+9MOgpH3hiqmitiPEOQ6srzYMpo3QRGsVoKzRTfOZDH//u/oHhyEmdUSKvKiYIZJvQVP3JNYUwvQ6+6SHn9wO24p1OlklYGqZsG6ZNpVhmJbP1mDHwsQzg751sOJpFWMQIztElShf7LFU0q7lL5sAsgiV5+7TYnPv7jKVgCf3EMt1CZnwwBUqktAnFb3Zhlmisf9YPyhVSs4tKejcIkUP+RynSIE30OJKFbwoawAWuSvXPIMFPZ6ToyaHXKLi9xto8LbingOxjfEYu9L1vHQ5J0u32JL6ZYICshajgqUMnMY5y3DTu+CRCrHyaSMkEpTICwkoDPdGq9zpKStW5hqnSe3aMBABg7kcrIiAt6YKjRrpOG3KiwRAh0wEhZ1GafvzRUh+MMjGDVR4JY1E=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PR3PR01MB8114.eurprd01.prod.exchangelabs.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(396003)(39850400004)(346002)(136003)(376002)(66946007)(66556008)(86362001)(66446008)(64756008)(52536014)(66476007)(91956017)(76116006)(316002)(55016002)(8936002)(3480700007)(122000001)(6916009)(38100700002)(83380400001)(2906002)(71200400001)(478600001)(9686003)(5660300002)(8676002)(6506007)(53546011)(186003)(33656002)(7696005); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: =?Windows-1252?Q?Xl1koF41KIUqEnBUVeSoHc3d2g6Dx65D2zKA48NHUgYChy+hjEyE3bU4?= =?Windows-1252?Q?JSwzOPf/tJo8h6Qssqlk9m9Ft9b7X0SSzeGt0peOoJ9htuTgTuboX6FF?= =?Windows-1252?Q?Ss9/cctW4yAx2Lp/FvivW/QIPrc0f+Sf7FPntAmonfVDtQRy2+pcwST2?= =?Windows-1252?Q?UQme84q+9Yf9aVED4qPWt9np8cet8MNnBYDJEWWGAS6pKvThA6TN+rgC?= =?Windows-1252?Q?y/KzlH9lyBbfZxTcsNnuL1dCT603TsedWC72F6eGyViBe4ATgyRqb28/?= =?Windows-1252?Q?ZD25zP1EWWIZFkCoXEXivaoCijW8G6WismQpV5c0d9YTy9D3cOzgGrCq?= =?Windows-1252?Q?aZuGsCUCnyzGmd9PAedEqNSnGvl+SAAh8FmR18cyYm+P7L/noRJWxZM2?= =?Windows-1252?Q?YpNSvQWillUQEL3oAUuAn7NRfJY6bZgll0f8sge9NCG/xS3h8dR7JzCK?= =?Windows-1252?Q?yRtpRfpiWFKttbMe6A5SSYJuqvtEEZploScu+TnPJPOjOpGLoDpJfETH?= =?Windows-1252?Q?dj6/uhTRJoynbyFJbehzSsBqQALediKlWyph8LEn+mtKr+uV4bo7vTO5?= =?Windows-1252?Q?UtBYQO+rLP7jhIXtZdV6I2j4UHlYfGu4QsSndtvGJMOUnqqlu/LmYJA2?= =?Windows-1252?Q?d8pHSKAp9r0prvDa+nFDQQgxk4ViWzyismxm0MRT6z0w/P7xWWpCSxz+?= =?Windows-1252?Q?Yl3wb9zjC04X8uXaZEpYzk8eSZimJy+DptGZqc8XoiQpqOhmM2dq79UP?= =?Windows-1252?Q?V7Yku/1sfW2AOBuB20/vdFStzw7Op9kwDHsw/gFI8y0IZBnshSj2Ijlr?= =?Windows-1252?Q?663EhX0XJt84XwJlBNz+XPJPt+dLm8vgn0+h/g0JBWg+tpNukjcHNvzO?= =?Windows-1252?Q?VQiHlxBvSiF9/7jzA8hSPdX7ZZ6hT8HuXHeVmTxaISnLf0J4bW9gxgIY?= =?Windows-1252?Q?jUrYQldcRdvZpMRXtgZkfWWE/+xtXPW9P4+XkG5O3aCwpfGynr2kO/nu?= =?Windows-1252?Q?HGXNnVpwX/u7tUszPSLpc1e2ofzJGQwn34Id7htJ1mqoCJgU2ztNCLfU?= =?Windows-1252?Q?WtPu7TjgVidhc4qwnJS5BulaNcf/E8OORPHfg8trTV+MY/o9OBXkMo37?= =?Windows-1252?Q?5rTWTx52LMemK1b6ycIV0CgwtWDAcnt2DXpHpXaB13CM7DaDGjLh9sPR?= =?Windows-1252?Q?ynbaknp7KJ45CFhE6uEXi8aHCDBo4RvGmglHypszkPrzYAhMjPZFSmVB?= =?Windows-1252?Q?tx928In9BBp8uCzHoyU4V/axKwSbgO78+FwL1pPXbIq5sUSKOqdI+CK9?= =?Windows-1252?Q?VyA3RtrAedkgM1D2rYVhsuNzoVMx2FmXsmntvBO3yLDJxotV6hT2ILX3?= =?Windows-1252?Q?vnEhKeEKFhgge8BAKmxcG89Qtu9Qz13cwljNE5xo59SgjSB7xmVdv6XY?= =?Windows-1252?Q?BPJRM/GQoApEOWsDN8CoD2KTkVfa7+yqs82kwN/XE6LLIrSf1GFMdOgx?= =?Windows-1252?Q?qyXOUQkKvz+JgnGeFfEduYh4OUrGvA=3D=3D?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_PR3PR01MB8114E955B8E566839DA0844380369PR3PR01MB8114eurp_"
MIME-Version: 1.0
X-OriginatorOrg: landisgyr.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: PR3PR01MB8114.eurprd01.prod.exchangelabs.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a169927e-594a-45b0-e0d7-08d92ba0fb86
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jun 2021 23:47:46.3870 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: ee2cd48b-958f-4be4-9852-b8f104c001b9
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 5Aw/AI0i6OQsYOByT5S0YFE8fCwmy9tVmuWokyd3TNlFtavBnCt3sFcgiOPLPp/SmyTZvmLt0M/YlBUWOskEpaRsHsE9sQfwQVf263wC0dY=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PR3PR01MB8038
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/5wYkvuA2cqH-5Asl2qpff6BJFq0>
Subject: Re: [Roll] P-DAO request
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, 09 Jun 2021 23:47:55 -0000

So,  from the draft, it looks like the basic idea is for nodes in DODAG to request routes between itself and another node, for P2P use-cases.  This idea is what I believe the original discussions centered around, and I admit I haven’t been following recent discussions on this draft, but the introduction sounds familiar.

Forgive me if I’m simplifying, but here is  how I was thinking this would work (from my previous email):

node(A) would like to setup P2P communications with node (B), so it issues a P-DAO request to the root/PCE for  a path from (A) to (B).  If this request is successful, the PDR-ACK returns a set of VIAs from (A) to (B).

So (A) can source-route a packet from itself to (B) based on the VIA information.

The root will monitor any change to the projected route, and if the route cannot be maintained, it will asynchronously notify (A).

If this interpretation is correct, then I was thinking that, if the state of the projected route changes (through future DAO/SIO reception by the root), then a new projected route could be calculated and node(A) could be asynchronously notified of new VIAs for its’ originally requested route to (B), without receiving an async notification that the route is no longer valid, and having to possibly perform a new P-DAO request.

Is this possible? Or did I miss something in the latest thinking?

Thanks!
Randy


From: Roll <roll-bounces@ietf.org> on behalf of Pascal Thubert (pthubert) <pthubert=40cisco.com@dmarc.ietf.org>
Date: Wednesday, June 9, 2021 at 8:20 AM
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Subject: Re: [Roll] P-DAO request
Hello Randy

Not sure what you mean by “Your previous track is stale, here’s the new version”. As it goes, the Root can redraw the Track, add segments here,  remove others there, it’s still the same track as long as it is functional, and there’s no provision in the draft to tell the ingress about those changes.

If that does not help, could you please rephrase?

Pascal

From: Roll <roll-bounces@ietf.org> On Behalf Of Turner, Randy
Sent: mardi 8 juin 2021 19:54
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Subject: [Roll] P-DAO request

Hi Guys,

In the -17 draft for P-DAO, section 3.3, a portion of this section says:

A positive PDR-ACK indicates that the Track was built and that the Roots commits to maintain the Track for the negotiated lifetime. In the case of a complex Track, each Segment is maintained independently and asynchronously by the Root, with its own lifetime that may be shorter, the same, or longer than that of the Track. The Root may use an asynchronous PDR-ACK with an negative status to indicate that the Track was terminated before its time.


I think it will be very difficult for the root to maintain tracks, given the spurious nature of topology changes in an RF mesh --- Rather than a PDR-ACK that says the track could not be maintained, could we have something like an async notification that says, “Your previous track is stale, here’s the new version”  as long as the egress point still exists.  Assuming it’s possible that the egress joined another DODAG.

I haven’t read the entire draft yet so I may have missed something that would preclude this capability.

Thanks,
Randy