From nobody Mon Jul 26 14:00:40 2021 Return-Path: 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 A58B73A0FD8 for ; Mon, 26 Jul 2021 14:00:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.541 X-Spam-Level: X-Spam-Status: No, score=-2.541 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_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham 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 i_rysiPpRaT9 for ; Mon, 26 Jul 2021 14:00:33 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80044.outbound.protection.outlook.com [40.107.8.44]) (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 23B173A0FD6 for ; Mon, 26 Jul 2021 14:00:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WnDeXD4PSwq/1wpeqICjgih5oiZnMLrARanGBJjuIsM7r+LRLiuWLtMy20wjZx7j9F7zD0dYls6mS+XGRiZbC37buKtN7H3AhlXQ9p3keu5D1WeIoI7Onbwi1G8lCLTilH6Q645NVShtjlwAP79B5H8r9STs6GrrG2NurIr2/Zr/mr0ICihBE+A1f1x1+jENVhTjfIKGytgkC4lcGgylgof5KOqqEdMO3w6XIOdrj044xApOjsOpOqa5pQ6aGyJb5dZOYtbVZOmWavbob2vbPh5iZfyGsB7u+PencEaTB++Gvb8/X4f39P1uk9vlP2PLO//+fW/uAMzQ72D/W2+yOw== 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=SOIUhkSLQH77HWNFhnco6adMstZN13+BxxIriuwmBiA=; b=Fj+PDPFTYX5w12OPPzV8SSFftiUTcQ3/tC6NGjiV57nsuZ5Gh+X59CCYrXQqx9woq9q0A7juLapJnlzschvaMm9xLri8zhG7yXpyJMOK8I4X9qkvjqD97C0f+M6Z8HRM9PyPCgKK3D0xn/wjOrhGs8N4FK0ThlsVlTgGMLDFF0BSepjXH1yoM5yLR+VuQL3JfdHlezZ4QPaCk/I8QXZ+9iFNYzK/FDoWTjibLIYPgITcTHBDZHhPt1d3zM9jf7DDMgon8/MM83rJddpuDA9Gl/NkKZJO6CRDaFXn6vQAZPDLAKZ1vHIP73tsziTh0ub4FKrPnbaq6yUql2GYmf7oUg== 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=SOIUhkSLQH77HWNFhnco6adMstZN13+BxxIriuwmBiA=; b=ZylrfH1N7HJaQbmBDB84rJJ/ZD4XFIezXid9E9XntDiyfJAea8Hffro0LB3gksl3qBks7DIPoxn+RBoNFkP5CVI9vy0edyXP5x4DwTUaSAXKiewp53ekS3rkeBO4jVsBLDo7EChTyfzad6Hb7QLK+5zXUY5QmOMatJJ3VYXSJHE= Received: from AM0PR07MB5347.eurprd07.prod.outlook.com (2603:10a6:208:e7::31) by AM8PR07MB7457.eurprd07.prod.outlook.com (2603:10a6:20b:249::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4352.11; Mon, 26 Jul 2021 21:00:29 +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.4373.017; Mon, 26 Jul 2021 21:00:29 +0000 From: =?iso-8859-1?Q?Bal=E1zs_Varga_A?= To: "pthubert@cisco.com" CC: "detnet@ietf.org" Thread-Topic: draft-varga-detnet-ip-preof Thread-Index: AdeCJhL5qclO3ipmQnOhnkjJnCiKCAAE+ubAAAYMvuAAA3HbcA== Date: Mon, 26 Jul 2021 21:00:29 +0000 Message-ID: References: In-Reply-To: Accept-Language: hu-HU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b17f03af-f590-4539-12bb-08d950786643 x-ms-traffictypediagnostic: AM8PR07MB7457: x-microsoft-antispam-prvs: 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: dSddPx7CgoL85w9YL2DRy0GY1rvlUzomwmE7AF3MI1ZOQCHUubLGfLEBrrZi3rvyY4Sw3SIS12x7PgkLPvcnEv9D2qSHqnPXcY7sJRCyIVF/h4oP1zAdM4BCRbGO0uEpwm+DW59TKBEF6aZS8do81XssZ3m1cdFuNM6Z4ddqRzhtdAV2FgUR+ZL4ymoShJgAcF2/C5AmBAz/rqQPYq1p3U5eCv09vzvOxDtuUO4sL2kktDdwWOqapjsZFrVCYYpuJPZyo9WG9ZFZ31MkftA3ssrNF177u4ohbTC58rxjpKzOTNoiXX120mChu3ehIfJJDyVBkntYvgsb4l+U5DssauLxz9u5DZdFWsTByd4xg7f1p4LkaVaohQ+D/ZVjpvswi+V+kgc6SecAxW6d7zYAo9bqReT8lgM+K9e/v1m+tsbNqJAsr5ftZKV1sSvU9aG5ZXsAkwZ66hQQYNff78h0LyAZPOGrlxyHXU8NJz/ZahPJtWoaR/Rflq0n6GI3qfuWKAZRLVKqNlNlMrt5eiS2VOkAStMXI8vVU1q1lQV2qiF/YuST9KXBpZgnGnF/KS4wfLpGvTlt1ZE+pY6gatELjweKjLGrrsPH/SS9syvje+3N2abKjNEKcs2M0m/dV6tbKCTWElQr9ZOGUXYVau54HBPd7dxxYWHTJ7Va0xib7SNpsE0JBxDa3zQVGBBXCrqC71eZhbBGQHcksWUjR5l1J/VYJWs0ALzTGZVOR4OULjx3puNFfRdrYgbavNb+PfhCkMqTYPv5PKsbi9Jz8xlPQA== 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)(366004)(66476007)(8676002)(166002)(8936002)(86362001)(71200400001)(4326008)(26005)(38100700002)(64756008)(66446008)(6916009)(76116006)(9326002)(55016002)(83380400001)(508600001)(186003)(66946007)(966005)(53546011)(9686003)(122000001)(66556008)(5660300002)(52536014)(7696005)(6506007)(316002)(2906002)(66574015)(33656002)(38070700004); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?k7Ne+rUEqpL6iehXfwIbDms3ccN1RJ7eYOn2NdD+6a8idTOQx4hxCGYyH3?= =?iso-8859-1?Q?nMUX8/vHS+ljbdK2py/aamhmMHRepOhgFcyTXL/HX9pPe/AqtEWhL4vUkG?= =?iso-8859-1?Q?DERPqb2BHqpBstgr5tuwGcp9T2PU6/ebKRQKnHXqHcLSP+M/nSQjwRU3yT?= =?iso-8859-1?Q?peVmeqfL+qxm0+jB+8fz12Z7UOVukO6w0ModF6zuhDPKBxuLtab/fAGWdl?= =?iso-8859-1?Q?trVuCp9WXPAprLoLbiC/Wc7t2uAM4Lxq46uZBX9ozTzVVJy1SlkI/Vro16?= =?iso-8859-1?Q?M9I8Hf7mo36cfRFDu84dZrzZrAsH8U2NHCGnRUALzxTgVX0Fruhntgytst?= =?iso-8859-1?Q?D0LNVh7L7SB/hUE17TPCHIdQumoUS0xOgfU+IjKlb6HC/V9f81F0bEkWix?= =?iso-8859-1?Q?R4c1/vYdZHLBg3sks0vBm6TWC2YkQYf8s4GX6AeuGk2bssTbTZFwdr+CIi?= =?iso-8859-1?Q?rSoH1L8+Y9KVjN6aiPmLzbvJkDPOBVrEQu1DfJjE9IgDssgE3A4AS3oJDp?= =?iso-8859-1?Q?9p5itshKNDPbXo96jd/npdor4YGKUhHDlugEUASjsOUmEAQMqoD14Uj8il?= =?iso-8859-1?Q?Nr+SC8LJxVHODv4W/qL1w4+QsCn6qa2nE0YkpjEyIEBcExpMVPUUNIc3AY?= =?iso-8859-1?Q?qetFpLw4Wr3zE8alvVifhxyopBE8alXH6w8voJH0p9ZzozO64T96jd542v?= =?iso-8859-1?Q?96GKGXCA9gYC0yG5CZOi0X1G0dlQb9Z9PrgVzDx3992H7RwXlnzoiavFNg?= =?iso-8859-1?Q?145q1UIONqidAj2mpN2eTKPed/QUtmlG2Pu/WjgN3oPutlvhQlhLJMWQ7p?= =?iso-8859-1?Q?Bc3rJKdvcQCemDJa7aUyCkNWURLl8Br0YibbKEUeDGc0UrALGnoXa1B8E3?= =?iso-8859-1?Q?TvP7mx/IP8yfDSesHYsAU728hl+wSJMPWqV2SkRG/nlGXSRmR8/DpVf6NS?= =?iso-8859-1?Q?F8843nTwJvA/I0jwUZkhpTkpz9j7MNLVOEU2AWUVsbdH8AZm1Rijq65s5H?= =?iso-8859-1?Q?NAPqbXkjUGq7lVhe/jRYF8k1u6oM+cl//ThBkPyLjIRVAfH27SLbQ2NzWd?= =?iso-8859-1?Q?gwziJa/ux9YTf6iP3oFAprAopL+9bcL+klotnq1xV1yI4Qbysz4x0Iq3WQ?= =?iso-8859-1?Q?dpbrWGAuSjEnV/GWhdIn/27kPd+o3q1bJ7wCIqQyYZ01FRntYNdplP6/TN?= =?iso-8859-1?Q?GT3BDvbKceBqGRls/mNm13oYAXJ8UpsPeI79fmFDUCom34UF4vbGyMqpbJ?= =?iso-8859-1?Q?cApY8yfdt/lO+S2qpbo2yV4KAYbC5y5Ogvt48SEEhMV6XdVRa+Vzre0T6r?= =?iso-8859-1?Q?YNzeAxWMNy5nYJpbCSKPD8maq5V671IFi+qyAnjBPd6SodWntyAsjeDPrk?= =?iso-8859-1?Q?yvtDuHdVNQ?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM0PR07MB53475FF5EC7C92D8285A27F0ACE89AM0PR07MB5347eurp_" 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: b17f03af-f590-4539-12bb-08d950786643 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jul 2021 21:00:29.0445 (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: J4BXIOp9ji6w/ZJ8yUlAlCKDVoyxdHRKlgUyDfnhPh4u8/LKzxcddCAIgfO9Dsigp9wpZV137LI2bd1YuJqlqPzH/c+KPs5l7vsEPiRYPZA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8PR07MB7457 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2021 21:00:39 -0000 --_000_AM0PR07MB53475FF5EC7C92D8285A27F0ACE89AM0PR07MB5347eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Pascal, Many thanks for the clarification questions. Please see my comments inline. Cheers Bala'zs -----Original Message----- From: Pascal Thubert (pthubert) > Sent: Monday, July 26, 2021 4:00 PM To: Janos Farkas >; Bal=E1zs Varga A >; agmalis@gmail.com Cc: detnet@ietf.org Subject: draft-varga-detnet-ip-preof Hello Bal=E1zs, J=E1nos, 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 though= t we should start here. - At first glance the draft seems to be placing the DetNet MPLS dataplane w= ithin UDP. If that is the intention, what are the benefits vs. using RFC 75= 10? 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 exi= sting ones. That's why it is informational. That is, this draft leverages RFC 9025, which leverages RFC 7510. It is app= licable 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 inform= ation deep inside the packet? No, the DetNet PW information is used only at relay nodes (as per rfc8= 655 those includes DetNet service sub-layer). Intermediate nodes (transit n= odes) do not need service sub-layer specific information, so they do not ne= ed 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? 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 pa= cket. From service sub-layer perspective it is the same concept used in rfc= 8964. - I'm concerned about the aggregation scenario. Contrary to MPLS, an IPv6 i= ntermediate 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? 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 own= ed by the PEs. A PE should be able to add / remove stuff that is relevant e= ither 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 stuf= f, it has to be thought in terms of matching encapsulation and decapsulatio= n. IPv6 has EHs that are designed to fit in such encapsulation, possibly to= gether, like an RH for replication and a HbH for path and redundancy inform= ation. What do you think? Again, the DetNet PW information is used only at relay nodes (doing se= rvice sub-layer). Intermediate nodes (transit nodes) do not need service su= b-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 --_000_AM0PR07MB53475FF5EC7C92D8285A27F0ACE89AM0PR07MB5347eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Pascal,

Many thanks for the clarification questions.=

Please see my comments inline.

Cheers

Bala'zs

 

 

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

 

Hello Bal=E1zs, J=E1nos, and Andy:

 

In prep for next Friday meeting I went through https://datatracker.i= etf.org/doc/html/draft-varga-detnet-ip-preof-00. I have a few qu= estions 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 t= he 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 t= he DetNet IP data plane in a simple way, with no new header or data plane d= efinition; but leveraging existing ones. That’s why it is information= al.

That is, this draft leverages RFC 9025, which = leverages RFC 7510. It is applicable both to IPv4 and IPv6.<= /p>

Key point in this draft is that DetNet PW (S-L= abel + d-CW) is placed in UDP. It is very important that there is *NO* labe= l 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 p= roblem to find that information deep inside the packet?

<BV> No, the DetNet PW information is us= ed only at relay nodes (as per rfc8655 those includes DetNet service sub-la= yer). Intermediate nodes (transit nodes) do not need service sub-layer spec= ific 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 forwa= rding node know what shape of stack to expect?

<BV> As the DetNet PW information is use= d 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. C= ontrary 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 re= lay node can perform aggregation as UDP tunnels are span between relay node= s.

 

Please consider the following picture from RFC 86= 55:

 

   DetNet     =             &nb= sp;            =             &nb= sp;          DetNet=

   End System    &n= bsp;            = ;            &n= bsp;            = ;       End System

      _   = ;            &n= bsp;            = ;            &n= bsp;            = ;        _

     / \   &nb= sp; +----DetNet-UNI (U)        &nbs= p;            &= nbsp;           &nbs= p; / \

    /App\    | = ;            &n= bsp;            = ;            &n= bsp;            = ; /App\

   /-----\   |  &nb= sp;            =             &nb= sp;            =            /-----\

   | NIC |   v  &nb= sp;      ________      &n= bsp;            = ;            &n= bsp;  | NIC |

   +--+--+   _____  = ;  /        \   &nbs= p;         DetNet-UNI (U) --+ = +--+--+

      |   = ;  /     \__/      &= nbsp;   \         &n= bsp;            = ;       |     |

      |   = ; / +----+    +----+    \_____  &nb= sp;            =         |     |=

      |   /&nb= sp; |    |    |    | &nbs= p;        \_______   &nbs= p;           |  = ;   |

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

        &= nbsp; |  |    |    |    |=     |         &= nbsp;    |     ___/ \   &= nbsp;    |

        &= nbsp; |  +--+-+    +----+    | &nbs= p;     +----+ |    /   &n= bsp;  \_      |

        &= nbsp; \     |       =          |    &= nbsp;  |    | |   /    &n= bsp;    \     |

        &= nbsp;  \    |   +----+    +--+= -+  +--+PE  |------       &nbs= p; U-----+

        &= nbsp;   \   |   |    | &n= bsp;  |    |  |  |    | | = ;  \_      _/

        &= nbsp;    \  +---+ P  +----+ P  +--+  +--= --+ |     \____/

        &= nbsp;     \___  |    |  &= nbsp; |    |        =    /

        &= nbsp;         \ +----+__  +---= -+     DetNet-1    DetNet-2

      |   = ;         \_____/  \__________= _/            &= nbsp;           &nbs= p;  |

      |   = ;            &n= bsp;            = ;            &n= bsp;            = ;        |

      |   = ;   |     End-to-End Service   = ;      |     |  &nbs= p;      |     |

      <--------------= ----------------------------------------------->

      |   = ;   |     DetNet Service   &nb= sp;         |   &nbs= p; |         |   &nb= sp; |

      |   = ;   <------------------------------------------------> = ;    |

      |   = ;   |          =             &nb= sp;         |   &nbs= p; |         |   &nb= sp; |

 

        &= nbsp; (RFC 8655) Figure 5: DetNet Service Reference Model (Multidomain)

 

You'll note that the DetNet architecture allows f= or endpoints that are not service-aware, in which case the service layer in= formation is logically owned by the PEs. A PE should be able to add / remov= e stuff that is relevant either within its domain (e.g., PREOF using SRv6 with Xuesong's SPRING draft) and / or w= ithin the DetNet Service Domain (across domains 1 and 2 above), e.g., redun= dancy information, excluding the End Systems which may encrypt their payloa= d 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 m= eans encapsulation, and it makes sense to minimize the incremental size. UD= P in UDP seems a lot doesn't it? 

 

My bottom line is that if we want intermediate no= des to add and remove stuff, it has to be thought in terms of matching enca= psulation 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.<= o:p>

 

What do you think?

<BV> Again, the DetNet PW information is= used only at relay nodes (doing service sub-layer). Intermediate nodes (tr= ansit 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, whi= ch just (re)uses existing DetNet data plane.

 

Pascal

 

--_000_AM0PR07MB53475FF5EC7C92D8285A27F0ACE89AM0PR07MB5347eurp_--