Re: [Detnet] draft-varga-detnet-ip-preof

Balázs Varga A <balazs.a.varga@ericsson.com> Wed, 04 August 2021 10:11 UTC

Return-Path: <balazs.a.varga@ericsson.com>
X-Original-To: detnet@ietfa.amsl.com
Delivered-To: detnet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B9953A11E7 for <detnet@ietfa.amsl.com>; Wed, 4 Aug 2021 03:11:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.542
X-Spam-Level:
X-Spam-Status: No, score=-2.542 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_H2=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
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 onvobUIMJHlm for <detnet@ietfa.amsl.com>; Wed, 4 Aug 2021 03:11:17 -0700 (PDT)
Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00064.outbound.protection.outlook.com [40.107.0.64]) (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 956DC3A11EA for <detnet@ietf.org>; Wed, 4 Aug 2021 03:11:16 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lhrTpaKUfn/wWb+nowUqGZS5+SDalaolbIh6g4jkre+yKW2tF8PEiNhTImUWd9UfbaY2VPgURdipD1tI3nYFeTJJZVpf1IIKsofFkhaaE+Nlymju2NH+ngguB4WvDF+6XACoz4mT6nrdCTny4779u8D93cikc0ZFSyHalvyLYOJEeA0RE9w2t3VPjAZqsOb06FDCV67f6EJUJ35w/G5KynzAhmql9skM5/RXYdMGGNn7kfF+YzBhCCtEqHlDv3UZtZ+3GectEnrh8b7bYhWMpTMyyiroF2sJ2mmK8g06hCEGmUPYUDWHU3+ES0PsnE3lBewWpyjZTRgmRAdS2cTX4w==
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=GGmv+7aFDyCTmw5zD55soDUzH5+94gkh2R+R5cm7wUw=; b=jZOCNTXfAHr4PefYxRo94RnCanmCTKyqQhLwjWQ23VDttjv8k0WOhC9Jca2ckc/wkhFEWsvfVCP35uVzbgnJVnZft1nnetei2930tSXKY+7VJyjfTuvGThCDHubdSllmNGYB+npwftyDaY4JBXiBaq1zDpE7DwkJhoF+qoc+RvgTXvxzlo+eAA2pB16yj21BWEK0ORVDI6jEvgSqD66/0AV83m2BEbWP/KJINaWy4zxTOMK5fPqtTinmOQPv5ARioSzHMSmsADDikwcaTise9L0FZlRdUm9QglWqJr84ee5kA84q9gSkR3KoQikZeG5fBfPynzhHelVyfuO89yU59w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GGmv+7aFDyCTmw5zD55soDUzH5+94gkh2R+R5cm7wUw=; b=KwdZz/mOf+AcGHhNkJiHToRUzEIua/fktXHw02fJawuaJsvROpupjsv7/Q0eXFgyhbLpmRy3idxdeFFTLUkBtdPCB/VAkZUIv3nd1FrSAin89+th23sMNZgPUbRbVtifeZaEAcaMLyt74OaedkZx5AqhR6sYf/OeB6fREkW+EI4=
Received: from AM0PR07MB5347.eurprd07.prod.outlook.com (2603:10a6:208:e7::31) by AM4PR07MB3171.eurprd07.prod.outlook.com (2603:10a6:205:8::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4394.13; Wed, 4 Aug 2021 10:11:12 +0000
Received: from AM0PR07MB5347.eurprd07.prod.outlook.com ([fe80::ecfb:cec6:9d16:e437]) by AM0PR07MB5347.eurprd07.prod.outlook.com ([fe80::ecfb:cec6:9d16:e437%5]) with mapi id 15.20.4394.016; Wed, 4 Aug 2021 10:11:12 +0000
From: =?utf-8?B?QmFsw6F6cyBWYXJnYSBB?= <balazs.a.varga@ericsson.com>
To: "Pascal Thubert (pthubert)" <pthubert=40cisco.com@dmarc.ietf.org>
CC: "detnet@ietf.org" <detnet@ietf.org>
Thread-Topic: [Detnet] draft-varga-detnet-ip-preof
Thread-Index: AdeCJhL5qclO3ipmQnOhnkjJnCiKCAAE+ubAAAYMvuAAA3HbcAAA8i7vAaxgKjA=
Date: Wed, 4 Aug 2021 10:11:12 +0000
Message-ID: <AM0PR07MB5347A00815E7D75D19F8A19BACF19@AM0PR07MB5347.eurprd07.prod.outlook.com>
References: <CO1PR11MB4881E860FF54BFB6CF04BF39D8E89@CO1PR11MB4881.namprd11.prod.outlook.com> <AM0PR07MB534784B537193F4F88241045ACE89@AM0PR07MB5347.eurprd07.prod.outlook.com> <AS8PR07MB8298836F25EE12742C278B44F2E89@AS8PR07MB8298.eurprd07.prod.outlook.com>, <AM0PR07MB53475FF5EC7C92D8285A27F0ACE89@AM0PR07MB5347.eurprd07.prod.outlook.com> <6E1BB2CC-FDCE-4F97-9036-894B7C30B904@cisco.com>
In-Reply-To: <6E1BB2CC-FDCE-4F97-9036-894B7C30B904@cisco.com>
Accept-Language: hu-HU, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=ericsson.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 0544b513-1ae8-4ed6-b2f1-08d957302ff4
x-ms-traffictypediagnostic: AM4PR07MB3171:
x-microsoft-antispam-prvs: <AM4PR07MB3171F2E660D34E27A3A495A6ACF19@AM4PR07MB3171.eurprd07.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: mJuw2Hge9tOV/Q9cvmT/WX4+KWFIsbF8fbzcSo07sU4oLfmixivUcQg+jFR8ZSFE1RNNhcRHIJX+sW6sdSeiNjw9zToT2hm4z2OLo84DzccuOE3XESp0hNAJsF1aCU3yL2/Wpu1YcovR71mM+b4wIEQU8PsTIdrwwBtz44maRxK8/PC8jOeyfZHY0x3Jw7dP9rlEfUkx14jF4PgBNUQ3Uyuexz+wkBmpnK2AtnND7VKz2t+9vYLR1RHWN7dtAVxtwUSZw6wn8Kj132RT6HB1xxwrMNC40ChidHiuVa++TlA0Cn2p0hfC/ZnO6WAMJ70SLL9tB9cnFxzvrOaBdYHybpNwNdy8LsxcK8jvYqCKFE58NR52IKjR7o2ezbiknb+rOCxl23SIWQbOwdV3Mw8ZhsTqaC3ShwuznGr7PbhiLWgDhSjGEs5kf5jPdZD0Ai+UuP4+7yaB03k7hz8pewVOLNUeZm+PMndqloB0SMfLycVOIW9lbLcsBAMBduy9AXCUCGLWMsFMmWwzPQ8RFcl3wIQmeps5Hai9Hb7HAJwwsSnhkNhVihHN/W8i6/URXsKsYee8etca1gL7WlkHRdbVZCkv+esKA1IckETMj7PUE4Mq9ClSf/wizg4/7PFgv6EaIDj97wYznFuaYnIheFBYr3C8eDo1P7Q2rFNElTyFY9hq9VpY3Uxqh9ljOW7PPI8tqtsTM9mesK86DWP89iQEAkX4vU82k32VhgerictcIjzl0uUpe0hrzy+nSQ3QRP0WKI05zQ0ci6iRrQZjRVxqYvYPiMKNgESgf/r58w+IwY4ecZSUTfKWsIySmjoRoA83
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR07MB5347.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(366004)(39860400002)(136003)(376002)(396003)(5660300002)(122000001)(966005)(4326008)(7696005)(38100700002)(52536014)(33656002)(6506007)(71200400001)(53546011)(9326002)(66476007)(55016002)(26005)(66946007)(64756008)(66446008)(66556008)(38070700005)(316002)(85202003)(85182001)(83380400001)(166002)(186003)(66574015)(86362001)(8936002)(478600001)(9686003)(2906002)(76116006)(8676002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?utf-8?B?SDBpeDZES21jL0xvWk1mbGt6eXNSU2ttSGdWNVpKdS91UVFMRk9nNGdpUDRs?= =?utf-8?B?TTRKa3F6a0JPR0g1VTNjVjNwVWM0MWQrRXBFcnRiVHJYQWhSYkFtcXpsbHlQ?= =?utf-8?B?MHQwRVJYQWVZZnhyaTMwcEEzR3hTYjJXYUFqMDQxRkpjcFM5d2dTVmpZWFhV?= =?utf-8?B?TURTQzdSRVJROVZDcGx2NTJ3YUVxamhCZW4zRy90YjBMYVhESFpZemtodmxB?= =?utf-8?B?NVd4M2FoU2l2bGo1L09xa09JTjQ2L3ltdUFpNSt4ajhldmYxbzFyUk5QdVpu?= =?utf-8?B?RGEvakZqa0JjWmUwNllzdk1wSzVnSUNDQlVIM1VUNCtJbi9xRDgrZmpFMEQy?= =?utf-8?B?L3lOcTFwWXl1bzZhOFY5bTVlQWdMQjhEUlZmWEdhcDZvQllHZVB2VUNKRlh1?= =?utf-8?B?Wld2VjV5WlR6R3lJc0RxY1NPYk5FTmtRODdQc1QycGVtZHBaQWlrRWI2ZDh2?= =?utf-8?B?RlJ3cHc1RjJsUGJ1amMvaTNIY2l6b1BmMXhoNjBZQnNGTnMyMERqVDJOSkxU?= =?utf-8?B?RE9jMXkzMFNXb1hudXUvSENlNXZKcmZXcTNHVE5odDh3M2pvbW1Yak5ZaGow?= =?utf-8?B?cDBaZDZpd21EeEhlbWRmY1pnd2tqWGtFY0g3REVUT09qV1dHcE9oUWkxOWRE?= =?utf-8?B?cTlkVHNIZkJLaStnLzVTdER2TjN2ZWswa1g4bEU4MjFKc05XVVJ3ZFlBbk5V?= =?utf-8?B?ZzNTRms3UFkwZkNyYjlRNWNYVUZtVHBncWtTcGpsR2N6SU14MFhiYW54Mzhx?= =?utf-8?B?YXVFWFlqaE1oMUxBLzZaZy9seUJoWHZvZzdndnU3Q2R5VDlKb0VaSm01bTN5?= =?utf-8?B?aW9yTUI0Nm9ZQXJuWXBIVzZNWEpWQjRId3N2MEdsR2pyYkptWDNsNFNpQUJk?= =?utf-8?B?MkhmeU8rRFBVQUx1bnl3bk8wYzVObXVqdE1TQ2pnaGJPTnhRS1BFSko5Umk1?= =?utf-8?B?OVlack0vUFROeWFHSHMveXQ2MUczeVRYamIxSzZFM2c2bWw4RWVlbXZyWWh6?= =?utf-8?B?WWRCTndGTUJpeGcvR2IrOUdhZElRSGMyZlRzeDZaMGhZZGFuTXA0QnRJVU5z?= =?utf-8?B?U3BZSUJTdE9pYjVkamVpQ1RCRmVwZDk3cmlzTlk5NUtjSkV4cUNXR2VrQjVX?= =?utf-8?B?MXJ3OThheU9OM1Z6K0dBT0dST1VuMmdIRzN0eCtqc2IzRFFHUkUwZmxvc2NB?= =?utf-8?B?cjkrajRZN3VRVUNvWTNiQThxY3kwQS9QdWFNYkZ2c1RHQ0REcittallMR0g3?= =?utf-8?B?bzdBNjBlTytWQmNtdTE4ZkpId011aXZTbExMRU5PSkxkc2F2b2cvNlBqWklV?= =?utf-8?B?ZVpibGlaZFpJZWdkN3dpbWkyaWl0ZUxUelpqQ2FaWnI3ckN5ZFk0c3dnbXYw?= =?utf-8?B?MjRFd0J1UFRtcE4za0hUbDFzVXluenpvcStIWUN5b1Rzd285N1BITWFUa250?= =?utf-8?B?eHNrRWhVNG1pK1NyWlBFb3FIUkF0UUZBeUpGU1NhWFdNOWF2cVo2TjRTRzZq?= =?utf-8?B?OUpROG5lcExjOWFRbmR0b3JoMThEdis2bkNoS3NEOVk1ZzNQUk1TUVAxeVlQ?= =?utf-8?B?MG95V0RhbFJpQ3NXeXMxcGdOdGlJZFRvNWtUdE5EZkI5ckhmTEhtVmVrZkxM?= =?utf-8?B?R29aUTNnS1VQSVk1YnZrNXVScmNlWDVDZDljS0J2Y0MwcVp5VFJxUXN4c3J3?= =?utf-8?B?K0h6UlRsRTN1ZVAwZGZMOW53SXRZL004alEyOTFaQmU1Vjg2VTVPQTFGMkpt?= =?utf-8?Q?8xFNbQi9HyMBTbuD2MSgpExKvpb0v7Aq0Ky9W/u?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_AM0PR07MB5347A00815E7D75D19F8A19BACF19AM0PR07MB5347eurp_"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AM0PR07MB5347.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 0544b513-1ae8-4ed6-b2f1-08d957302ff4
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Aug 2021 10:11:12.2989 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: vXtw3ooHPGKQK4vwI2xz7riv5gDYCEQz50Xq8bBEabedrYSSXHmK8s2vMZUHPc71Hh0QMgLZsBXa06edtpKh6fd1bLexLuDjlLoFsHC3q1E=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB3171
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/8w7erPa_PDfi0fSOPDnS7PH1m5g>
Subject: Re: [Detnet] draft-varga-detnet-ip-preof
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussions on Deterministic Networking BoF and Proposed WG <detnet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/detnet>, <mailto:detnet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/detnet/>
List-Post: <mailto:detnet@ietf.org>
List-Help: <mailto:detnet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/detnet>, <mailto:detnet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Aug 2021 10:11:22 -0000

Hi Pascal,

Many thanks for the new comments.

Yes, forwarding between relay nodes (doing service sub-layer) is based on the 6-tuple.
Aggregated flows use the same UDP tunnel as defined in Section “4.4. Flow Aggregation”.

Regarding your concerns using UDP: It is the same for all UDP encapsulations. We have
not changed the rules of RFC9025, this draft reuses existing DetNet data plane building
blocks. :--)) It provides DetNet service sub-layer for IP with minimal effort (i.e., minimal
standardization and implementation effort). No new header fields are specified. It is a
generic IP solution, already available both for IPv6 and IPv4. And it does not require any
additional processing on transit nodes.

Thanks & Cheers
Bala’zs

From: Pascal Thubert (pthubert) <pthubert=40cisco.com@dmarc.ietf.org>
Sent: Monday, July 26, 2021 11:18 PM
To: Balázs Varga A <balazs.a.varga@ericsson.com>
Cc: detnet@ietf.org
Subject: Re: [Detnet] draft-varga-detnet-ip-preof

Hello Bala’zs

Many thanks for the clarification; I expected that the aggregation label would signal a common path but from your response it seems the draft still relies on the flow to find the path, based on the 5/6 tuple, correct ?
<BV> Yes, forwarding between relay nodes (doing service sub-layer) is based on the 6-tuple. Aggregated flows use the same UDP tunnel.


My bottom line stands though. Aggregation and PREOF may happen inside the network. And it means encapsulation. Going all the way to UDP will make the header to insert and read bigger.
<BV> Yes, this is the same for all UDP encapsulations.

 I understand now that you place only service layer information in there, but that still needs to happen at wire speed, and bigger headers can be counter productive for DetNet tput and latency, and be more complicated to implement in hardware.
<BV> We have not changed the rules of RFC9025, this draft reuses existing DetNet data plane building blocks. :--)) Scalability and aggregation


