[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