Re: [spring] SR and DetNet, draft on sr-redundancy-protection

"Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net> Mon, 19 July 2021 21:44 UTC

Return-Path: <zzhang@juniper.net>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C08003A0BB3; Mon, 19 Jul 2021 14:44:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.548
X-Spam-Level:
X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, 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_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=iPL9BK4s; dkim=pass (1024-bit key) header.d=juniper.net header.b=Qmj8tHw2
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 CarmmCVHJuQt; Mon, 19 Jul 2021 14:44:07 -0700 (PDT)
Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3636B3A0B91; Mon, 19 Jul 2021 14:44:06 -0700 (PDT)
Received: from pps.filterd (m0108161.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 16JLf8SH010654; Mon, 19 Jul 2021 14:43:55 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=T6/AtE5q07fuIkOC68LH4hW4QTj9VfiVpzpV6qGgMPE=; b=iPL9BK4s3NUVHPnW8QImlO99ElzB15GXoQ55x94v0zcPz3puVAKXZjgpzjFduFSvcGMn xLWbNwOME31IP0HCDu+K+1tkcwlrgWhUpbOuv7W68cHsxHc64wkB7+cv6kXvS+xUBpn1 VBwRJVyc8p3yUIkE7fsBpbXI/iHmhksHHAH7/NxfbHo8ZYHAFtkWHgueiEftNHTvJBOs oZdJreZJLPSp98s7qehMovZCJT84qiMvYoME4ajgfp5CzzJoWZvzYSBbmrDc5Xn41EST TkU/iQ2rXkavwz35Ez4LPLxg4Pww52EAKGycrNw+uZ2SNFI9ZsaaC7Dg9HE2trY30lBn xg==
Received: from nam10-mw2-obe.outbound.protection.outlook.com (mail-mw2nam10lp2100.outbound.protection.outlook.com [104.47.55.100]) by mx0b-00273201.pphosted.com with ESMTP id 39wh2d81wh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 19 Jul 2021 14:43:54 -0700
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KnRVeUJMKPrQCmMxev6vIyy0CehF+grEVQ+6wLNnvZ4e48I//l49O7/+KkyTsjOZnVP1976ylzdlYnf/vqL54Q6hU7CMHOKSWYw1ycmJ+dWyIF30xGT0a91Vof8x32VCeKd8IUD63mNMnqR9IgIcyb6+KPUR1CfW09lbtbDEfGQVt1zyE0ZWGpDQh0t3d7eBdMJFqDh1uHH4YiBSb3L7xWdZW/N6G9/1U7cXAjdjM+kT71hKhJ2zcP9EEhdJZpARZSDzSfWqoidCQ3RlNmWLgmY43w8DJe7Z8SyboQzC5zyQ5Yh4Pczox5hPlJJ3S8j99yRLqHa9NBu1W5VVgp0+wA==
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=T6/AtE5q07fuIkOC68LH4hW4QTj9VfiVpzpV6qGgMPE=; b=fXla745hol9aVRCce6lKzljddR7RRuQr0GR/G90qGabSvWbKJXt++OxCYvgFWF14zNmEg398/jr2w+uiY7x+gPO1viCOY6QBdYE9j65l4ZOj4AYd1GqS+gVSe4DR+I1Wbmnuhj+8Z7C0YsKAFnw8CKoT3TuukxoPeELCob5YLIjs2R4vC5gp8CCy9CSDmA7l7Ar3Kfc4Q4qx9bHtGtwrz5P0baUEHH9akOWUrGVS+9yR9fo04JgFl1lSfK2ELYHefmzVzRPkY587AA0g3igKpfJOaJ4QEKfTjErCdACFZmw0pPvvJqu/IVaquFyyMG3qY6nfS3hFjGy7Gn3SWscoyQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=T6/AtE5q07fuIkOC68LH4hW4QTj9VfiVpzpV6qGgMPE=; b=Qmj8tHw21ZuJjbiP/FMB7KlAAqNu+ccHzDskLP0V5sb4+ZOkWR46qcSeTupROWsA3h2/zA9qik+yhcaeSPStlKXLakpHb9LiTSnVT0nwlNeeTM0MCoc78iMya2RHZoEk4o0IXJRjvMoGsTKMY5i23tdHKDZS3zFQubwddj0fTPM=
Received: from BL0PR05MB5652.namprd05.prod.outlook.com (2603:10b6:208:6a::19) by MN2PR05MB7087.namprd05.prod.outlook.com (2603:10b6:208:179::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4352.8; Mon, 19 Jul 2021 21:43:52 +0000
Received: from BL0PR05MB5652.namprd05.prod.outlook.com ([fe80::454f:fd4:90e2:3b2f]) by BL0PR05MB5652.namprd05.prod.outlook.com ([fe80::454f:fd4:90e2:3b2f%6]) with mapi id 15.20.4352.022; Mon, 19 Jul 2021 21:43:52 +0000
From: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>
To: "Yangfan (IP Standard)" <shirley.yangfan@huawei.com>, Balázs Varga A <balazs.a.varga@ericsson.com>, "draft-geng-spring-sr-redundancy-protection@ietf.org" <draft-geng-spring-sr-redundancy-protection@ietf.org>
CC: spring <spring@ietf.org>, "detnet@ietf.org" <detnet@ietf.org>
Thread-Topic: SR and DetNet, draft on sr-redundancy-protection
Thread-Index: AddewvSL8KiUghQTQGO6l6GoThOP4wAdSB4wB2tquhA=
Date: Mon, 19 Jul 2021 21:43:52 +0000
Message-ID: <BL0PR05MB5652F5021CD0F9471D0911DAD4E19@BL0PR05MB5652.namprd05.prod.outlook.com>
References: <AM0PR07MB5347AE468EC4B5BA146C6013AC349@AM0PR07MB5347.eurprd07.prod.outlook.com> <d840f86867f347bfb52223b96f43fc19@huawei.com>
In-Reply-To: <d840f86867f347bfb52223b96f43fc19@huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
dlp-product: dlpe-windows
dlp-version: 11.6.100.41
dlp-reaction: no-action
msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=70b9a5b2-83fd-4913-a162-b098391c6f24; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=0; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2021-07-19T21:33:45Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4;
authentication-results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=juniper.net;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 9fd2ce1d-4c73-449a-2ade-08d94afe4cfe
x-ms-traffictypediagnostic: MN2PR05MB7087:
x-microsoft-antispam-prvs: <MN2PR05MB7087D15A593B7CA34B2C08BBD4E19@MN2PR05MB7087.namprd05.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 2GmU7McAYn+eHhV69fQnI+xZoW6wkkQEPQMf9xFkHvLi4MPFlH8SKxcbB/6mtMBvd6nArikV4vPa5myp/fPMpEKfgET5+352nrwf66OzX3bMyDXDBz8h+pEdEivtjjSqa3h5aula0eyiJePZamqORpcAV74JILaLN+OYQfIvczkbawXxu32A56PSfYByKhNb62EfykN218eRFRWFnAvNuw2BdlJ2cCs2h68/NCu/2ScEDTfntFexvQGICQhKIo/PmDVfLG0jmWNQWwNtW2VoyEgFAazyq1AgmQpuAmTHE3X1H5p7rSP4jRZAKMvECG2VKxnM0xtzK6DhP5nPCCJE6/Oj/FGAkw0C8JtEC/vchhbWo1EXCediQUpJ23OZS2W1qj2HlR8wkUtVDw6r5JHGSY60NrGCf8PpRALnXGp2nePe09XYE6+cd3TwGFdENj7N/UQyuoDRK4l9s9qRvZcmLE+XNFavzZNTLQVA/hWAAT4OkwtMFad7rC3CeIJa3N1miOyNu83WAUs+6EhX46aZPcVkVkUZj3AGZ6WRnEKtizZFEvLaiFb4zEtuAoGY6MYkBgoOyUDUaopPltSgeYmwh9PEjrOF5n+qlnY84Aqfy6iN2zDeKdxlNLAi2M0FOzAZRGYYVzrEtstuPrN5ZaqD32Jh6ciDSWGAuVELCdBB6Mfkp9J0b30EfQeyUD5iGYEpFvbRmkLwQXt78rrqTkMLQAhCJ/FcpYtv13SbZTEUifLhzgrydOR8+qTe7TaZVq+tBOFhwvQy3EDE9m8ItqHTcrLTs5cR/piwXK4unZaCkNI=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR05MB5652.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(316002)(33656002)(86362001)(186003)(83380400001)(53546011)(5660300002)(52536014)(110136005)(8676002)(54906003)(166002)(6506007)(2906002)(508600001)(9326002)(66946007)(122000001)(9686003)(26005)(7696005)(8936002)(38100700002)(71200400001)(4326008)(66574015)(76116006)(66476007)(64756008)(66446008)(66556008)(55016002)(38070700004); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: woM9aqxdWN+nI6calEZ6wCfZZDBY+9C1MkkK9xywluvaDCQHRvR8/rarlHW75VFTJi5i7VtiVOTOSpITbZMc71B3ojhJjgZdmKuo4oe5NaTA2mAQfTpiFion83hQZTp5MZ+4HXuGM613xrDb8XMsR/zZU1sWWduZA0ZOP21XZqRd4Dw3z14jMqLmt1Z4USZ8zsfMHXZpKN/D9U0eIBZ3MLh6UeP/pd/xOc4LbjFCbyEavh/aHln7ydf6PGMcSryTL3yXzRHUYRfGFQrivhNvhgEA8WETNA5WU+huyV+3JneuET74iw55o2Cib+qC5Up7txH+QjuCmasBSfmxpiYdZrEJ7kemNW3+9G4RpXn/HAFckuXdtndoFj4NILcqUAlVMFFbwjyEfQwYA2xzcpsMmFmwVoK+2wXZJODzLTootLMz7EqSKddmCT4quaBUl8ofF9/8ihDgIDVcDX97BFbtJe8xtvYsQF8lw22Q2IBmyYMqDkI6sMYDYCGyO6B8NSbSXqYQWy5sSZmbTTKYY4mq6rEy/ObW4iZAauli8O0UfTXTxxUw1EJiUgYhQuwxqTstRWz9EuzsxyTwCz9BSM7Qy3F6sDLmA966/sCCh+Uf8TwLDoHXJ5UZNsucMqL5Xv3bPqfrZgGTNYaQ7OZB+HBAWK5wSPgtXnn94QqUa90QFo48fTUiz++nednGORcynrdUPVVAIdTz2KYqBNc7DOnmClkv+gVld34ltBpPObQxV55FB4dBR+GsifmpSyXQrkHW7XvH4mg99LJM81JCVH8zpXge90QbsMFqNWQPONbiwyy7RRZbK74t1D48og9p/SR+GLEHuoQ8+ATjY0jpvZNw0f2ZE4sZlPqyn7azFCgXCHG4NfB37qjGPI1A/Ot+vKwSZea7BJ+n3xDjmFthDwwBmjfAm1iQx7VwPyhlqqoS6TC5XHgPJfSH7TF+oXWkjmt4VEceQhupxFaKBIe+PEme+zZvvTEtI6P9NDmWr9AYRgLu02LRjPyK/6n2fd6ykN5YWsTNa5bsGyV6ZjYJZedstDkLEV9zNWIIb+Ztq6Hf7p0roTNIpyWQuptC/a2g4c11E+OVHsvZjA6D1Ax92m2UGhTixgAwELTtuq5PfVMVq/a7S0sNpXST3rTeRHU3J0hFyINhvq5SOlHdkmuvQIw4zMvxEO1SaKmQ2PkAlfVbvmqkdWAPxpx69LKgoxvOxv7kRb6QRCI0XQP0PtC53/+28amvRm8bfFovcHp9RCZnpU8jsH1+rrEg/SwxRsL9h8r3OwEUWfuJEhLwPMXtpdiM/DZx6FJR8qNu7HpvH2MoTF12VpZY+KIOPdUuBbEdUTAy
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_BL0PR05MB5652F5021CD0F9471D0911DAD4E19BL0PR05MB5652namp_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BL0PR05MB5652.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 9fd2ce1d-4c73-449a-2ade-08d94afe4cfe
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jul 2021 21:43:52.1121 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: e9Tf89NHaLmLwxBg4A/s+ohN9ZOohYxnZgn1aGKhnLxHEiYwu7jzWl1vq7xKLMWdziFgSXUjnTYP1qYemfWx2Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR05MB7087
X-Proofpoint-ORIG-GUID: dBeIzj-Q7S_XIkUcPMukL_vJGAQGKy8W
X-Proofpoint-GUID: dBeIzj-Q7S_XIkUcPMukL_vJGAQGKy8W
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-07-19_11:2021-07-19, 2021-07-19 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 clxscore=1011 impostorscore=0 malwarescore=0 lowpriorityscore=0 bulkscore=0 spamscore=0 mlxscore=0 suspectscore=0 phishscore=0 mlxlogscore=999 priorityscore=1501 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2107190124
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/95x9mMIaqE1SaCHTkdoBxzdQKdM>
Subject: Re: [spring] SR and DetNet, draft on sr-redundancy-protection
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Jul 2021 21:44:24 -0000

Hi Fan,

Catching up on this late …

You said:


  *   Triggered by the discussions in SPRING, I think we can define redundancy segment and merging segment as a functional segment without routing and topological semantics, and use different segment for the routing purpose. Thus, redundancy segment and merging segment are segments with pure service semantics and don’t violate the sub-layers definition in DetNet architecture.

Are you alluding to using replication segment for the routing/forwarding purpose? In my late response to an old email of yours that I just sent (https://mailarchive.ietf.org/arch/msg/spring/YyEb8kGgtXxITZaIGyxynp9wh9s/), I also said “the redundancy/merging functionality can be considered as an overlay service that makes use of replication underlay service” – so maybe we’re converging?

Thanks.
Jeffrey

From: spring <spring-bounces@ietf.org> On Behalf Of Yangfan (IP Standard)
Sent: Saturday, June 12, 2021 2:07 AM
To: Balázs Varga A <balazs.a.varga@ericsson.com>; draft-geng-spring-sr-redundancy-protection@ietf.org
Cc: spring <spring@ietf.org>; detnet@ietf.org
Subject: [spring] 答复: SR and DetNet, draft on sr-redundancy-protection

[External Email. Be cautious of content]

Hi Bala’zs,
Thank you for your comments. Please see my reply inline starts with Fan1>>

发件人: Balázs Varga A [mailto:balazs.a.varga@ericsson.com]
发送时间: 2021年6月11日 21:12
收件人: draft-geng-spring-sr-redundancy-protection@ietf.org<mailto:draft-geng-spring-sr-redundancy-protection@ietf.org>
抄送: detnet@ietf.org<mailto:detnet@ietf.org>; spring <spring@ietf.org<mailto:spring@ietf.org>>
主题: SR and DetNet, draft on sr-redundancy-protection

Hi Authors,

thanks for the update of your draft, to clarify the proposed mechanism of
redundancy protection.

I have concerns regarding this draft as (1) the SRv6 approach does not follow the
DetNet architecture, and (2) repeats functionalities that are provided by the DetNet
service sub-layer but with serious limitations.

(1) DetNet has defined two sub-layers: the service sub-layer and the forwarding
sub-layer. The service sub-layer is responsible for service protection and the
forwarding sub-layer provides forwarding paths and resource allocation on top of
them for the DetNet flows. DetNet specifications allow to use any technology in
the forwarding sub-layer, including Segment Routing.

The SRv6 approach described in "draft-geng-spring-sr-redundancy-protection" breaks
the clear concept of the sub-layers by mixing them up. It contradicts to several
points at least to RFC8655 (DetNet Architecture), RFC8938 (Data Plane Framework)
and RFC8964 (DetNet MPLS Data Plane).

Fan1>> Segment routing extends IPv6 by introducing SRH extension header and SID programming. From the perspective of SID list in SRH, it provides the explicit route to IPv6 data plane in forwarding sub-layer. From the perspective of SID programming and Endpoint behaviors, it provides the packets replication and elimination in service sub-layer. So Redundancy segment could include the routing characteristic and service indication at the same time. Similar happens to Merging segment. I think this is why you called it breaking the concepts of two sub-layers and mixing them up.
Triggered by the discussions in SPRING, I think we can define redundancy segment and merging segment as a functional segment without routing and topological semantics, and use different segment for the routing purpose. Thus, redundancy segment and merging segment are segments with pure service semantics and don’t violate the sub-layers definition in DetNet architecture.
Besides, in RFC8655 4.1.2 DetNet data-plane overview, it says,
This separation of DetNet sub-layers, while helpful, should not be considered a formal requirement. For example, some technologies may violate these strict sub-layers and still be able to deliver a DetNet service
I think SRv6 could be acceptable based on this.

In addition, I guess where to encapsulate meta data could be one concern. According to DetNet, they should be identified and encapsulated at SR edge node. We plan to include both possibilities in next update. To carry them at SR edge node would be recommended as the first choice, and thus does not violate DetNet architecture. Right now I still want to keep the possibility for redundancy segment to add meta data for some corner case.

So far, I didn’t realize there are other points contradict to DetNet RFCs. We are very happy to discuss them.

(2) The motivation for "draft-geng-spring-sr-redundancy-protection" is not clear especially
as the SRv6 approach seems to be repeating DetNet service sub-layer functionalities; however,
with a limited set of functionalities without any clear benefits.
Fan1>> as what I said in previous email to Joel, redundancy protection comes from service protection specified in DetNet, but more focus on how to do it when Segment Routing is introduced to MPLS and IPv6. Currently, DetNet defines IP and MPLS data planes for DetNet in RFC8939 and RFC8964. There is segment routing consideration in RFC8964, but not in RFC8939. In our draft, we try to focus on definition in SRv6, and for MPLS-SR just obeys the specifications in RFC8964. It is clear that we are not repeating DetNet service sub-layer functionality, but to fill the gap between RFC8939 and SRv6. If WG thinks the SR-MPLS sections are redundant, we can take reference from RFC8964 for simplicity in next update.
I don’t think there is no clear benefit what segment routing brings to IP(v6). By using the redundancy protection mechanism, DetNet services running over SRv6 don’t rely on IP+UDP/TCP tuple to provide PREOF. The authors believe this draft is meaningful.
Thank you for bring this topic into DetNet and SPRING. I take it as whether SRv6 is worth to be specified separately besides the existing DetNet data plane RFCs. It is a valid and important question for DetNet, we may need some guide from the WG.
My 2 cents.

Best regards,
Fan


Cheers
Bala'zs


Juniper Business Use Only