Do I miss anything ?

Pascal


Le 26 juil. 2021 à 23:00, Balázs Varga A <balazs.a.varga=40ericsson.com@dmarc.ietf.org<mailto:balazs.a.varga=40ericsson.com@dmarc.ietf.org>> a écrit :


Hi Pascal,

Many thanks for the clarification questions.

Please see my comments inline.

Cheers

Bala'zs





-----Original Message-----
From: Pascal Thubert (pthubert) <pthubert@cisco.com<mailto:pthubert@cisco.com>>
Sent: Monday, July 26, 2021 4:00 PM
To: Janos Farkas <Janos.Farkas@ericsson.com<mailto:Janos.Farkas@ericsson.com>>; Balázs Varga A <balazs.a.varga@ericsson.com<mailto:balazs.a.varga@ericsson.com>>; agmalis@gmail.com<mailto:agmalis@gmail.com>
Cc: detnet@ietf.org<mailto:detnet@ietf.org>
Subject: draft-varga-detnet-ip-preof



Hello Balázs, János, and Andy:



In prep for next Friday meeting I went through https://datatracker.ietf.org/doc/html/draft-varga-detnet-ip-preof-00. I have a few questions that might be too much for the mike, and considering the short time we have, I thought we should start here.



- At first glance the draft seems to be placing the DetNet MPLS dataplane within UDP. If that is the intention, what are the benefits vs. using RFC 7510?

