[mpls] Re: Working Group Adoption Poll on draft-mb-mpls-ioam-dex
Fabian Ihle <fabian.ihle@uni-tuebingen.de> Mon, 28 October 2024 15:10 UTC
Return-Path: <fabian.ihle@uni-tuebingen.de>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44707C14F6B0 for <mpls@ietfa.amsl.com>; Mon, 28 Oct 2024 08:10:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 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, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=uni-tuebingen.de
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SmZcYj9WDLlJ for <mpls@ietfa.amsl.com>; Mon, 28 Oct 2024 08:10:23 -0700 (PDT)
Received: from mx03.uni-tuebingen.de (mx03.uni-tuebingen.de [134.2.5.213]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68EB0C14CEFC for <mpls@ietf.org>; Mon, 28 Oct 2024 08:10:22 -0700 (PDT)
Received: from [134.2.10.219] (kalliope.cs.uni-tuebingen.de [134.2.10.219]) by mx03.uni-tuebingen.de (Postfix) with ESMTPSA id 6FB4F20C6A49; Mon, 28 Oct 2024 16:10:21 +0100 (CET)
DKIM-Filter: OpenDKIM Filter v2.11.0 mx03.uni-tuebingen.de 6FB4F20C6A49
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uni-tuebingen.de; s=20211202prod; t=1730128221; bh=b5fO5PBLlDo/N6ZjhZfZvP2tfoKqZfeyPU+gNYklGZU=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=hdLq8Qp8SEMPkyQ3RU4/pJUsvBkMVFZy9rUej+9DF4KUeCEMryy0F/1XDmqhCURH+ EHcUQe0dhmz/amQtrCtNeVNqblH80Q/dC8hR+sESq9Q8OcQMaXzQrcD7NCO8N46kab wQiCH/m2ZrJCIiavf71ayRIcjs0UDLr5oFSK+LJpurhspRvhbvFNcEk2/+O5GJ84BH UR03CaEZQdpgIc5Nieqicot7Zd8Pscqn3EUYCPrsMn0gfXPuQ8W1mWt9YfcwdKYUP5 IzA+mbG+GNgjH+Ld+29XcKcI3r7arDXJozq4ePZQp5qFbIH0Cx7L15xT3FoWUBkVVq oeN87jaD+0m7g==
Message-ID: <79310c56-1d00-4315-b7a7-97bd9841fd5f@uni-tuebingen.de>
Date: Mon, 28 Oct 2024 16:10:20 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: Loa Andersson <loa@pi.nu>, Stewart Bryant <stewart.bryant@gmail.com>
References: <BEZP281MB2008D5D3609840A7A3C5E26E987D2@BEZP281MB2008.DEUP281.PROD.OUTLOOK.COM> <408a6ad5-2fe0-4a53-8764-87b3949302b0@uni-tuebingen.de> <EDA63038-9312-4634-BC70-F73C914C354B@gmail.com> <5d0e02de-cb9d-47d8-b088-af923650a584@pi.nu> <8c987261-81c1-4293-a6ea-67f8329f6083@uni-tuebingen.de> <640ac998-5ed9-4145-b008-a3f9ff1a00e3@pi.nu> <4075b0bc-c05d-49a5-ada0-3289efd78d03@uni-tuebingen.de> <d9de4311-920a-4d6d-84a8-d36d19b610c6@pi.nu>
Content-Language: en-US
From: Fabian Ihle <fabian.ihle@uni-tuebingen.de>
In-Reply-To: <d9de4311-920a-4d6d-84a8-d36d19b610c6@pi.nu>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-512"; boundary="------------ms030702070406030108020000"
Message-ID-Hash: 3XMBPEOJAXY7V2A6VV3566K27YZNN25F
X-Message-ID-Hash: 3XMBPEOJAXY7V2A6VV3566K27YZNN25F
X-MailFrom: fabian.ihle@uni-tuebingen.de
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-mpls.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: mpls <mpls@ietf.org>, Michael Menth <michael.menth@uni-tuebingen.de>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [mpls] Re: Working Group Adoption Poll on draft-mb-mpls-ioam-dex
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/wWPz6C3JMW68ArFlCFVSvOYtYYs>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Owner: <mailto:mpls-owner@ietf.org>
List-Post: <mailto:mpls@ietf.org>
List-Subscribe: <mailto:mpls-join@ietf.org>
List-Unsubscribe: <mailto:mpls-leave@ietf.org>
Hi Loa, inline below On 26.10.24 17:33, Loa Andersson wrote: > Fabian, > > Misunderstand me correctly :)! > > I understand what you are saying and see how you need to treat it. <FI> Thats good to hear :) > > What I thought you were saying is the the PSD need to be within the > RLD, but if you place 4 octets of AD in-stack or post-stack, does not > have a significant impact on whether it is within RLD or not, right? <FI> I'm not sure if I got your point right. In the thought experiment below it actually does have a significant impact. 4 octects in this example lead to an RLD of 8 LSEs for ISD and 17 LSEs for PSD. Best, Fabian > > /Loa > > Den 26/10/2024 kl. 14:42, skrev Fabian Ihle: >> Hi Loa, >> >> comments inline below tagged with *<FI>* >> >> Am 26.10.2024 um 13:09 schrieb Loa Andersson: >>> Fabian, >>> >>> We are very much on the same page. Though in addition to what you >>> say, compatibility with RFC 9326 is important for me. >>> >>> Inline please. >>> >>> Den 25/10/2024 kl. 15:50, skrev Fabian Ihle: >>>> Stewart and Loa, >>>> >>>> the "a bit trickier" part of PSD is: >>>> >>>> 1. The presence of PSD needs to be indicated efficiently. With a >>>> single >>>> bit for indication (the "P-bit" from the jags draft), we still >>>> need >>>> 8 bytes (Format A for in-stack NAS indication and Format B for a >>>> flag-based opcode with the P-bit set). If select-scoped PSD >>>> indication is to be a thing, even more overhead is added. >>>> 2. In P4, the MPLS stack and the PSD must be within RLD. We cannot >>>> skip >>>> parts of the MPLS stack that are not relevant to the current node >>>> but have to parse the entire stack. While these irrelevant LSEs do >>>> not need to be processed, we still have to allocate resources to >>>> parse them. However, with an RLD of 51 LSEs, this constraint is >>>> not >>>> a showstopper and PSD is definitely doable. But it does emphasize >>>> the importance of the first point. Other hardware may work >>>> differently and not have this limitation, or may be even more >>>> constrained. In the latter case, PSD might be difficult. >>> >>> Thought experiment: >>> >>> Assume we need to transport 4 octets or mutable or variable >>> ancillary data. >> >> *<FI> In this case, we're only speaking of the DEX option. There is >> not mutable or variable ancillary data in DEX. AD in DEX are only the >> 32-bit optional sequence number and flow ID which is pushed by the >> encapsulating node. I totally agree with you that if not using the >> DEX option, e.g., requiring mutable or variable data with tracing, >> PSD is much more efficient as more bits are available.* >> >> *However, lets assume mutable data in the thought experiment. >> * >> >>> >>> For ISD you would need >>> >>> - the MNA label >>> - a format B LSE, for the OpCode to tell what NA the AD belongs too. >>> - a Format C LSE that can carry 7 bit mutable/varaiable AD >>> - three Format D LSEs to carry 25 bits (11+11+3 bits) mutable or >>> varaiable AD >>> >>> = 6 MNA LSEs. >>> >>> For PSD you would need >>> >>> - the MNA label >>> - a format B LSE, for the -p-bit or an OpCode to tell what NA the AD >>> belongs to >>> >>> After the stack you would need >>> >>> - 1 LSE carrying the type >>> - 1 LSE carrying the OpCOde + 16 bit of AD >>> - 1 LSE carrying 16 bits of data >>> >>> = 5 MNA LSEs >>> >>> It seems that RLD-wise in this case PSD will be more efficient. >>> >> *<FI> The problem here is that (at least in our case) we cannot only >> look at the number of LSEs for the NAS/PSD, but must look at the >> entire MPLS stack. We have to parse the full MPLS stack to be able to >> parse the PSD. Lets assume we have two forwarding labels at the top, >> followed by a HBH NAS with the IOAM data, followed by 10 arbitrary >> LSEs until BoS. In the ISD case for your example this means:* >> >> *| MPLS forwarding label A | >> | MPLS forwarding label B | >> | MNA bSPL label | >> | Format B LSE (e.g. HBH scope) |* >> *| Format C LSE with 7 bit mutable data |* >> *| 3 Format D LSEs to carry 25 bits (11+11+3 bits) mutable AD | --> >> we can stop parsing the MPLS stack here. Assuming we have two >> forwarding labels at the top until we find our NAS we require an RLD >> of 8 LSEs in this example. >> | Rest of the MPLS stack, lets say 10 LSEs until BoS | --> ignored* >> >> *Same example for PSD:* >> >> *| MPLS forwarding label A | >> | MPLS forwarding label B | >> | MNA bSPL label | >> | Format B LSE (the PSD indicator) | >> | Rest of the MPLS stack, lets say 10 LSEs until BoS | --> we MUST >> parse the remaining MPLS stack to be able to parse the post-stack. >> Those labels are not processed in the pipeline, but we have to >> allocate resources to parse them. >> --- BoS, PSD begins now ---* >> *| 1 LSE carrying the type | >> **| 1 LSE carrying the OpCode + 16 bit of AD |* >> *| 1 LSE carrying 16 bits of data| --> Total RLD of 4 LSE >> (top-of-stack + in-stack NAS) + 10 LSE (rest of the MPLS stack) + 3 >> LSE (PSD) = 17 LSE* >> >> *Other hardware may not be forced to parse the remaining MPLS stack >> and does not have to allocate resources for them. If that is the >> case, i.e., if there is an efficient way to go directly from the PSD >> indicator LSE to the actual PSD, for example by skipping over with >> the BoS bit without actually parsing those entries, the PSD case >> would be more efficient.* >> >> *With that in mind, a PSD solution is compatible with RFC 9326 but >> has some more hardware requirements (either large RLD, or efficient >> way to parse PSD without parsing the entire stack). In contrast, the >> ISD solution does not have those requirements (probably better for >> legacy hardware), but has two bits less for flow ID / sequence >> numbers in DEX.* >> >> *Best,* >> >> *Fabian >> * >> >> >>> >>> /Loa >>> >>>> >>>> Our intention with a P4 implementation is not to deploy commercial >>>> MNA solutions but rather to show that a protocol extension such as >>>> the MNA framework can be implemented on constrained hardware. If it >>>> works on constrained P4 hardware, hardware engineers will most >>>> likely also be able to implement it. However, the reverse >>>> assumption, i.e., "if it does not work on P4 hardware, it will also >>>> not work on other hardware" does not apply. >>>> >>>> We have mainly focused on an ISD implementation for now, the next >>>> step will be an extensive evaluation of the PSD version. >>>> >>>> Best, >>>> >>>> Fabian >>>> >>>> >>>> On 25.10.24 14:34, Loa Andersson wrote: >>>>> Stewart and Fabian, >>>>> >>>>> I think all implementation experiences are useful, also if the >>>>> they are done using the commercially non-deployed P4, you can >>>>> always draw some conclusions. >>>>> >>>>> What I would like is why PSD is trickier, and if "a bit trickier" >>>>> is significant enough to not go with PSD. Especially since we >>>>> agree that draft-mb-mpls-ioam-dex is not compliant with RFC 9326. >>>>> >>>>> Is "a bit trickier" the prize we pay for compliance with RFC 9326? >>>>> >>>>> /Loa >>>>> >>>>> Den 25/10/2024 kl. 13:13, skrev Stewart Bryant: >>>>>> >>>>>> >>>>>>> On 14 Oct 2024, at 10:34, Fabian Ihle <fabian.ihle@uni- >>>>>>> tuebingen.de> wrote: >>>>>>> >>>>>>> I think that ISD is the way to go for the DEX option as an PSD >>>>>>> implementation has proven to be a bit trickier in our P4 version. >>>>>> >>>>>> Is this an issue with the protocol or an indication of >>>>>> deficiencies in P4? >>>>>> >>>>>> Is P4 deployed or likely to be deployed in a production >>>>>> environment, i.e. is this a consideration for protocol >>>>>> standardisation? >>>>>> >>>>>> Best regards >>>>>> >>>>>> Stewart >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> mpls mailing list -- mpls@ietf.org >>>>>> To unsubscribe send an email to mpls-leave@ietf.org >>>>> >>>> -- >>>> Fabian Ihle >>>> Universität Tübingen >>>> Fachbereich Informatik Lehrstuhl Kommunikationsnetze >>>> Wilhelm-Schickard-Institut für Informatik >>>> Sand 13, 72076 Tübingen >>>> >>>> Raum: B303 >>>> Telefonnr.: +49 7071 29-70545 >>>> E-Mail:fabian.ihle@uni-tuebingen.de >>>> Internet: uni-tuebingen.de >>>> >>> >> -- >> Fabian Ihle >> Universität Tübingen >> Fachbereich Informatik Lehrstuhl Kommunikationsnetze >> Wilhelm-Schickard-Institut für Informatik >> Sand 13, 72076 Tübingen >> >> Raum: B303 >> Telefonnr.: +49 7071 29-70545 >> E-Mail:fabian.ihle@uni-tuebingen.de >> Internet: uni-tuebingen.de >> > -- Fabian Ihle Universität Tübingen Fachbereich Informatik Lehrstuhl Kommunikationsnetze Wilhelm-Schickard-Institut für Informatik Sand 13, 72076 Tübingen Raum: B303 Telefonnr.: +49 7071 29-70545 E-Mail: fabian.ihle@uni-tuebingen.de Internet: uni-tuebingen.de
- [mpls] Working Group Adoption Poll on draft-mb-mp… N.Leymann
- [mpls] Re: Working Group Adoption Poll on draft-m… Joel Halpern
- [mpls] Re: Working Group Adoption Poll on draft-m… Tony Li
- [mpls] Re: Working Group Adoption Poll on draft-m… Greg Mirsky
- [mpls] Re: Working Group Adoption Poll on draft-m… Haoyu Song
- [mpls] Re: Working Group Adoption Poll on draft-m… Tianran Zhou
- [mpls] Re: Working Group Adoption Poll on draft-m… mohamed.boucadair
- [mpls] Re: Working Group Adoption Poll on draft-m… Fabian Ihle
- [mpls] Re: Working Group Adoption Poll on draft-m… Stewart Bryant
- [mpls] Re: Working Group Adoption Poll on draft-m… Gyan Mishra
- [mpls] Re: Working Group Adoption Poll on draft-m… Loa Andersson
- [mpls] Re: Working Group Adoption Poll on draft-m… Fabian Ihle
- [mpls] Re: Working Group Adoption Poll on draft-m… Greg Mirsky
- [mpls] Re: Working Group Adoption Poll on draft-m… Haoyu Song
- [mpls] Re: Working Group Adoption Poll on draft-m… Tony Li
- [mpls] Re: Working Group Adoption Poll on draft-m… Loa Andersson
- [mpls] Re: Working Group Adoption Poll on draft-m… Fabian Ihle
- [mpls] Re: Working Group Adoption Poll on draft-m… Loa Andersson
- [mpls] Re: Working Group Adoption Poll on draft-m… Loa Andersson
- [mpls] Re: Working Group Adoption Poll on draft-m… N.Leymann
- [mpls] Re: Working Group Adoption Poll on draft-m… Tony Li
- [mpls] Re: Working Group Adoption Poll on draft-m… Fabian Ihle
- [mpls] Re: Working Group Adoption Poll on draft-m… Greg Mirsky
- [mpls] Re: Working Group Adoption Poll on draft-m… N.Leymann