Re: [Roll] Transit vs. Target in P DAO

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Fri, 25 September 2020 20:15 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 337613A08B8 for <roll@ietfa.amsl.com>; Fri, 25 Sep 2020 13:15:33 -0700 (PDT)
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=XinWwUPG; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=ljShAxhD
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 bZgSBQMQLD5X for <roll@ietfa.amsl.com>; Fri, 25 Sep 2020 13:15:30 -0700 (PDT)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAA723A08BA for <roll@ietf.org>; Fri, 25 Sep 2020 13:15:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=89893; q=dns/txt; s=iport; t=1601064929; x=1602274529; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=cVeHRtzxHfwFR5HWfpk97usoDWq8EOEFC+0H4lOSGLE=; b=XinWwUPGH6Gf2uoD2cO0zl3S5LgnwA/mziCdarV2xNBL0cd4V3p89IUO 0Y8fNdASooFP4Pr6LqETSPDZQ43qCFNiW0zuSra+KmNIrhSEis/xAtwyG KHLcQ6Wp0xOiECq9p6dFX7fG7H6qyIcr3/r//PSfQnHzxq4MGqKldz8MV o=;
IronPort-PHdr: 9a23:YyeOuhLoTCypFldXhtmcpTVXNCE6p7X5OBIU4ZM7irVIN76u5InmIFeGvK8/jVLVU8Pc8f0Xw+bVsqW1X2sG7N7BtX0Za5VDWlcDjtlehA0vBsOJSCiZZP7nZiA3BoJOAVli+XzoMEVJFoD5fVKB6nG35CQZTxP4Mwc9L+/pG4nU2sKw0e36+5DabwhSwjSnZrYnJxStpgKXvc4T0oY=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CmBQC3Tm5f/40NJK1fHAEBAQEBAQcBARIBAQQEAQGCD4EjAS4jBigHcFkvLIQ8g0YDjX+BAokMjmiBQoERA1AFCwEBAQ0BARgBDAgCBAEBhEsCF4IXAiQ4EwIDAQELAQEFAQEBAgEGBG2FXAyFcgEBAQECAQEBEAgJBBkBASUHDAQLAgEIEQEDAQEhAQYDAgICHwYLFAMGCAIEEyKDBAGBfk0DDiABDqxXAoE5iGF2fzODAQEBBYFHQUOCdQ0LghADBoE4gnKCXEtChlMbgUE/gRABJxyBT0kHLj6CGkIBAQIBAYEhGAEBAjUPB4JqM4ItkBMVIYJwhwAmi1SQPVEKgmeIe4lCgxGFCQMWCYMNjzeJAYVLnW2Cao4KgSSDCAIEAgQFAg4BAQWBayOBV3AVOyoBgj5QFwINjh8MF4ECAQGCSoUUhUJ0AgE0AgYBCQEBAwl8i3QHgj8BAQ
X-IronPort-AV: E=Sophos;i="5.77,303,1596499200"; d="scan'208,217";a="565562587"
Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 25 Sep 2020 20:15:28 +0000
Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id 08PKFPhY015319 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for <roll@ietf.org>; Fri, 25 Sep 2020 20:15:26 GMT
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 25 Sep 2020 15:15:25 -0500
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 25 Sep 2020 16:15:23 -0400
Received: from NAM10-DM6-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; Fri, 25 Sep 2020 15:15:23 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fRAD2eMaZhOd1BSUJz2c4mwbSGQ8mfpLtrDqwg52OVmP6loUDl45pA+1A10o54qTxIAnX7Xj1IgJ8mOweJmPqFXnqOC3O76hAlzeoLMX1mgsYpesEo6F52zaNVdwLVxz3V0NZbJsTbGi9qugrZrb6qzcvbgkxeN3M3wjoWwobJQuv5fq3CB3imDryANPWiwlVj+o5R7xp5ikMrNKTVRm45OjCUJugPV6MinI+MRO0Ev+qO6wX5NVnz7v/Z+fMIEszLZoxl34mp0rCnuCmBMb6mSLE6cj8vu3ulTZpEe8cmvXceoExJ4afK0Lpugw8I5s20hfMhy1qgbRahZzZc05jw==
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=cVeHRtzxHfwFR5HWfpk97usoDWq8EOEFC+0H4lOSGLE=; b=L51JuGAU9/PkMEYlNgsdOZzVI8/HKRGkdgNzDJkhGt8lFNSSyLfED+5MAtIvjxgUewBYUtvcUL1uYzWZ/sB7w0ZdSrDcfYxCZ/OTpsP3tMSpsYmW9jj9LmxLakxpHmVlbT8YIaP2FgjSelprU1csr/6k8NixHohBwmXY0FpWeeQDAE8QNBVxemj7ED1xc8lk7KEfIjBNCIEmLqXgtXKdZ26nIpUXeJVY6wFIG5Ijk8y+62006QJd/pMzCqse8cTdCOGch/IOU+xve/12hOVdb5LujKRHGvBxiqghQJgRn1Ddqvb52+EYJxOKRpJbROOywLqzVurO5Pj8ZWVRSNR+8A==
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=cVeHRtzxHfwFR5HWfpk97usoDWq8EOEFC+0H4lOSGLE=; b=ljShAxhDbyZrUhH/CLo6ar5wwgr2dkVGa+LOAJNTrX8DuWsBVveNRC/gqSHKT5s0Sa3ubR2AtZ6xbI0UW06D6IF1qFJNKKxqDbEOQMTJ5naqdxH8d1Dl3QhJKVqk4Lqy+ZXCg5cT7w4pkxH6WLttrr7QbJj2m3P0zjC9+inRaiQ=
Received: from MN2PR11MB3565.namprd11.prod.outlook.com (2603:10b6:208:ea::31) by MN2PR11MB3629.namprd11.prod.outlook.com (2603:10b6:208:f0::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3391.14; Fri, 25 Sep 2020 20:15:22 +0000
Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::119:f851:5860:da95]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::119:f851:5860:da95%4]) with mapi id 15.20.3391.028; Fri, 25 Sep 2020 20:15:22 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Thread-Topic: [Roll] Transit vs. Target in P DAO
Thread-Index: AdaQxACW+9AEP58UTgCAyyDLmy9JbwA+H2KAAAAgcuAAOTQCgAAa/vSgABGID8AABQIGAAAEKSPY
Date: Fri, 25 Sep 2020 20:15:22 +0000
Message-ID: <E7F1781A-DFF1-4B61-B9B1-66B72405182F@cisco.com>
References: <MN2PR11MB3565E58634AC61AD90C18B87D8360@MN2PR11MB3565.namprd11.prod.outlook.com>, <51EFCCF8-A6AA-4E39-8DCE-B264CCDCD039@getmailspring.com>
In-Reply-To: <51EFCCF8-A6AA-4E39-8DCE-B264CCDCD039@getmailspring.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
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:7d03:eb11:f616:bc78]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: f744479e-5d59-452d-3074-08d8618fbb57
x-ms-traffictypediagnostic: MN2PR11MB3629:
x-microsoft-antispam-prvs: <MN2PR11MB3629B2DB521E42611F294822D8360@MN2PR11MB3629.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: OsxqdVEELVMvcX40vEXyBuU9wj4Xf58y74dH8GhWFu5p2/epAEDwbSpvSashMTTWHSpEDQ+BmQtFkRAYXH00wCUnAcYZzwKyi/NX3J9JXSabiXwbtbKWjpH1lTlpea9hNt6tkh4hOgyZ9p3KL2GwfhAM1/i3BlK3f5eqyW1/LQi23wYOIAxyQTqKvPnLwS+1Tjad6OFaiXMIEH5dKTOR0eRSOL9SmFhpjQLSIbcGRlf0S16s31UV/Ip08DSGvBcGHFRk4Gw/LXgZFXpjsZwfV/rqW7UucVB42SGarmv7ZcQHl67EtsT0YFvXFkcw0/NWJFhfMKBH1mh/p/dGGCSr2OvZ5k+iluof8FXr8if5qYEqRR/XU6HkxrJ3qPeWbc7GrMZkm34aSv92hCtZvknXazKjbaNQ7Ev4HYYXeh7vqBllZrZOvMJOofNdBHF0OulZbIJdvHh+QtqyYwGckLBUpZtYkSp1Q36iMtzk4cGW4W2xCwhK4wVR8T+262GWPrQF
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB3565.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(136003)(396003)(346002)(376002)(39860400002)(33656002)(30864003)(66446008)(478600001)(86362001)(66556008)(76116006)(6512007)(91956017)(8936002)(66946007)(316002)(8676002)(64756008)(5660300002)(71200400001)(66476007)(2616005)(166002)(36756003)(2906002)(83380400001)(966005)(6506007)(186003)(53546011)(6916009)(6486002)(66574015)(579004)(559001)(244885003); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: A4o2802SBlZg4asIP5cNWUtvBHz6BN6ucHYImu6Z2dx1P/ZzQ+X0GamM1uVy4vJMISB4Hbgni9phor/mqjju1eynu0zbcOmSDpEAV+dd9xH4zdP/VtzLmudJSdyJ9OJfk7xpw1uPYThJZlB6cvHqOuKmtu7UN/Gj4aRtYvBF5aCMveoqF2FgHdKYERcybI4w8vSAinn1r255GyYaHQJcmyatQ4kyRiphaBnDYRgf8SQkLDJEjMJNr1UD/bdJIp6nrOHPUJpmRpoAtboq4KYxHa2Tc984vMnYqjfT7mioWc43+tYY/cwFBszsYy2ukAW2kyUQMJ7d5+IcyhZ6UYGvFxzCI11XAGr3UZvBT0MEppWG6lPFOTMF8icNDpYwwswWtNoN4sIr4uthoEPprosvQdk6Nnsjue6/PZqP4o8AeXIP5Qmf/6CTFxT8cJM0Ch98tAfyNbB+dnYIi5Vrooqb6vz3C2NbjtUrwUR8X2uHHmGEZH/a7j53W7Bn1HuNPu/0UlJ1ISq23uhUeTTSuZi5YTkWOhsh6cdOtmuDE9mf3uBBFE03qynYZXGKKE2rGIdLIvm7YcrHPYsS5iQ/aI83PClWezQkEGbCGb9O2lQtT+D/XpMzDWf3gjJlsq7wFsaAhpnmTvM3Kp+ogcuWRanZyIlE3DtcYj5R5UCd6qah0KNd0C0LHGGLwc+s1+dr1Pkqv1ZiBhXXR455PnufT0K58A==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_E7F1781ADFF14B61B9B166B72405182Fciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MN2PR11MB3565.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: f744479e-5d59-452d-3074-08d8618fbb57
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Sep 2020 20:15:22.2727 (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: zx5jygZo3IJeEIMcoyJd54WDoNBOUwtth2M07q3LwuIHEuoF43meF1WTe9wUfv7+lI5n41GlJy35E9g/nPE1hg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3629
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com
X-Outbound-Node: alln-core-8.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/NoSiZJLp_adPHnivnaH3W-8djh8>
Subject: Re: [Roll] Transit vs. Target in 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, 25 Sep 2020 20:15:33 -0000

Hello Rahul

As specified today the PDR is issued by the Track Ingress but if you think relevant we may add something to the PDR so that any other node asks for it as well;

Any suggestion?

Pascal

Le 25 sept. 2020 à 20:16, Rahul Jadhav <rahul.ietf@gmail.com> a écrit :


Very interesting!

But, wouldn't this mandate that only Global DODAG roots can initiate a P-DAO request?

Isn't it currently possible for a local DODAG (with local RPLInstanceID) root to initiate a P-DAO request? If yes, then the DAO base object cannot be used as mentioned by you.

I didn't find any mandate in DAO projection draft that local DODAG roots cannot initiate a P-DAO.

Regards,
Rahul
On Sep 25 2020, at 9:29 pm, Pascal Thubert (pthubert) <pthubert=40cisco.com@dmarc.ietf.org> wrote:

Hello again Rahul and all



The Track Egress is the Root of DODAG that we build and we call  it a Track.

For a Track, the RPLInstanceID is a local one, that is associated to the Track Egress, and we call it a TrackID.



Now, trying to make work the below, it seems better that instead of using a TIO, we could signal the Egress and TrackID in the DAO itself as follows:



        0                   1                   2                   3

        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       |    TrackID    |K|D|   Flags   |   Reserved    | DAOSequence   |

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       |                                                               |

       +                                                               +

       |                                                               |

       +                        Track Egress                           +

       |                                                               |

       +                                                               +

       |                                                               |

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       |   Option(s)...

       +-+-+-+-+-+-+-+-+



                      Figure 16: The DAO Base Object





This seems to make more sense than using a TIO.



Works?



Pascal







From: Pascal Thubert (pthubert)
Sent: vendredi 25 septembre 2020 09:56
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Subject: RE: [Roll] Transit vs. Target in P DAO


Hello Rahul,



Yes, this gets quite a lot of things to put together but in the end it is not so complicated if you have a picture to look at.

I’ll make some for the interim.



My to do’s on this draft for the next version:



- Align the “serial” vs. “Complex” Track terminology between 6TiSCH, RAW n’ ROLL.



- Create an initial format for FIO based in DetNet.

  -> Do you see any more field we’d like to see in there, e.g., the capability to inject a Track in another?



- Describe that the TIO points on the tunnel egress, and that routes via the tunnel are signaled as targets in RTOs

  -> a side effect is that the sequence and lifetimes are now taken from the TIO so they are not needed in the (SR)VIO. This makes good sense IMHO.

  -> should the route to the egress be automatically added? There could be times where only some flows should go there. Maybe we could use a flag in the TIO to signal it?



Many thanks for your help!



Pascal







From: Roll <roll-bounces@ietf.org<mailto:roll-bounces@ietf.org>> On Behalf Of Rahul Jadhav
Sent: jeudi 24 septembre 2020 20:38
To: Routing Over Low power and Lossy networks <roll@ietf.org<mailto:roll@ietf.org>>
Cc: Routing Over Low power and Lossy networks <roll@ietf.org<mailto:roll@ietf.org>>
Subject: Re: [Roll] Transit vs. Target in P DAO


Thanks Pascal for the detailed example. The problem stmt is now clear to me and the need for TIO with parent address of egress node.
Few comments inline.


Best,
Rahul


On Sep 23 2020, at 10:09 pm, Pascal Thubert (pthubert) <pthubert=40cisco.com@dmarc.ietf.org<mailto:pthubert=40cisco.com@dmarc.ietf.org>> wrote:

Hello Rahul





> Currently, the draft allows the Root to send multiple RTOs which could contain the egress target and all the (immediate) children and siblings. The VIO option list would contain all the hops on which to install these target routes. Doesn't this already handle the problem statement you mentioned? Using this the root can install routers not only to the egress but also to its immediate children, isn't it?





I thought so, but I felt there was something wring and digging I found it.





> Is the point to not install the route on behalf of egress but only for the egress's children/siblings? Is this the objective to achieve?
It would be great to have a sample topology to base this discussion on.





Ye, we’d like to be able to use the Track to reach siblings wouldn’t we? If so let’s look at signaling and encapsulation:





The “Track” that P DAO sets up is a path between a pair of nodes, call them I and E like ingress and egress. Currently E is indicated in an RTO and the Hops in an RPO (VIO or SRVIO).





If I talks to E, it can do like we do in useofrplinfo for Root to RAN, that is create a packet with destination (that is E), an RPI with the local RPL instance of the Track (rooted at E), and an SRH if this is a SR VIO. No encaps.





Now say that we want node I to send its packets to one of E’s sibling, S over the Track to E. Still following useofrplinfo, node I needs to encaps the packet I-> S in a packet I->E to add the RPI with the local RPL instance ID that is taken from E’s name space, and possibly an SRH.





We also see that signaling that we build a Track I->E (which comes as a aside effect with a route to E) is not the same thing as signaling a route to S via the Track before.


[RJ] This was my assumption which went wrong.
I not get that, to send a packet to destination S via E, an encapsulation is needed. The outer destination is E and inner is S. For node I to create this encapsulation it needs to know that node E is the egress for S. The proposed TIO(E) option identifies this.


There could be many S nodes reachable via the Track to E.





Thus my proposal to encode S in RTO, E in TIO, and then the SRVIO. There could be multiple RTOs as usual, for all the siblings and children of E that we want to reach through the tunnel, but only one TIO since the track (tunnel) has only one egress.





So we’d get RTO*, TIO, (VIO | SRVIO*) . Whether E is implicitly a destination or we need an RTO for E as well is to be debated, see below.





It can get worse: say that a child of I sends a packet to E. Following the default route, that packet reaches I. I needs to decide whether to use the default topology (via the Root) or the Track. We have not really defined how that is programmed in I, but the current text says that the P DAO routes have a better admin distance, so current text says we use the Track. With DetNet and RAW, it’s flows that get routed over the Track, signaled by a 6tuple (https://datatracker.ietf.org/doc/html/draft-ietf-detnet-ip-07#section-3). So really we’d need another option that carries the 6tuple (say  a flow info option, FIO) and use it as we use the RTOs to signal which flows are routed in the Track.





In that case the P DAO would have (FIO|RTO)*, TIO, (VIO | SRVIO*)





Did I make the problem more clear?
[RJ] Yep. After reading through detnet draft, I now understand the need for Flow Info Option. Need to re-read the draft considering this.





> One another point: The draft talks about "serial Track" .. is that synonymous to the "serial path" you mentioned in your mail. Does serial Track indicate a track with a single projected segment? Would be better to have this term described in the terminology section in the doc. Thanks.





Yes, I should use only one of the two. 6TiSCH defines serial and complex Tracks (see https://datatracker.ietf.org/doc/html/draft-ietf-6tisch-architecture-29#section-4.5.2). OK that I align?


“








   A Projected Route is a serial path that may represent the end-to-end


   route or only a Segment in a complex Track, in which case multiple


   Projected Routes are installed with the same tuple (Target address,


   TrackID) and a different Segment ID each.





…






   An RPO indicates a Projected Route that can be a serial Track in full

   or a Segment of a more complex Track.  In Non-Storing Mode, multiple

   RPO may be placed after a same Target Option to reflect different

   Segments originated at this node.  The Track is identified by a

   TrackID that is a Local RPLInstanceID to the Target of the Track.




“


[RJ] Yes, we can align to this.




Keep safe;





Pascal





From: Roll <roll-bounces@ietf.org<mailto:roll-bounces@ietf.org>> On Behalf Of Rahul Jadhav
Sent: mercredi 23 septembre 2020 17:16
To: Routing Over Low power and Lossy networks <roll@ietf.org<mailto:roll@ietf.org>>
Subject: Re: [Roll] Transit vs. Target in P DAO



Hi Pascal,


I have a few questions in the context (with respect to the problem statement, not proposals):


Currently, the draft allows the Root to send multiple RTOs which could contain the egress target and all the (immediate) children and siblings. The VIO option list would contain all the hops on which to install these target routes. Doesn't this already handle the problem statement you mentioned? Using this the root can install routers not only to the egress but also to its immediate children, isn't it?


Is the point to not install the route on behalf of egress but only for the egress's children/siblings? Is this the objective to achieve?
It would be great to have a sample topology to base this discussion on.


One another point: The draft talks about "serial Track" .. is that synonymous to the "serial path" you mentioned in your mail. Does serial Track indicate a track with a single projected segment? Would be better to have this term described in the terminology section in the doc. Thanks.


Best,
Rahul



On Tue, 22 Sep 2020 at 16:35, Pascal Thubert (pthubert) <pthubert=40cisco.com@dmarc.ietf.org<mailto:40cisco.com@dmarc.ietf.org>> wrote:
Dear all ;





Say we are building a serial path using P DAO: in that case,  we are building a tunnel from the Track Ingress to the Track Egress, where the Track is signaled in the packet by the local RPLInstanceID in the RPI and the destination IPv6 address. The outer header may also have a SRH in case of non storing P DAO.





In the current version of the P DAO draft we use a RPL Target Option (RTO) to signal the Track Egress and the new Via options (CMOs) to indicate the hops. But say we do not want to reach the Tunnel egress but one of its children or siblings. How can we signal that these guys are reachable over the tunnel?





Proposal A)





If we want to be able to signal that, it could be more consistent with RPL to use:


- one or more RTOs to indicate the targets of the route, can be any of the children and siblings


- Exactly one Transit Information Option (TIO) to indicate the tunnel egress


- then one VIO or one or more SRVIOs (as we currently do)





The result would be that the Track terminates at the “Parent” indicated in the TIO but can be used to reach any of the children and siblings indicates as targets





Proposal B)





Maybe we want to signal that only certain DetNet Flows should be placed in the Track. In that case, The RTO is not sufficient and we’d need the 6tuple. If we take that path, we’d need to create a new Flow option that is a Flow descriptor, in which case we’d get


- one or more Flow Options to indicate which flows  are encapsulated in the Track


- Exactly one RTO  (as we currently do) OR Exactly one TIO (as in Proposal A) to indicate the tunnel egress


- then one VIO or one or more SRVIOs (as we currently do)








What do you guys think?





Pascal



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