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

"Huimin She (hushe)" <hushe@cisco.com> Wed, 09 December 2020 06:18 UTC

Return-Path: <hushe@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 E8DEF3A0CBA for <roll@ietfa.amsl.com>; Tue, 8 Dec 2020 22:18:39 -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, 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=M/RpAyow; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=nopzOn4K
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 klopbN01ABpR for <roll@ietfa.amsl.com>; Tue, 8 Dec 2020 22:18:36 -0800 (PST)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DF333A0CB8 for <roll@ietf.org>; Tue, 8 Dec 2020 22:18:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=33574; q=dns/txt; s=iport; t=1607494715; x=1608704315; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=71eVB0N+fMSoSo+n2aVNn1HY+Bx2impXwI9Y5573QPo=; b=M/RpAyow9nrNe2METjMIoqfkTGIdxps2tDp/AAh+WAsuMzH5EfDMXDez eANgR0bsswfWoLP1HTa/+u6vSNQRHRG5r1DZ25mVmvyh/vxlCh0SAs1r9 54rDtNC1wUXm8KYv2oi6tyHCeab4TvJKr9e+nlQL4Vbx+TptZZAjiHoTJ s=;
IronPort-PHdr: 9a23:QM+rmhNIJmih2/EDomQl6mtXPHoupqn0MwgJ65Eul7NJdOG58o//OFDEvKw33l7EQYud7OhL2KLasKHlDGoH55vJ8HUPa4dFWBJNj8IK1xchD8iIBQyeTrbqYiU2Ed4EWApj+He2YklYBMi4YEfd8TW+6DcIEUD5Mgx4bu3+Bo/ViZGx0Oa/s53eaglFnnyze7R3eR63tg7W8MIRhNhv
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AiDAA0a9Bf/5FdJa1YCh4BAQsSDECDISkoB3VbLy4KhDSDSAONOCUDgQWOBYl/gUKBEQNUCwEBAQ0BASUIAgQBAYRKAheBZwIlOBMCAwEBCwEBBQEBAQIBBgRxhTQIJQELhXIBAQICARIICQQNDAEBJRMRAQgRAQIBAQEDAiMDAgQwFAECBgoEEyKCfwQBAYJVAw4gAQ6hTQKBPIhpdn8zgwQBAQWBNwQMQUSCegMVghADBoEOKoJ0gmZOQoZZG4FBP4EQAScMEIFXSQcuPoEEgVkCAgEBFYEMDQ8eBxAPEgKCXTOCLIFpWAYBYxQbAwYLCAgfAiwPHggCCwcrGQEGBBoBLhoYD48HJDKCeIdQnTUKgnSJHolniDsDH4JnPIoklG2TeosLkUQID4Q8AgQCBAUCDgEBBYFtIw2BSnAVOyoBgj5QFwINh36GIwwMC4ECAQeCRIUUhUR0AgE0AgYKAQEDCXyHSC2BBgGBEAEB
X-IronPort-AV: E=Sophos;i="5.78,404,1599523200"; d="scan'208";a="836914423"
Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 09 Dec 2020 06:18:33 +0000
Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 0B96IYMJ017806 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for <roll@ietf.org>; Wed, 9 Dec 2020 06:18:34 GMT
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 9 Dec 2020 00:18:34 -0600
Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 9 Dec 2020 01:18:33 -0500
Received: from NAM10-MW2-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, 9 Dec 2020 00:18:33 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QAUkGmWMVIKfG85IPaCETdaa8PzCvnqM5TZ0ddc96sW6KezuSfw0wnqnVPwEyg/HFIwT1Z0jrSK5WK9Hy+mKHK512y6iBjxsoHbUX5BaYL/D4WEyWqOrPdmbz0f4k2FD+1mymXLwhIEg8cA3nKtjQpU9X9GdQikHd7GTLISa+6tMTEgorKctqFIYOtcMjCtFEhCzuYoeZV2hSk53EipjZ5uX/IDkjq6PoxSu9+mMzau6anwn0QDFO0LRS7E2nO0MM8i5U6DdUDhdYDSTI5qfk/F3fA+QLKrZGUF7bZtd1ngZKtnd9URlRx5BII80V8mozrxu6uZgvjCl9VG7OqJxTA==
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=71eVB0N+fMSoSo+n2aVNn1HY+Bx2impXwI9Y5573QPo=; b=Uh2Y0ijWKYrjL5N3T45K+7neOu7/F9SUpWb4cIVjacgXAcJUBpG/mKgzveVR8b9fT+GUjVWD4NtmtmFOMIDqsrgA4XiD7ZFWqMeYj0sst/d811dHG/rdiuF5tiF03VeFyK2bVzNXffDyg0gAU2TCe7z64brNgikWMNYb3ffTiIISn1K+i7pF/VG37Uo6FVnOx27Ld6D93xak6irk/ezUxOdQL7cyDXEfxvKGDpApH4V4kpKtBnHE//Nj9j3q4221nXkf9iM43jSvuZjTiJrGw52H/VdQcPxVSScuhZ/2FCzVTCNppZHqHuJFi/qxzMVXu9WIX586QIAr147gyKkizA==
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=71eVB0N+fMSoSo+n2aVNn1HY+Bx2impXwI9Y5573QPo=; b=nopzOn4KRgW4TOjt8mxHNewu2iHGvPExWhIHEWyV0/RiBxn2lCbTEWjswDVafrzcVHSI/B6xrSagxu254UT/5cjHUTGDi6K3X3dNoJUY+ZUW9aHAQIkrklqpPZpvjcavU31dVX0UFVFKA9zHNNLyXnEIGZKtBKOYiB6xiyPiaRE=
Received: from DM6PR11MB3803.namprd11.prod.outlook.com (2603:10b6:5:141::30) by DM6PR11MB2810.namprd11.prod.outlook.com (2603:10b6:5:ce::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3654.12; Wed, 9 Dec 2020 06:18:31 +0000
Received: from DM6PR11MB3803.namprd11.prod.outlook.com ([fe80::51a2:6f3b:817c:8dc8]) by DM6PR11MB3803.namprd11.prod.outlook.com ([fe80::51a2:6f3b:817c:8dc8%6]) with mapi id 15.20.3632.023; Wed, 9 Dec 2020 06:18:31 +0000
From: "Huimin She (hushe)" <hushe@cisco.com>
To: "roll@ietf.org" <roll@ietf.org>
Thread-Topic: [Roll] Make P-DAO bidirectional [extends] IETF 109 open Questions on P-DAO
Thread-Index: AQHWzfMdmrIloDNomE2Ns+gKyu5Y6Q==
Date: Wed, 09 Dec 2020 06:18:31 +0000
Message-ID: <6BF749EE-85B2-4300-8095-59D46ECFBFB5@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.39.20071300
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: [64.104.125.234]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: e14ceb71-7a74-48a4-0472-08d89c0a4077
x-ms-traffictypediagnostic: DM6PR11MB2810:
x-microsoft-antispam-prvs: <DM6PR11MB2810BF92757FCF90164CF2B3A3CC0@DM6PR11MB2810.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: HHqE2IJYZF9ObJW3iLV5WU0gwRaJq+7elD2NqipsmkPUEZfKwBM+WFJ7C30zm1Aszbt0BFkwx1XzPW/SCQCNQHh/RZkcwRN/nFk28LiMMjOaeJlX6DKyY32VFa3J5wccjTXmrW0oodsi8Ty65FXZOyNrsi6vsmxqbpkkGDQ1RWTApTqLwbCtFwFts8Se+B0KLAZV9FjmRsNvvTUq/3RYvqv1EQZzuMKYMeG+/I2U5TQbHgeviOr/wONN9+JPOB8LyyJAsgDagp6ycH/VPbe2/Ta0Jl13VUH0C7CZfjNB/d6xEf1b6NTECa0I91EkeMi/rx7r94ZdiJAhHBHX9j6X5HXCg6noNG2bDhls0hMIgdO8ReeV2rUTvvtTsaEQ20jMm5MQR3dBHh+RPn44xWOeVxNy60hLHyP4PptWJJHhzRXcnplOjlB7j9FO/gvDk6ciSVF87TOjYXBn9Xu0oFbIZQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR11MB3803.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(376002)(396003)(366004)(346002)(39860400002)(136003)(66446008)(26005)(966005)(86362001)(316002)(36756003)(186003)(91956017)(76116006)(33656002)(6512007)(6916009)(6486002)(53546011)(2616005)(6506007)(66946007)(66556008)(66574015)(8936002)(4743002)(71200400001)(478600001)(8676002)(66476007)(30864003)(83380400001)(2906002)(64756008)(5660300002)(45980500001)(579004); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: LoqKDlUy27Jz5tfqmaaCtRWLGc5viGAY1ItasJGT3GckU18wMURQOLQjjioiUxYxqiGseDyJO305Hp9D0g+gb/w9hDG4aVHFmQ8+D4I3XxI200qt2M+Z5BV9A6Lf2rgemlOsq6whB2hqVqAIaUqapnSRIqpe5UOeUC+l+rKJgBB0nQFYuIAT3THHjd6IHirTuifn9NmhWqsVJK+13RRq+fVt8+IozbmAy2Niy+SJa7Tud99KN/VcSquUvd3tkD9azgh4vPx2IeMZe9WStDB/zuAn4FagxqrOiAluf72aYwDbtselNehYQh1uxNhRIliz7W5VHd6EQDutZxTM9P4S7jjjbKf/Ww+9WF3a4nqzLDFa5o9ShKLiRH6NPp3Yn4r515WW/p3FSjMgOyIBtrBVijJPTH5inzUDdjPVZYbBcZYay5J5SZTL0PhABxm49n7S7Waz7lovcYUMN+kojKv0rsZPTsoxIV4mWVpOVvOckjfljvt/i0xprJQZQRfU6AV4nUBkvGspEFTLexpAWr1VShWckbmu/TJ+xIdXcg5zwOQGKVlWpudxE74a6Obn48HEY8z3QG+fNENp4ZjBS6H6KM0t69gNXpaHq/m9/MRXvNSMXPeLznP6RUMmN87j5C9ipkvl+QgzLu/7t7reXrwZDRohlSddrV23jK/m85zkHe2XZko6LyYNoFh1ZigJ2v/uQn4cNU+PquINeVnqGnxzybrXIEibavefjbb4Z4NPd+c5RDhu8R1GPUioXq0va1W62EOb82FDtcvxlmUkK/sblSsQEvbBnRjVJVHvbG+wJld1xVZOOKOjftF+Uru6c18TLrYZBzcLqLnFm5K0fWaRWY3+LrgkZp+Z38uTkV6AwPqdBQbuhG/UlLpyPpQhuu3wbskBc8B9b1GJfyzMNM3Yp7FAVdrqtMcS7zDo2RtlQQEOvXO8CULkYbg/DGwRCqdsCFCIgYHb86YFgVq4FK8EWFmgb0X4GNmFfCBtCSF72AoYKS6Z2Sz2LHK3aZJcbHXU
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <3BC56C34D989A84E88A329B825DD95F8@namprd11.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM6PR11MB3803.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: e14ceb71-7a74-48a4-0472-08d89c0a4077
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Dec 2020 06:18:31.7313 (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: exHJWelRdivWOmDgNaUd682W7YqsWxbUWzM4YI0x19vq+wHSpY0JQ9Gm+49OwnJk
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB2810
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com
X-Outbound-Node: rcdn-core-9.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/aW6-WsnmgVx3PtXaSarbIcRz_RY>
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 06:18:40 -0000

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@CO1PR11MB4881.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