<BV> No, this draft is not about putting the MPLS data plane into UDP.

This draft is about how to provide PREOF for the DetNet IP data plane in a simple way, with no new header or data plane definition; but leveraging existing ones. That’s why it is informational.

That is, this draft leverages RFC 9025, which leverages RFC 7510. It is applicable both to IPv4 and IPv6.

Key point in this draft is that DetNet PW (S-Label + d-CW) is placed in UDP. It is very important that there is *NO* label switching along the path.



- Some of the labels in there are needed at every hop to select one or more next hop(s) along the DetNet path. Can it be a problem to find that information deep inside the packet?

<BV> No, the DetNet PW information is used only at relay nodes (as per rfc8655 those includes DetNet service sub-layer). Intermediate nodes (transit nodes) do not need service sub-layer specific information, so they do not need find anything “deep inside the packet”.



- There can be variations of the label stack, e.g., fig 3 vs fig 4. Are the labels self-describing? Else, how does the forwarding node know what shape of stack to expect?

<BV> As the DetNet PW information is used only by relay nodes, they know by configuration of the service sub-layer (e.g., PREOF) how to process the packet. From service sub-layer perspective it is the same concept used in rfc8964.



- I'm concerned about the aggregation scenario. Contrary to MPLS, an IPv6 intermediate node is not allowed to insert headers, in particular not after the UDP header. So it seems that the aggregation proposed is always done at the end points. Is that correct?

