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

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Fri, 27 November 2020 11:51 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 ED16E3A09B5 for <roll@ietfa.amsl.com>; Fri, 27 Nov 2020 03:51:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -11.9
X-Spam-Level:
X-Spam-Status: No, score=-11.9 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_DNSWL_MED=-2.3, 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=dpVjKpb4; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=jZwgGHXr
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 Hz5JYhHD_u9R for <roll@ietfa.amsl.com>; Fri, 27 Nov 2020 03:51:56 -0800 (PST)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B02423A09AD for <roll@ietf.org>; Fri, 27 Nov 2020 03:51:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=98428; q=dns/txt; s=iport; t=1606477915; x=1607687515; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=2wyssjDNkSrYGmfKiYTQKSvGLXNYmLsQOdhxpnyPCEo=; b=dpVjKpb4hsFK9s93ts89gb7IRgEJv2BduzBsgMztSJS/Lyl3BT01ekbz Cttx6egca6q8NU/XzUaSuAOEFK0a+mfKlrbfNlzJYAlEwMI0tp3cvgIZI zKc4pV0SzNN08FSkLLeD5dMb4inhvxI2PjkRGx0VO7ATWrJxulT5d4puf Q=;
X-IPAS-Result: =?us-ascii?q?A0DrCAA258BffYUNJK1YCoEJgnIBLikofFovLogGA41dg?= =?us-ascii?q?QWPeogHgUKBEQNUCwEBAQ0BASMKAgQBAYRKAoIpAiU4EwIDAQEBAwIDAQEBA?= =?us-ascii?q?QUBAQECAQYEFAEBhg8IJQyFcgEBAQQSCAEMBhMBASUTDwIBCBEBAgEBASEBB?= =?us-ascii?q?gcyFAMGCAEBBBMIGoMFgX5XAy4BDqUMAoE8iGl0gQEzgwQBAQWBNwQMQYMlG?= =?us-ascii?q?IIQAwaBOIJzgmZOhxkbgUE/gRABQ4FXSQcuPoEEgVkCAwGBIQ0PIB4GBwmDF?= =?us-ascii?q?IIskC8kMoobKIt4kS4Kgm+JF4lfiFiCYjuKHZRanmuRLIQ8AgQCBAUCDgEBB?= =?us-ascii?q?YFtIYFZcBU7gmlQFwINh36GLxeBAgEHgkSFFIVEdDcCBgoBAQMJfIwaLYIXA?= =?us-ascii?q?QE?=
IronPort-PHdr: =?us-ascii?q?9a23=3A0H8Z5hJ6wn6DUVXjZ9mcpTVXNCE6p7X5OBIU4Z?= =?us-ascii?q?M7irVIN76u5InmIFeGvK8/jVLVU8Pc8f0Xw+bVsqW1X2sG7N7BtX0Za5VDWl?= =?us-ascii?q?cDjtlehA0vBsOJSCiZZP7nZiA3BoJOAVli+XzoMEVJFoD5fVKB6nG35CQZTx?= =?us-ascii?q?P4Mwc9L+/pG4nU2sKw0e36+5DabwhSwjSnZrYnJxStpgKXvc4T0oY=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.78,374,1599523200"; d="scan'208,217";a="601800913"
Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 27 Nov 2020 11:51:54 +0000
Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 0ARBprtf025965 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for <roll@ietf.org>; Fri, 27 Nov 2020 11:51:54 GMT
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 27 Nov 2020 05:51:53 -0600
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 27 Nov 2020 05:51:52 -0600
Received: from NAM10-DM6-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 27 Nov 2020 05:51:52 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Tb48KW4AfLT3HcAyFkEe6GeODakhHjc0W9lkZKWojcFMwUwxKygLmqsoJTggvXRhBnIH7UdJXhWLHq5mRddIXdqicyQrJj2Oy7hUiO8p0cTakku74CfZnOGlJmtO5PGdiDGUneG3MJLEH7UCFBeMhM1mkrAzwLurejY/UDvH8sYNu/4u2RiowntZP19pVr3v3k2/DADA7bw+j/OrPzNvIRj4IB66HqB3aEu9jHmZcEj+AJTLFndI91rX0kXlBEgCR4mb/mYaCRDnUQxsJpfjsuZc/zp0TN80DCVyRl0Id23cjaEXnTW9yVpMyOe5G8uNaJ8f0iuTN21/pNnEJPd+OQ==
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=ZU6YbGp4klb0mgnL17bpEpwz8NjmHH/1Iii3LozZY5E=; b=KavOaCoU2NZafzAMy+eyYGidaFjLYUfQ8110nuiWRznAcgYzrywNIQmAQrIZFmQV20AU5eDc+M1rc5Ca0Yy/q00itMmkUYeDxvan441KTVtGhJlaeLDT0RDNmsRLMdNAEhzezf7Y3jR8NdQGNYyf6NJEIT3lG0Y/UDSlTKvj/DnXXlj5LH+y2quC+HXwxzsIOs68Yer5hk4HyEiuJNGQz6JpS7ABvl4nFGxijjzz9SyEIA175yR1aZuWac7kqVXMwmoUy5JtEO15/f+n5GRibPc0Hs2RQqbmWe03OxJ9/EhqUM5U/j+YEw1LLzaGfI+3Qb3uomiYgZ4yheEFH4VsxA==
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=ZU6YbGp4klb0mgnL17bpEpwz8NjmHH/1Iii3LozZY5E=; b=jZwgGHXrOkaz8W9nm+tGzAHIW3hxtPUJfpP7hKEaN6wP3CRuNyfHsPP/XhuS83ACRsztRNQ4jY37ey0EGsKPmIRC/8iVSdY9lKrDWh9RGptX5pmIl4qS/jPAqRiGYN52M7uxWv++K6/sxW2hpzHHUWeDdJHHZzCsvsTJkzuvYGs=
Received: from CO1PR11MB4881.namprd11.prod.outlook.com (2603:10b6:303:91::20) by MWHPR11MB1709.namprd11.prod.outlook.com (2603:10b6:300:25::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3611.20; Fri, 27 Nov 2020 11:51:51 +0000
Received: from CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::fc25:3e72:3e83:7df6]) by CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::fc25:3e72:3e83:7df6%4]) with mapi id 15.20.3564.025; Fri, 27 Nov 2020 11:51:51 +0000
From: "Pascal Thubert (pthubert)" <pthubert@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: AdbCZRGxaZJsqD20SLuISSoVqF9MEgAgkqIOABJ37jAAGm3GHQALqPgAADNsT9A=
Date: Fri, 27 Nov 2020 11:51:25 +0000
Deferred-Delivery: Fri, 27 Nov 2020 11:50:13 +0000
Message-ID: <CO1PR11MB48819304E7BE2BD815A8DB42D8F80@CO1PR11MB4881.namprd11.prod.outlook.com>
References: <CO1PR11MB4881CE0521CFB876B608188BD8FB0@CO1PR11MB4881.namprd11.prod.outlook.com> <MWHPR11MB17424F37A16E1B048096B1428CFA0@MWHPR11MB1742.namprd11.prod.outlook.com>, <CO1PR11MB48819F71CFF279AC9BD7240DD8FA0@CO1PR11MB4881.namprd11.prod.outlook.com> <MWHPR11MB17423564937E277312C6BCB78CF90@MWHPR11MB1742.namprd11.prod.outlook.com> <CO1PR11MB488112E5FE83F6C36E19E05ED8F90@CO1PR11MB4881.namprd11.prod.outlook.com>
In-Reply-To: <CO1PR11MB488112E5FE83F6C36E19E05ED8F90@CO1PR11MB4881.namprd11.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:4537:3354:1495:3c15]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: e39ff4c0-554e-41e6-d004-08d892cad40b
x-ms-traffictypediagnostic: MWHPR11MB1709:
x-microsoft-antispam-prvs: <MWHPR11MB170992337346A08CD0A5E8CAD8F80@MWHPR11MB1709.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: yIoWQIBvMuUo0PjteehLNdasEGO7AfHL8jG/KP643NrwxdJU0atRUpuoWbfUX0d6jREt6sioNfnSwZSITxfke14dPufl4QOsnBhPunP7SRqFuaMHMkzgP6735KRH76NM3KEW8NpS9q4r26nCWT4EbE5iSemVHSEjXBwMeTKnWBUVhdWuXo+F13j7AkNRcOq77GeAAdJnpCbzAtkN+2+bGucVTbkDyPjes5lU6dsAppFOX6Shy3PutSnFS7PzudUAw2M11fP/wL8PLtsYE+pgyHCWsxcSC2A7l2BpoeDwAJ0miS9NsazRgxafDYcXNcd6bf4j4lcQ7ZjiHh9sKAp0r2XKcSJkxfAW2X70RInuzv9GmvwfgXAKpkQtLtf97eyC1ahBGH8ebO1Jy5kN9FkVnQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CO1PR11MB4881.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(366004)(376002)(39860400002)(396003)(346002)(52536014)(53546011)(6506007)(7696005)(5660300002)(8936002)(8676002)(2906002)(33656002)(64756008)(186003)(55016002)(66946007)(316002)(6666004)(71200400001)(66556008)(76116006)(66446008)(66476007)(9686003)(166002)(478600001)(30864003)(66574015)(966005)(86362001)(83380400001)(6916009)(559001)(579004); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?us-ascii?Q?7xonj53pt79WiamUGsQi4WGIxcLcEtmG3ERuQOAKSwQ043IRd9MyAFqlMNM/?= =?us-ascii?Q?vmszOSAVUTY9UVOef2muRDqNgK0lMP3cgYC5PVVr6c5GSMdt7on1KQzx4TyC?= =?us-ascii?Q?3/17PSK+0/irwZozq4zxXZZ3aLNRIX+5WuFEX3w9hmFFsgtZJF+dMhO364bA?= =?us-ascii?Q?vurymZzOVI1MmaAos1gG0sIqtzWVfrTvdEgQ0/fVI6PRJLo4UdmXKjJFR42i?= =?us-ascii?Q?3wffFIn9S3cx22nZzRWurRMAM7AsDm5g/nKgrsTMhDewnoYaRLs0gzBWGFrP?= =?us-ascii?Q?CX4Gyb9g70+EYY6EldunBboYZy5PsY5SYJNNXPK31E/49LUXEwjyF1pcAMUD?= =?us-ascii?Q?f6s5Jy+MmJA3qDv2lpg1v+6QyFCR5R3/vNnUCbyznPE/10OYAptJRsCrCTCC?= =?us-ascii?Q?gdgumd3yzNQlyXJLrgxVnIJ9P+h6KRS6iwHf9xhoeEzf5+rbvdpxhiUWrdhR?= =?us-ascii?Q?gsenals1iGu7fLV9jiKWK6kMzE8lcqs/MMV8+wSJVKOnkIDqzSzXWaEifGHy?= =?us-ascii?Q?96CskUzCHbsqstf5zn1UMn9GZ3M56BeZ61Np2ZBx4zgUwAjgISmM8mTdoSNO?= =?us-ascii?Q?zX8AlObLtp+G4U5d7GBli1fVTBfwvWI8i73xlj/SQfzgXZrUgqmTP0jBQBAe?= =?us-ascii?Q?B1hkjzoWm02ZYh1ubiHP12Ka0mn0zAhUSu+xh/rmWBScOfcMsv1A9FgNNBPR?= =?us-ascii?Q?F9M/K47+MbsI2O25XeevlTi59MFChJi/I2Q7DNAJOi5mkJHw+rHI77QEqWWC?= =?us-ascii?Q?6Oh3cOJp9LJ+JWwNhtPBuPXztyEruFaeIFlSwajhv+146kHaHQZBxKS6l5HZ?= =?us-ascii?Q?WVNH8TRxrfGN6GY4Sx06YLtgjXjZVY17Jl1hcGEb2vSxuWZf8HVXWg40L3aQ?= =?us-ascii?Q?RZqsNT2blCTIwyzE//TIYXiupLlefS70eH+S3aPACzysiLkBYUj+7JptDQlZ?= =?us-ascii?Q?pbG2Tu53vpfMRtUdOSwo7e00ngDElgtngbDmMQGffpV5znKFCyNCp5b3IoT7?= =?us-ascii?Q?/ixJ5v5yyceKhVlZcuZ6uIN+kO9+jQ0HUeBg3qWfqGs9bR5nUpfkAmSVD217?= =?us-ascii?Q?5+uQoU1Z?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_CO1PR11MB48819304E7BE2BD815A8DB42D8F80CO1PR11MB4881namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CO1PR11MB4881.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: e39ff4c0-554e-41e6-d004-08d892cad40b
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Nov 2020 11:51:51.0243 (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: +qEDGuZc3MIzGbj/GmL/A7NvznJKY2Nb9ACTiFD0RPiZcMD5r13EFVUiUj70tJYcZNiLUpQT+SFrEzMW6Egb7Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1709
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com
X-Outbound-Node: alln-core-11.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/HX8hSis17dIR2ZPufm9ITTqk1Z8>
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: Fri, 27 Nov 2020 11:52:00 -0000

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> On Behalf Of Pascal Thubert (pthubert)
Sent: jeudi 26 novembre 2020 11:47
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

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> On Behalf Of Li Zhao (liz3)
Sent: jeudi 26 novembre 2020 03:45
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,

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