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

Balázs Varga A <balazs.a.varga@ericsson.com> Mon, 26 July 2021 21:00 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 A58B73A0FD8 for <detnet@ietfa.amsl.com>; 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 <detnet@ietfa.amsl.com>; 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 <detnet@ietf.org>; 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?= <balazs.a.varga@ericsson.com>
To: "pthubert@cisco.com" <pthubert@cisco.com>
CC: "detnet@ietf.org" <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: <AM0PR07MB53475FF5EC7C92D8285A27F0ACE89@AM0PR07MB5347.eurprd07.prod.outlook.com>
References: <CO1PR11MB4881E860FF54BFB6CF04BF39D8E89@CO1PR11MB4881.namprd11.prod.outlook.com> <AM0PR07MB534784B537193F4F88241045ACE89@AM0PR07MB5347.eurprd07.prod.outlook.com> <AS8PR07MB8298836F25EE12742C278B44F2E89@AS8PR07MB8298.eurprd07.prod.outlook.com>
In-Reply-To: <AS8PR07MB8298836F25EE12742C278B44F2E89@AS8PR07MB8298.eurprd07.prod.outlook.com>
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: <AM8PR07MB745712FAAB613D7495BAE3F4ACE89@AM8PR07MB7457.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: 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: <https://mailarchive.ietf.org/arch/msg/detnet/Q9BKPLceFoJZlGqkUUfXLjafGcA>
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: Mon, 26 Jul 2021 21:00:39 -0000

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