Re: [Roll] Make P-DAO bidirectional [extends] IETF 109 open Questions on P-DAO

"Li Zhao (liz3)" <liz3@cisco.com> Thu, 26 November 2020 02:44 UTC

Return-Path: <liz3@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 098E73A0BFD for <roll@ietfa.amsl.com>; Wed, 25 Nov 2020 18:44:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.6
X-Spam-Level:
X-Spam-Status: No, score=-9.6 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, 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=AP1qF+As; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=w+7NIYtf
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 2lY4vcQioCNq for <roll@ietfa.amsl.com>; Wed, 25 Nov 2020 18:44:42 -0800 (PST)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10AC43A0BFA for <roll@ietf.org>; Wed, 25 Nov 2020 18:44:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20550; q=dns/txt; s=iport; t=1606358682; x=1607568282; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=DwRg0UYRAroDQNsZkc/I2y9d1ueR2nMe4zQiSmjxYfk=; b=AP1qF+Asu4xnOZnAIrEeSEXSFZHJK+H3RThr9+T/F4vYYWYPghdK8Qhf Lf6yLNKTLgUjouVByTQw3xOLrJd43TQvqocAe+ymOGnEsm2/web50LMim nPxWUGYvbPF22uPkzhYXCjS9Fj+aysGi4kmYvxxgDJcfV5wKWNklxkMJA g=;
X-IPAS-Result: A0DdCADPFL9ffYgNJK1YCoEJgnIvUXxaLy6IBgONY5B/iAaBQoERA1QLAQEBDQEBIwoCBAEBhEoCgiQCJTgTAgMBAQEDAgMBAQEBBQEBAQIBBgQUAQGGDwglDIVyAQEBBBIuAQElEw8CAQgRAQIBAQEeCgcyFAMGCAEBBBMIGoMFgX5XAy4BDqMjAoE8iGl0gTSDBAEBBYE3BAxBgyYYghADBoE4gnOCZk6HGYIbgRABQ4FRUC4+gQSBWQIDAYEhDQ8gHgYHCYMUgiyBRgGPN4oYnUIGBIJuiRaJX4hVgmA7ihyUVp5mkSiEOgIEAgQFAg4BAQWBbSGBWXBQgR6BS1AXAg2HfooUhRSFRHQ3AgYKAQEDCXyMai2CFwEB
IronPort-PHdr: 9a23:Pdk2Lh/9x/7wnf9uRHGN82YQeigqvan1NQcJ650hzqhDabmn44+7ZRaN5PhxghnOR4qIo/5Hiu+DtafmVCRA5Juaq3kNfdRKUANNksQZmQEsQavnQU32JfLndWo2ScJFUlI2/nynPw5SAsmtL1HXq2e5uDgVHBi3PAFpJ+PzT4jVicn/1+2795DJJQtSgz/oarJpJxLwpgLU5cQ=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.78,370,1599523200"; d="scan'208,217";a="637602055"
Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 26 Nov 2020 02:44:40 +0000
Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 0AQ2iehl019973 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for <roll@ietf.org>; Thu, 26 Nov 2020 02:44:40 GMT
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 25 Nov 2020 20:44:39 -0600
Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 25 Nov 2020 21:44:38 -0500
Received: from NAM12-DM6-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 25 Nov 2020 20:44:38 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GTIlUJUtLSZf402UrIp2sJ+ayI4Mdt1RsJ0/z5Iu3ejvNKUljQZCHdEDInXX8unP+LnMWcqKpTjF2rxyB8SkGzWL5PiT8/Pw/VCwmhpRhDF90rVsptUyxw/m5mmHdAlKHPcBGm41wcI9hn6QfoNS+O3YowMC1P88wiX4Gd8x/D1uqXLQ7nEyqjSBGrXeRp5QgWMH46vVQpiag2SHvebGkJhT/pCAOhHTdMYFqW8P+Jaixq2R2mBcir51qInS70yZIY2l9yWaZKxHJqiMbhhF9AZqytHJEjOAXZ6vbPfdYxGGCd2t6rJOo/vqT+0BlzO2hEUfQ6gGX76568/yPZ7TuA==
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=5D+gP7li6Ghv9qx4wjkrfh9khaBFC9nCDBd69HCr0iA=; b=GY9y8wKIPt6oHtzRSvCP0sxbddugIIz/AMODjPdtm+wtYVljvTyS/cIGTDnFF94qFI2HTCZxfdw7qHzkXug4fB1SfVBJeZbvrYOAwPXpXRLbu4J8ZcMYbMJ9EZDHS3kF8VqE1NvbjZ6W5OpJGahMq8ZOEq/51YwEy7EKWORgNeJkItNQx6LtcX/H4OTJGXEQHX9Ui2QytWbd4ZlfMjqL4afmZSKHJmLzLVHtHtr/dQASrIyOwk2e8BqIft5rkZ+j5dALKOdCvMu9jQ5zXSsqZv1JaL74H4adMn4sGCuIh4Mt/kWCW803L+tNVHbjrKNiEEhPkmwg9koGfxmHNmTQjQ==
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=5D+gP7li6Ghv9qx4wjkrfh9khaBFC9nCDBd69HCr0iA=; b=w+7NIYtfmyTi0mArrRbsGporvnUDRiEC9gTyAQCRh7/TV5PD5Qlk7sum1eGZRToK9nRvG5k2MDPyErMBiq1JFTmWGqjCAFhe/0YNqie8rvnH8S8CRJcDm6lN+GHjhhfuTJsvYuX6dxFrJERa09nty1QKEDdx2/DVCm2SKsWrQMQ=
Received: from MWHPR11MB1742.namprd11.prod.outlook.com (2603:10b6:300:113::13) by MWHPR11MB1679.namprd11.prod.outlook.com (2603:10b6:301:f::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.30; Thu, 26 Nov 2020 02:44:37 +0000
Received: from MWHPR11MB1742.namprd11.prod.outlook.com ([fe80::5819:88b4:cdaf:610a]) by MWHPR11MB1742.namprd11.prod.outlook.com ([fe80::5819:88b4:cdaf:610a%9]) with mapi id 15.20.3589.030; Thu, 26 Nov 2020 02:44:37 +0000
From: "Li Zhao (liz3)" <liz3@cisco.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Thread-Topic: Make P-DAO bidirectional [extends] IETF 109 open Questions on P-DAO
Thread-Index: AdbCZRGxaZJsqD20SLuISSoVqF9MEgAgkqIOABJ37jAAGm3GHQ==
Date: Thu, 26 Nov 2020 02:44:37 +0000
Message-ID: <MWHPR11MB17423564937E277312C6BCB78CF90@MWHPR11MB1742.namprd11.prod.outlook.com>
References: <CO1PR11MB4881CE0521CFB876B608188BD8FB0@CO1PR11MB4881.namprd11.prod.outlook.com> <MWHPR11MB17424F37A16E1B048096B1428CFA0@MWHPR11MB1742.namprd11.prod.outlook.com>, <CO1PR11MB48819F71CFF279AC9BD7240DD8FA0@CO1PR11MB4881.namprd11.prod.outlook.com>
In-Reply-To: <CO1PR11MB48819F71CFF279AC9BD7240DD8FA0@CO1PR11MB4881.namprd11.prod.outlook.com>
Accept-Language: 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: [2001:420:588c:1252:ed42:30ae:45fa:1f11]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 79bc7073-d699-4cba-e84b-08d891b53739
x-ms-traffictypediagnostic: MWHPR11MB1679:
x-microsoft-antispam-prvs: <MWHPR11MB167942DE2B444D82D6756F2A8CF90@MWHPR11MB1679.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: VDpthEM+ngdDq5f2icepyEgOe2h29Loi+1vLDwD15qMvEG+LSh1OIfvBXdFmat4YTICqXQyBYUvo56C9Ed16oSHxAg9fIlw6bsc+k8X5DIZwESJbAy0IH6dwh3pYqqwfPYNrTtM0V2nyDxqhxob/KiGOKdFwNC0WhZeBkyRPSFkhxrjuCo0iOx/UvRwLYRMaSoityrKBd2vMyR34qquodkEj6FC6SzbvF/xsbAQwTWza73H2NMhSv3LonLTRac9HcwddAcDdpaw/REHQP8Ns+rKkwhU+KYmqc54T1LQh2oG6DM6uQXjidNaP11zdBQc8Py4XFgpVVJVIvc5mqm8NCD0gS+T/7BG4qd0Z+wDAzsMsj4hqsrGPfvLpVhXU4iaZL14gP978EmsuZQ6ZhgM6duWEqojgByEetgqBwe88eSujVqlYSgbtmPa5oDMH83xewmTqJKQHBuz/zZFgq4X4Kg==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MWHPR11MB1742.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(39860400002)(376002)(136003)(396003)(346002)(366004)(478600001)(55016002)(86362001)(33656002)(8936002)(7696005)(2906002)(966005)(186003)(8676002)(6916009)(53546011)(6506007)(9686003)(66446008)(166002)(76116006)(5660300002)(83380400001)(91956017)(66946007)(52536014)(316002)(66556008)(71200400001)(64756008)(66476007)(88722002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: V6L63WkBMf/Now4e7CncUfvkzZC9WtY1h4zkcwO1XLhWVMtSzko6rJmmlDF1ztATcCW/+V9+zz0TePvBrw9xlM5A7bZ2gcuftfjiwC4Tb31ZePKLE4mYHfD26fQiBX1iWOquO+iAo23x8jjyzlz28yn2LwAJQOb82cabXXI+72q8yDKb80mWUmb5f/gmL+GRAm/E89n5rNS0VMbx5PwtTQ9uvdA3GrdML1ScJ5RgMQtgERnKljNyKT18T44+nxW+P0/9vahw1GO9o5TIKUVjA99VWcGM+3kP576aNYDfmk0+/b8tlk+K+LQR+Fp320cJlrX6LRjVi3l0R3B7ziFS994l7Z15bq7smJy2iFsT4H73zURK5hnzuluCwjGFkIXAAdopOYrRBff5K8wxhq5l2HkeWRYpMgCpmtxNazw1NrkIXhEu6YZk4YqIMmOhjXRXP3vzS2r5BPyM1AdKoI1NqPzCi8pc4aD9bw6w2G336tSMzUC/9Frvs2tZCAYxEX1NADiPoh7HqIL4g7tlUCl4e0v+1YXpi3rfB19Lm+EmZia5tqKkQbpzXMn2V0EEUsxfDqG72w+y+pC8mOsu3Xajf/7oqR/wOelwP0o0itdwIUmTHCgRKzc3khjn3XmPM8lAsPiKf862jIEAd/qbjPeqoSRmbmBmhoB2zTB25FRlNOmeyRh3JhbsmBTwlipZFAbcaFte9HDA4cBI9/a+aybEQKwRdqq3vq+3UKHsF2mCLJLRFliIjE4ICmuA2Z4AzfigkfoQn29nF0LTgR5s9mtbTcyDq64ZtyX0eGNrqLzC1KQJf4ll2Pez/5PNFy1ilNAGUhvtiFNhgjwlrbnE0E6o12a0UzIbIj1RHUurELBwkBRwBENGovUL45N1Atqm2qwDMgEOczTmJsKxS/qq8v+BIDONmovIX2vPoTwiaFEatmegqBVBgjB4yYWlXqU3vXA08G1vrNjCmNAa8fOuqVsaRw4nOR/4Kh5OJ8OlWA7Jx02Q7CbeRIrzp+L00s0XYlM+riIGd7chBcrN6u6A1Scs/9RBGG+t29vdtcPguCVFKCzPZFTkr0/AM/cUGxPou7miSTReE4mmjKZnKxCSwZbKtg==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_MWHPR11MB17423564937E277312C6BCB78CF90MWHPR11MB1742namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MWHPR11MB1742.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 79bc7073-d699-4cba-e84b-08d891b53739
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Nov 2020 02:44:37.2716 (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: 6+qMNOr4VAcwCiWwiikwlmM8h10XeN2PbJDGidpGbv5c/gE3bKK31PbSAj1hVcHg
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1679
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com
X-Outbound-Node: alln-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/e2mZ9BNk9SkIJqaomfFm5mf_ECQ>
Subject: Re: [Roll] Make P-DAO bidirectional [extends] IETF 109 open Questions on P-DAO
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, 26 Nov 2020 02:44:45 -0000

Hello Pascal,

If either source or destination can be root, it’s better to identify when or in which case source or destination can be root. Otherwise, it’s hard to interop between different implement even though they both follow RFC standard.

E.g. for non-storing mode PDAO, if source is root, PCE only responses PDR-ACK after receiving PDR from source.
But if destination is root, PCE should also notify destination which trackid is used. Maybe we need bring new message for this notification?


Take care,
Li

From: Roll <roll-bounces@ietf.org>
Date: Wednesday, November 25, 2020 at 21:54
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Subject: Re: [Roll] Make P-DAO bidirectional [extends] IETF 109 open Questions on P-DAO
Hello Li;

Well noted. This was the original intent. The change was made to egress because the idea was that the track could enable multiple sources to reach the egress, like a tree rooted at the egress that flows traverse going down. But the idea of a bidirectional track kinda blocks that idea and the other issues like the one you point out seem to get us back to the original view. I recently made the change from ingress to egress in the 6TiSCH architecture, waiting in RFC editor queue. I could reverse back, or maybe say “either source or destination” so it can be egress or egress and we are covered for bidirectional.
What do you think?
Or should a reversable Track be really a pair of tracks?

Keep safe;

Pascal

From: Roll <roll-bounces@ietf.org> On Behalf Of Li Zhao (liz3)
Sent: mercredi 25 novembre 2020 05:57
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Subject: Re: [Roll] Make P-DAO bidirectional [extends] IETF 109 open Questions on P-DAO

Hello Pascal,

Ingress as Root looks better because
1.  It is consistent with the way RPL usually works. RPL Local instance, aodv-rpl, p2p-rpl all use ingress as root.
2.  For non-storing-mode P-DAO, currently ingress sends upward traffic to egress(root) with SR header. But in RPL, only downward traffic carries SR header.
3.  Only ingress can send PDR makes sense. Behavior of TrackId is similar as Local Instance ID. Ingress as root can propose TrackId from its namespace.


And for storing-mode P-DAO, if we make ingress as root and ingress sends PDR, can PCE send P-DAO to egress then egress forwards it towards predecessor to ingress?
Maybe it helps to make P-DAO looks like a DAO message.


Best regards,
Li


From: Roll <roll-bounces@ietf.org<mailto:roll-bounces@ietf.org>>
Date: Tuesday, November 24, 2020 at 21:39
To: Routing Over Low power and Lossy networks <roll@ietf.org<mailto:roll@ietf.org>>
Subject: [Roll] Make P-DAO bidirectional [extends] IETF 109 open Questions on P-DAO
Dear all

Whether to make the P-DAO bidirectional is an intriguing question. It could be done, just like we can send packets DOWN a classical DODAG.
But if we take that path, we reopen the question of who is root and which direction the P-DAO flies.

Could we make either the ingress OR the egress root? How does it matter?

At the moment the Root is the egress and the storing-mode P-DAO flies from the Track egress to the track ingress, and the track egress is the root. This is not the way RPL usually works as the DAO flies towards the root. The reason was that we wanted a single egress for the Track, as we build unicast Track. If we wanted to build multicast Tracks the root should logically be the ingress. And for bidirectional Tracks it could be either.

Up to -24 the 6TiSCH Architecture expected the ingress to be root. I changed in the latest to map we do here, that it is the egress; maybe a flag in the DAO would indicate which direction the flow, from root, to root, or both?

Also if we build bidir Tracks in storing mode, the nodes that forward the DAO will have to build routes in both directions based on the P-DAO, both towards egress and ingress; but only the path from which the P-DAO comes has been validated by the P-DAO itself. Should we send a P-DAO to each end, each setting up one way?

Please let me know your thoughts

Pascal


From: Roll <roll-bounces@ietf.org<mailto:roll-bounces@ietf.org>> On Behalf Of Pascal Thubert (pthubert)
Sent: mardi 24 novembre 2020 14:22
To: Routing Over Low power and Lossy networks <roll@ietf.org<mailto:roll@ietf.org>>
Subject: [Roll] IETF 109 open Questions on P-DAO

Dear all

The slides for the P-DAO discussion at IETF 109 are available here:

https://datatracker.ietf.org/doc/slides-109-roll-dao-projection/

There are a number of open questions that we starting discussing, and would need to progress on the list.
Some of them were expressed on the list, e.g., from Huimin She. I’d like to progress on them all with individual threads.
The questions are:


  1.  Lifetime Unit: could we use a different unit for P-DAO?
  2.  How to differentiate a P-DAO from a normal DAO in a local instance; new flag?
  3.  Make P-DAO bidirectional?
  4.  Who sends the PDR? Does it have to be the ingress? If it was egress it could propose a TrackId from its namespace. Else could the ingress be the root?
  5.  Maintaining the sibling state. Should we have text on using RFC 8505 there?
  6.  Whether ingress and egress are listed in NPO? Today they are both, ingress to indicate the packet source in case of encapsulation and for SRH-6LoRH compression reference and egress to build the full SRH-6LoRH. Note that the ingress must consume the first entry and use it as source.
  7.  Track in Track vs. SR Header reload models, see slides

Let me open threads to follow up.

Keep safe

Pascal