<BV> Aggregation just works fine. Any relay node can perform aggregation as UDP tunnels are span between relay nodes.



Please consider the following picture from RFC 8655:



   DetNet                                                     DetNet

   End System                                                 End System

      _                                                             _

     / \     +----DetNet-UNI (U)                                   / \

    /App\    |                                                    /App\

   /-----\   |                                                   /-----\

   | NIC |   v         ________                                  | NIC |

   +--+--+   _____    /        \             DetNet-UNI (U) --+  +--+--+

      |     /     \__/          \                             |     |

      |    / +----+    +----+    \_____                       |     |

      |   /  |    |    |    |          \_______               |     |

      +------U PE +----+ P  +----+             \          _   v     |

          |  |    |    |    |    |              |     ___/ \        |

          |  +--+-+    +----+    |       +----+ |    /      \_      |

          \     |                |       |    | |   /         \     |

           \    |   +----+    +--+-+  +--+PE  |------         U-----+

            \   |   |    |    |    |  |  |    | |   \_      _/

             \  +---+ P  +----+ P  +--+  +----+ |     \____/

              \___  |    |    |    |           /

                  \ +----+__  +----+     DetNet-1    DetNet-2

      |            \_____/  \___________/                           |

      |                                                             |

      |      |     End-to-End Service         |     |         |     |

      <------------------------------------------------------------->

      |      |     DetNet Service             |     |         |     |

      |      <------------------------------------------------>     |

      |      |                                |     |         |     |



          (RFC 8655) Figure 5: DetNet Service Reference Model (Multidomain)



You'll note that the DetNet architecture allows for endpoints that are not service-aware, in which case the service layer information is logically owned by the PEs. A PE should be able to add / remove stuff that is relevant either within its domain (e.g., PREOF using SRv6 with Xuesong's SPRING draft) and / or within the DetNet Service Domain (across domains 1 and 2 above), e.g., redundancy information, excluding the End Systems which may encrypt their payload and may not provide anything usable for redundancy anyway.



As a specific example, the aggregation should be feasible between DetNet-1 egress PE and Detnet-2 ingress PE. In IPv6 this means encapsulation, and it makes sense to minimize the incremental size. UDP in UDP seems a lot doesn't it?



My bottom line is that if we want intermediate nodes to add and remove stuff, it has to be thought in terms of matching encapsulation and decapsulation. IPv6 has EHs that are designed to fit in such encapsulation, possibly together, like an RH for replication and a HbH for path and redundancy information.



What do you think?

<BV> Again, the DetNet PW information is used only at relay nodes (doing service sub-layer). Intermediate nodes (transit nodes) do not need service sub-layer specific information and do not “add and remove stuff”. Aggregation and the DetNet service reference model just works fine with this solution, which just (re)uses existing DetNet data plane.



Pascal


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