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

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Wed, 09 December 2020 08:03 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 CD44F3A0DCB for <roll@ietfa.amsl.com>; Wed, 9 Dec 2020 00:03:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.601
X-Spam-Level:
X-Spam-Status: No, score=-9.601 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, 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=LAscL6F1; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=gvKKBKtT
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 Lx_wMqbKKmcV for <roll@ietfa.amsl.com>; Wed, 9 Dec 2020 00:03:16 -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 45C773A0D13 for <roll@ietf.org>; Wed, 9 Dec 2020 00:03:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=27801; q=dns/txt; s=iport; t=1607500996; x=1608710596; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=o47O49jc6UbijZNIcN6mHA/8YIKipVxJ5ARpQQ4dpcU=; b=LAscL6F1h8ZIyuszar772ZNXf2pTcl6jAJVy+hmUUKNiFTUAW4mIcXo5 TV19hIOzP0//gTr3zenvPOJz1MW+cjg9hOxRJSkFbCekrzP4PDOwHOfck RLb/4m9K/xfHWqkutNJzPQSyeEWHsFQuwhxiqiHNZDrvLX9k4L7EDd1Km k=;
X-IPAS-Result: =?us-ascii?q?A0DKAgBHhNBfmJNdJa1YCh0BAQEBCQESAQUFAUCBT4FSK?= =?us-ascii?q?Sh8Wy8uiAYDjV0DgQWOBYl/gUKBEQNUCwEBAQ0BARgNCAIEAQGBbAGCXQKBf?= =?us-ascii?q?wIlOBMCAwEBAQMCAwEBAQEFAQEBAgEGBBQBAQEBAQEBAYYJCCUMhXIBAQEBA?= =?us-ascii?q?wEBEAgNGQEBJQcMCwQCAQgRAQEBAQEBKAcnCxQDBggCBBMIGoJ/BAEBglUDL?= =?us-ascii?q?gEOoVoCgTyIaXSBATODBAEBBYE3BAxBgy4DFYIQCYE4gnSCZk6HGxuBQT+BE?= =?us-ascii?q?AFDgVdJBy4+gQSBWQEBAgEBFYEMDQ8gBR8SgxKCLIFpWAYBYw0HGwMGCwgIH?= =?us-ascii?q?wIsDQIeCAILBysVBAEGBBoBLhoYD48HJDKKSIEcnBkKgnSJHpJEgmg8iiSUb?= =?us-ascii?q?Z8HkUQID4Q8AgQCBAUCDgEBBYFtIQ+BSnAVO4JpCUcXAg2HfoYjDA4JgQIBB?= =?us-ascii?q?4JEhRSFRHQCATQCBgEJAQEDCXyHKi2CFwEB?=
IronPort-PHdr: =?us-ascii?q?9a23=3ApIY2GB8yWfiNZv9uRHGN82YQeigqvan1NQcJ65?= =?us-ascii?q?0hzqhDabmn44+7ZRaN5PhxghnOR4qIo/5Hiu+DtafmVCRA5Juaq3kNfdRKUA?= =?us-ascii?q?NNksQZmQEsQavnQU32JfLndWo2ScJFUlI2/nynPw5SAsmtL1HXq2e5uDgVHB?= =?us-ascii?q?i3PAFpJ+PzT4jVicn/1+2795DJJQtSgz/oarJpJxLwpgLU5cQ=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.78,404,1599523200"; d="scan'208";a="649710125"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 09 Dec 2020 08:03:14 +0000
Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 0B983EMA011281 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for <roll@ietf.org>; Wed, 9 Dec 2020 08:03:14 GMT
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 9 Dec 2020 02:03:14 -0600
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 9 Dec 2020 02:03:13 -0600
Received: from NAM04-BN8-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 9 Dec 2020 02:03:13 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=esncy+QqvDfmkSScW/Qzd4piHXAT0g1ZcWZhUId6hrQ766DoeUMOUJxBo760J3sPJP7XOWaXBUPbdKRRd3GFiXvlrHahwMJMXouJY/5EdB4kucppGMnc47HVQcViy8weMoOP7z9vk+dxTye7FwhrGxtPrLiiBlf16oSyNVzO9HlqxHiU7wdsysBt3wZZv0tpCYlecrHz1/nsjD4Ek+jF4TlCfS0WZyk6hgTGnHTdWjzrgooq/tuWWH1l9865UnGti3Aq9oxohrlxBzb9vA+grV9Mdan2m7Jpvsv3n8NZrGmly+eoewvOHfeUgx2RvHqm1cHxsZHhpOCLsVp5H3PQ3Q==
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=iJkpO0jUnY4RXqlN2GiGsl0CkvzkJu+Meq2NHMHO1xE=; b=jGTFYDhDtXs2kBMRxN/I/Duk2j56FWYcT6apmNX11ghshpPIey+mAXB2m0UFOWYDlyPROQbiokXe1iR5eST/3h0W+AQB6GSy/fI9LSaa85FhZE26TJBzmjRaIf9Bd4cb/VFcQMOYQudk7NKAXKRotC8zPYeT/Be7a7Q821y2225vAR2DlKyESygnboqWlGmrSd40LfxlvWvb2xonbcQbshk8COZaf/wVu19bkyNolz+U4tTUKiDI4oWD6iHVdsNuGXkpZJje0lMXsbzs7mI+0K4FXzygAGX3wD+M4rFk4bNAGiUfL9hD0+eElqkuwi5SWLIcQknsPk5I/IshQJx+Yw==
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=iJkpO0jUnY4RXqlN2GiGsl0CkvzkJu+Meq2NHMHO1xE=; b=gvKKBKtTTwLep0WUmkIYnamg/m1a4pu9BjBSrpoZuKZWFbg3jKYZiNrWCtSIVBgFZHNitxs+DKNFhA9xk1gO5wYhSSeehemYdowrEx+orqwj0jS8q2IueYdwDeqRCoZkU34WELUGz1M/pogy0DqFHVBp20+h7TbD6WJjqBQ0syU=
Received: from SJ0PR11MB4896.namprd11.prod.outlook.com (2603:10b6:a03:2dd::20) by SJ0PR11MB5167.namprd11.prod.outlook.com (2603:10b6:a03:2d9::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3654.13; Wed, 9 Dec 2020 08:03:12 +0000
Received: from SJ0PR11MB4896.namprd11.prod.outlook.com ([fe80::3143:6202:a05:c34c]) by SJ0PR11MB4896.namprd11.prod.outlook.com ([fe80::3143:6202:a05:c34c%3]) with mapi id 15.20.3654.012; Wed, 9 Dec 2020 08:03:12 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Thread-Topic: [Roll] Make P-DAO bidirectional [extends] IETF 109 open Questions on P-DAO
Thread-Index: AQHWzfMdmrIloDNomE2Ns+gKyu5Y6anuZfJg
Date: Wed, 9 Dec 2020 08:02:52 +0000
Deferred-Delivery: Wed, 9 Dec 2020 08:02:25 +0000
Message-ID: <SJ0PR11MB489660E1657F3105766B9E76D8CC0@SJ0PR11MB4896.namprd11.prod.outlook.com>
References: <6BF749EE-85B2-4300-8095-59D46ECFBFB5@cisco.com>
In-Reply-To: <6BF749EE-85B2-4300-8095-59D46ECFBFB5@cisco.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:145f:188f:f1c2:a887]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 2a98eaba-a211-44e5-8075-08d89c18e037
x-ms-traffictypediagnostic: SJ0PR11MB5167:
x-microsoft-antispam-prvs: <SJ0PR11MB51674BF13BA41E4558F47BD1D8CC0@SJ0PR11MB5167.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: FZL68SPkdEIfEJYyKe0C2JBn3Yty09R07KG3e3lHHw0W7pUGFZD4erJSfmjsuYBjHRvFRaw+s0dZV/AMQMP34j1B0OAZvvLpM+l1jINxDmpv7iMZtet2f/adThM9uwmA2d4Hjh5aKgmwrI4pMvKbKq+YavYwJxfW+mivpqnWzu5RZHRRNhKkU8LuBMv2pLiPpUTdnt9UzmlIXmQOuYZ8wMlUM5e/QPBLVSuNz13A4O9KOXg8fTYufmY93o16XB9ESBEUGYmliJ1T8vCjP6sdjYYqhLYDpyYzSFbKyPhfnHWMDqe2jQYbxEe4fpVORcHptmS0BWfrS41EWYoflzfJJeqjiJxjGPg075Hq/3Yl/UoMqeUoUrQ67sac0IXEsP/2VMbN6sO/l+pLuVqusFqFEw==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SJ0PR11MB4896.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(376002)(346002)(396003)(39860400002)(366004)(52536014)(6666004)(478600001)(316002)(66574015)(7696005)(86362001)(6506007)(30864003)(76116006)(83380400001)(66476007)(2906002)(186003)(9686003)(5660300002)(66446008)(33656002)(71200400001)(966005)(53546011)(64756008)(6916009)(8936002)(66556008)(8676002)(45080400002)(66946007)(55016002)(579004)(559001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?SHZ96yoiyHzyO1J3M2lciHKIRsiMYBXrwyiaLaBVWE1s4zHC+c2jUGoCvc?= =?iso-8859-1?Q?uuS3d3PEfHKPD1jkLnGtACnOGts9+Nvu19JUYOpgGbRQejEX/qqT5rgeRA?= =?iso-8859-1?Q?/FFiM7XyiGnBQFZkSO9Ynkn1mzFEB3x+vzM2YEVcZAD1ehecQ0SNiKlFu5?= =?iso-8859-1?Q?2ExfuHXs4vUupY2tJTIHfXrt64Xwh4OPoDiLSQur8My+5tdzjndCY/1jSC?= =?iso-8859-1?Q?BDmgyUNJrev1B/0HFIeK1zKyW7XnA8XjbdmfG/TjUris9xEsikZJ0l1G7J?= =?iso-8859-1?Q?iOc1z2cn3JgbzdtUqyUvbBG9tdX4Ipr3XnC3uWyNdDyWjMxMLm0vViD2oj?= =?iso-8859-1?Q?o6MF1Pwt94vhQ8gu7whgjDBgtlWljIpq6Re4gEf9/5i+SKWUjTWsld4Jjc?= =?iso-8859-1?Q?oW1hkfR/1+rBa77nK2fvf/M80tn5fSQ4+DV61jnEQNp5pMhao1hkxUHL1z?= =?iso-8859-1?Q?aGZ4cg3ezsVogf/mDXYlDHktKVTfKPz/zgxZTV7gj8Lhd4apb4R95RLFV+?= =?iso-8859-1?Q?al+lv1QFU5V1LlAdtls9wh3LrdaGX1idRpDWI/f1dKAD/3+/U69oFsfsSJ?= =?iso-8859-1?Q?9zEgrb9rm96n2S0OF3r1+17W/J7Qh3hiusVJswC2qSL2sytXHsw0qZes/p?= =?iso-8859-1?Q?6xlDYsi2yJUEKLXlQ6KEuGWPZTKh+7DN6PkpzZmzkyVkpyHINuIOxJizGH?= =?iso-8859-1?Q?NgWVvEmVER/WzWCuf6S5qF0hwLwBVP91KnqZzV7vM+zfM3PB6LLYEKCC9V?= =?iso-8859-1?Q?IUVSuf8AB4Uz563cWca3McgORe6SyTkmmz0vJyXx67H5ib2EUSCCNDmHZk?= =?iso-8859-1?Q?gR9BkFLO1Qavy9+fFGo1nL54Z7qzdHILsKxTmfA1KOQDrEEuR0Kkr5kUCB?= =?iso-8859-1?Q?Xd132WHxU8I/vVE2mGAA+RCjhvRH/vX/MH8IVMisAkV2JsDn/pUwrMqIcV?= =?iso-8859-1?Q?uU6onVn8LGNwpOjXflxqLt+mqmggAgutR3lbqcyHdnPGGJxQXbjc2GKDX8?= =?iso-8859-1?Q?QFU+xtgy5gQsq49LZKbkzxcnjidhhqsk7t0A6f5sMS4B0y/7bBQM8KNhCM?= =?iso-8859-1?Q?TO812i84hIBFqp1zDKDBgrgQDFQjdcgMoRQ+gPxE7vfS?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SJ0PR11MB4896.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 2a98eaba-a211-44e5-8075-08d89c18e037
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Dec 2020 08:03:12.6074 (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: DdoxHZmaj3ZaKUxMK8gASX4gwpNyq36YeD1S6f+AXvKcomvGiuQtdDHZDIyx4u6SrSiYAnTDcfi9Ksb0FLdEUA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR11MB5167
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com
X-Outbound-Node: rcdn-core-11.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/rfjnEpH_Ai5Kf9ybYZ9QPMsBm7k>
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: Wed, 09 Dec 2020 08:03:20 -0000

Hello Huimin 

Documenting the 3 cases (and giving names) looks like a good idea, Huimin. That helps explain what an implementation supports and what it does not. 

I want to ensure that the group understand what can be done, and then we'll provide examples of how that is done. This is what I started with the cases.

I did not get much feedback. Should I assume that the group agrees the examples work?

Pascal 

> -----Original Message-----
> From: Roll <roll-bounces@ietf.org> On Behalf Of Huimin She (hushe)
> Sent: mercredi 9 décembre 2020 07:19
> To: roll@ietf.org
> Subject: Re: [Roll] Make P-DAO bidirectional [extends] IETF 109 open Questions
> on P-DAO
> 
> Hi Pascal,
> 
> Non-storing P-DAO is a very good complement for non-storing RPL.
> One of the practical use case is to find the P2P path via the common ancestor in
> non-storing mode RPL.
> 
> For non-storing P-DAO, I think it's fine to live with Tracks without segments.
> 
> For the P-DAO draft, is it more reasonable to list three cases: non-storing,
> storing, and mixing?
> 
> Best regards,
> Huimin
> 
>     Message: 1
>     Date: Tue, 8 Dec 2020 07:29:37 +0000
>     From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
>     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
>     Message-ID:
> 
> 	<CO1PR11MB48819E978A4064D00E869A75D8CD0@CO1PR11MB48
> 81.namprd11.prod.outlook.com>
> 
>     Content-Type: text/plain; charset="iso-8859-1"
> 
>     Hello Li:
> 
>     > Yes. There is no segment in non-storing mode anymore... It seems that we
> either back to egress as root or accept this shortage?
> 
>     I have been bouncing between the 2. You can see that in the diffs in the
> 6TiSCH architecture. I did again when you suggested the change back to the
> ingress is root. We need to settle. The change was a lot of work
> (https://tools.ietf.org/rfcdiff?url2=draft-ietf-roll-dao-projection-15.txt). The
> reason why I accepted the change is that the RH reload that II explained at IETF
> 109 is far from accepted at 6MAN, and the history we have there with RH
> insertion does not leave much hope anyway. Which leaves us with:
> 
>     a) Tracks are non-storing  paths expressed in strict or loose source route.
> Simple implementations only do strict
>     b) Segments are storing mode paths, that stitch loose SRH paths. This applies
> to the main DODAG and to Tracks. That's the normal segment routing case 1.3
> below.
> 
>     What is also possible but more complex:
>     c) A path can be established by stitching segments without declaring a Track
> (that's case 1.1 below). The Track is implicit.
>     d) Instead of declaring a storing mode segment between 2 loose SRH hops, the
> path can be another Track in which case we need to encapsulate between the
> loose hops. That's the non-storing segment routing case 2.3 below.
> 
>     And then there can be tunneling of traffic beyond the egress, e.g., if the egress
> is a station with multiple devices in it.
> 
>     > Btw, I think mixed storing PDAO /non-storing PDAO/Stitched Segments is
> complex and maybe little bit hard to use in runtime deployment.
> 
> 
>     An implementation will not need to support all possible combinations. It is
> really a matter of what the industry standard -the like of Thread or Wi-Sun- that
> would use RPL P DAO needs. You see it today, most implementations of RPL do
> not support both storing and non-storing modes. But we have a consistent RPL
> RFC which can do both with most things in common.
> 
>     This is something we also observe with RFC 6282. The RFC has to propose all
> possibilities in a consistent fashion with a clear architecture that encompasses all
> cases. But you find that open source implementations, Thread or Wi-Sun did not
> necessarily support the same cases, and would not necessarily interoperate.
> Since those implementations face one another, that is not an issue.
> 
>     When an industry standard moves to P-DAO, it may support, say, only strict
> non-storing mode P-DAOs, if the problem is P2P/automation. It may create only
> one, or it may create more than one P2P path from ingress to egress. It may
> enable tunneling or not.
> 
>     Another standard may only care to shorten the SRH in the main DODAG, in
> which case it will not need the sibling information and the tracks, but just the
> storing mode P-DAO in the main DODAG.  Just like today we have storing mode
> only and non-storing mode only implementations. This is the original use of
> mixed P-DAO segments with loose SRH path. This use case makes a lot of sense
> and is the reason why the group originally adopted the draft.
> 
>     Because it proposes a consistent model, the draft allows a combination of
> tracks and segments. In that case, the SRH that defines a Track is loose, and
> storing mode segments join the dots, like they do in the main DODAG. I agree
> with you, that can be complex in current use cases. So I do not expect industry
> standards to pick it up day 1. But should we add text to say do not do it?
> 
>     It would be a lot worse if there were 10 RFCs that operate differently with no
> consistency and overall architecture!
> 
>     > The original requirement I want to get from pdao-draft is finding an
> available p2p path from PCE with lowest cost. Which means easy to get route
> entry from PCE and easy to maintain in node.
> 
>     > Because either rpl local instance or aodv-p2p mechanism will leverage more
> DIO/DAO/NS messages to maintain the route path.
> 
>     Yes, maybe you can live with non-storing strict SRH for that use case. Do you
> also need to compress the SRH in the main DODAG? I would suspect so.
> 
>     Keep safe;
> 
>     Pascal
> 
>     From: Roll <roll-bounces@ietf.org> On Behalf Of Li Zhao (liz3)
>     Sent: mardi 8 d?cembre 2020 02:07
>     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,
> 
>     Yes. There is no segment in non-storing mode anymore... It seems that we
> either back to egress as root or accept this shortage?
> 
> 
> 
>     More comments line...
> 
>     Btw, I think mixed storing PDAO /non-storing PDAO/Stitched Segments is
> complex and maybe little bit hard to use in runtime deployment.
>     The original requirement I want to get from pdao-draft is finding an available
> p2p path from PCE with lowest cost. Which means easy to get route entry from
> PCE and easy to maintain in node.
>     Because either rpl local instance or aodv-p2p mechanism will leverage more
> DIO/DAO/NS messages to maintain the route path.
> 
> 
>     Best regards,
>     Li
> 
> 
>     From: Roll <roll-bounces@ietf.org<mailto:roll-bounces@ietf.org>>
>     Date: Friday, November 27, 2020 at 19:52
>     To: Routing Over Low power and Lossy networks
> <roll@ietf.org<mailto:roll@ietf.org>>
>     Subject: Re: [Roll] Make P-DAO bidirectional [extends] IETF 109 open
> Questions on P-DAO
>     Dear all
> 
>     <hard thinking here, sorry, been scratching my head quite a bit, so please bear
> with me>
> 
>     On this thread we decided to change the Root from being the Track egress to
> being the ingress. That is cool for many reasons, but as i said that kills the
> possibility to "reload" the routing header in a multi-segment Track where the
> segments are expressed as non-storing P-DAOs. Why?
> 
>     The operation I presented at IETF 109 involves changing the packet source at
> the segment stitching point and still recognize the packet as being part of a
> Track. The change above makes the packet source is the Root of the Track, so
> the packet source now identifies the Track (together with the RPI). Non-storing
> P-DAOs require to add a routing header. If header insertion was allowed then
> that would not be an issue.
> 
>     But to add a RH cleanly at the segments stitching point, the connecting router
> needs to decapsulate the previous segment and encapsulate the next segment
> with the RH. The connecting router becomes the source, thus the root. Meaning
> that the segment is in fact a Track in its own right as opposed to a segment of the
> complex Track.
> 
>     Another way to say that there is no segment in non-storing mode anymore.
> There are only Tracks that can be further assembled into more complex graphs.
> That is, unless as I said we allow RH insertion despite the disputes we observe on
> the same subject at 6MAN about Segment Routing. Or the TrackID is taken from
> the Global Instance IDs name space. At the moment I'm ignoring those options
> which lead to either political issues or technical limitations.
> 
> 
>     A complex Track can still be expressed as a collection of loose source routing
> paths from a same Ingress == Root.
> 
>     Think of it as a Segment Routing Policy for those familiar with SR. The
> difference is that in SR the loose hops are ECMP path served by the IGP.
> 
>     Here we'll need either non-storing Tracks or storing mode segments, the
> difference being that the storing mode segments do not required re-
> encapsulation. Note that in either case, there can be multiple NECMP
> possibilities.
> 
> 
>     An example maybe?
> 
> 
>     Say we have
> 
>                                     ------ F
>     A------B------C------D------E <
>                                     ------ G
> 
> 
>     A is Track ingress, E is track Egress. C is stitching point. F and G are E's
> neighbors, "external" to the Track, and reachable from A over the Track A->E.
>     In a general manner we want:
> 
>       *   PDAO 1 signals A->B->C
>       *   PDAO 2 signals C->B->E
>       *   PDAO 3 signals F and G via the A->E Track
> 
>     PDAO 3 being loose, it can only be non-storing. Note that since the Root is
> always the ingress of a Track, and all SR-VIOs are now Track, the Root being
> signaled in the DAO base object can now be elided in the VIA list in SR-VIO. This
> enables the construction by the main root of the RFC 8138 optimized SRH-
> 6LoRH in the SR-VIO, to be placed as is in the packet by the Root.
> 
> 
>     1) Storing mode Segments
>     --------------------------------
> 
>     A->B->C and C->D->E are segments of a same Track.
>     Note that the storing mode signaling imposes strict continuity in a segment.
> This may also avoid weird loops.
> 
>     Case 1.1) Stitched Segments
> 
> 
>       1.  storing mode PDAO 1 is sent to E. It has Root = A, VIO = C, D, E, Track ID
> 129 from A's namespace, Target = E, F, G
>       2.  storing mode PDAO 2 is then sent to C. It has Root = A, VIO = A, B, C, Track
> ID 129 from A's namespace, Target = E, F, G
> 
>     E recognizes that it is egress because it is a Target and a segment endpoint.
> 
>     Packets along the Track have source= A, destination = E | F | G, and RPI = 129.
>     >From PDAO 2: A forwards to B and B forwards to C.
>     >From PDAO 1: C forwards to D and D forwards to E.
> 
> 
>     Case 1.2) External routes
> 
> 
>       1.  storing mode PDAO 1 is sent to E. It has Root = A, VIO = C, D, E, Track ID
> 129 from A's namespace, Target = E
>       2.  storing mode PDAO 2 is then sent to C. It has Root = A, VIO = A, B, C, Track
> ID 129 from A's namespace, Target = E
>       3.  non storing mode PDAO 3 is then sent to A. It has Root = A, SRVIO = E,
> Track ID 129 from A's namespace, Target = F, G
> 
>     >From PDAO 3: A encapsulates packets with dest =   F | G as below;
>     Packets along the Track have source= A, destination = E, and RPI = 129.
>     >From PDAO 2: A forwards to B and B forwards to C.
>     >From PDAO 1: C forwards to D and D forwards to E.
>     E decapsulates if encapsulated packet.
> 
> 
> 
>     Case 1.3) Segment Routing
> 
> 
>       1.  storing mode PDAO 1 is sent to E. It has Root = A, VIO = C, D, E, Track ID
> 129 from A's namespace, Target = E
>       2.  storing mode PDAO 2 is then sent to B. It has Root = A, VIO = A, B, Track
> ID 129 from A's namespace, Target = B, C
>       3.  non storing mode PDAO 3 is then sent to A. It has Root = A, SRVIO = C, E,
> Track ID 129 from A's namespace, Target = F, G
> 
> 
>     >From PDAO 3: A encapsulates packets with dest =   F | G as below;
>     Packets from A have source= A, destination = C, SRH = E, and RPI = 129.
>     >From PDAO 2: A forwards to B.
>     B forwards to C based on a sibling connected route; C consumes the RH and
> makes the destination E.
>     >From PDAO 1: C forwards to D and D forwards to E.
>     E decapsulates if encapsulated packet.
> 
> 
> 
>     2) Non Storing mode joining Tracks
>     ---------------------------------------------
> 
>     A->B->C and C->D->E are Tracks expressed as non-storing P-DAOs.
> 
>     Case 2.1 Stitched Tracks
> 
> 
>       1.  non storing mode PDAO 1 is sent to C. It has Root = C, VIO = D, E, Track ID
> 131 from C's namespace, Target = E, F, G
>       2.  non storing mode PDAO 2 is then sent to A. It has Root = A, VIO = B, C,
> Track ID 129 from A's namespace, Target = E, F, G
> 
>     >From PDAO 2: A encapsulates packets with dest =  E | F | G. The outer
> header has source = A, destination = B, SRH = C and RPI = 129.
>     Packets forwarded by B have source= A, destination = C , SRH =, and RPI =
> 129. C decapsulates.
>     >From PDAO 1: C  encapsulates packets with dest =  E | F | G. The outer
> header has source= C, destination = D, SRH = E and RPI = 131.
>     E decapsulates.
> 
> 
>     Case 2.2 External routes
> 
> 
>       1.  non storing mode PDAO 1 is sent to C. It has Root = C, VIO = D, E, Track ID
> 131 from C's namespace, Target = E
>       2.  non storing mode PDAO 2 is then sent to A. It has Root = A, VIO = B, C,
> Track ID 129 from A's namespace, Target = E
>       3.  non storing mode PDAO 3 is then sent to A. It has Root = A, SRVIO = E,
> Track ID 141 from A's namespace, Target = F, G
> 
> 
> 
>     >From PDAO 3: A encapsulates packets with dest =   F | G. The outer header
> has source = A, destination = E, and RPI = 141.
>     This may recurse with:
>     >From PDAO 2: A encapsulates packets with dest =  E. The outer header has
> source = A, destination = B, SRH = C and RPI = 129.
>     Packets forwarded by B have source= A, destination = C , SRH =, and RPI =
> 129. C decapsulates.
>     >From PDAO 1: C  encapsulates packets with dest =  E. The outer header has
> source= C, destination = D, SRH = E and RPI = 131.
>     E decapsulates if encapsulated.
> 
> 
>     Case 2.3 Segment Routing
> 
> 
>       1.  non storing mode PDAO 1 is sent to C. It has Root = C, VIO = D, E, Track ID
> 131 from C's namespace, Target = E
>       2.  non storing mode PDAO 2 is then sent to A. It has Root = A, VIO = B,  Track
> ID 129 from A's namespace, Target = C, E
>       3.  non storing mode PDAO 3 is then sent to A. It has Root = A, SRVIO = C, E,
> Track ID 141 from A's namespace, Target = F, G
> 
> 
>     >From PDAO 3: A encapsulates packets with dest =   F | G. The outer header
> has source = A, destination = C, SRH = E, and RPI = 141.
>     This may recurse with:
>     >From PDAO 2: A encapsulates packets with dest =  C | E . The outer header
> has source = A, destination = B, and RPI = 129.
>     B decapsulates forwards to C based on a sibling connected route; C consumes
> the RH and makes the destination E.
>     >From PDAO 1: C  encapsulates packets with dest =  E. The outer header has
> source= C, destination = D, SRH = E and RPI = 131.
>     E decapsulates, twice for dest =   F | G.
> 
> 
>     Does that work so far?
> 
>     Keep safe
> 
>     Pascal
> 
> 
>     From: Roll <roll-bounces@ietf.org<mailto:roll-bounces@ietf.org>> On Behalf
> Of Pascal Thubert (pthubert)
>     Sent: jeudi 26 novembre 2020 11:47
>     To: Routing Over Low power and Lossy networks
> <roll@ietf.org<mailto:roll@ietf.org>>
>     Subject: Re: [Roll] Make P-DAO bidirectional [extends] IETF 109 open
> Questions on P-DAO
> 
>     Hello Li
> 
>     In the packet, there's a bit in the RPI to say if the root is the source or the
> destination. That's RFC 6550.
>     I guess the discussion is related to the PDR and P-DAO, not data packet,
> though it impacts the ICMP error reporting.
> 
>     In a packet along the P-Route, the idea was so far that the DODAG is a
> convergecast to the destination so the destination is the root. If we say that
> there's a single ingress and a single egress then the dodag is reversible and either
> can be the root. If we want to support multicast tracks in the future, then the
> ingress should be root.
> 
>     If the Track has a single ingress and a single egress, then the DODAG is
> reversible into another DODAG and it does not matter which is root, so we can
> make it bidir as Huimin asked.
>     The storing mode P DAO would look a lot more like a DAO, as you pointed
> out, if it goes towards the root. If we want to take that path, a node could learn
> both directions with a single storing mode P DAO. To be continued...
> 
>     For non-storing, making bidir is really hard. It seems easier to install a Track in
> both directions and couple them.
> 
>     As a summary of the proposed changes:
> 
>     General
>     - we make the root the ingress
>     - ICMP errors sent to the Root, using the main DODAG if the track is not
> reversible
> 
> 
>     Storing mode P DAO:
>     - we also make the root the ingress, P-DAO from egress to ingress are now
> more similar to RPL DAO operation
>     - the track could be made bi-directional, but that's more code; if so:
>       - the packet forwarding leverages the RPI to indicate the direction, from or to
> root
>       - ICMP errors sent to the Root, could be source or destination.
> 
>     Non storing mode P DAO:
>     - tracks remain directional, can be coupled, how is tbd
>     - the RPI is mostly useless since the intermediate nodes do not know the
> instance (they see neither the DIO nor the P-DAO); they have no idea of their
> Rank. Still, it is interesting to have is for error determination in an ICPMP error at
> eth root. It is also interesting if the SRH forwarding nodes have a state associated
> to the Track, e.g., reserved time slots or priority queues.
>     - the RPI is still a SHOULD when there's no compression and a MUST when
> there is. We need to clarify what to do, that's another of Huimin's questions,
> taken separately.
>     - ICMP errors forwarding packets are sent to the root which is now the
> ingress, aka the source of the packet, and the encapsulator field if the packet is
> encapsulated and compressed. This is common to any non-storing operation,
> whether it is a main Instance, local Instance, or Track. The RPI therein is useful to
> indicate the Track in Error. So for that matter the forwarder does not need to
> make a difference Track vs. other form of RPL local instance.
>     - this impacts the discussion in SRH reloading we had at IETF 109, when a  N-S
> mode loose track is forwarded along a segment that is also NS mode. We'll
> probably need to re-encapsulate now.  In case of re-encapsulation, the re-
> encapsulator becomes source and root of the segment, which now has to be
> considered as a serial Track; as tunnel headends do, it will have to decapsulate
> the tunneled packet to send the packet in error back to the ingress of the loose
> track
> 
> 
>     Doe that work?
> 
>     Pascal
> 
>     From: Roll <roll-bounces@ietf.org<mailto:roll-bounces@ietf.org>> On Behalf
> Of Li Zhao (liz3)
>     Sent: jeudi 26 novembre 2020 03:45
>     To: Routing Over Low power and Lossy networks
> <roll@ietf.org<mailto:roll@ietf.org>>
>     Subject: Re: [Roll] Make P-DAO bidirectional [extends] IETF 109 open
> Questions on P-DAO
> 
>     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<mailto:roll-bounces@ietf.org>>
>     Date: Wednesday, November 25, 2020 at 21:54
>     To: Routing Over Low power and Lossy networks
> <roll@ietf.org<mailto: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<mailto: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<mailto: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
> 
> 
> 
> 
> 
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll