Return-Path: 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 5D69AC14F60A for ; Sun, 27 Oct 2024 12:04:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.753 X-Spam-Level: X-Spam-Status: No, score=-1.753 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=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_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 letcDwzRf9FW for ; Sun, 27 Oct 2024 12:04:39 -0700 (PDT) Received: from mail-pj1-x1034.google.com (mail-pj1-x1034.google.com [IPv6:2607:f8b0:4864:20::1034]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F875C14F605 for ; Sun, 27 Oct 2024 12:04:34 -0700 (PDT) Received: by mail-pj1-x1034.google.com with SMTP id 98e67ed59e1d1-2e5a0177531so2694990a91.2 for ; Sun, 27 Oct 2024 12:04:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1730055873; x=1730660673; darn=ietf.org; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:sender:from:to:cc:subject:date:message-id:reply-to; bh=O8jbrEYzjxGZZsZaAc8S4Ae5GclVahX/O9nhnQ9/z/w=; b=lksNXHSsLMqfc1BXph5qlNVXxySSVOW8Ig9Hv+vHDSpyEW4o5HKjpKW68A3M5+nOu2 Lgu9Q6bo16Iz7xJfIdqFAL4poxUaxYdczUSbdX4k+27BDTq9/vuDiU06W0d6ToQfaH97 NO0k+1TV92u988iZ1NEq7KZqcnC6Mdhyco3AMtuWAhuhe1/eNt+Ch3U1+MIxbLIHNaw7 KMj25qRxMJe4wkx/3T8WsiXdUV89wBZY9xCm/LWGyTSWPgDYyC4YlddiU9+Z+UhhorD6 nngWtUc3sGhiKZK/3aWMh9Kd8fxZiNW1p5NyXwxnTY9OGPD1ryVuKwQvkFDTMEpB/dpu 0ZXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1730055873; x=1730660673; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=O8jbrEYzjxGZZsZaAc8S4Ae5GclVahX/O9nhnQ9/z/w=; b=LiPHivNMfFAiraZsNE7HYQgubcJUiDm4FQLvWePIQXqA+j/8fPdky6m5qrEDN8d9Dv HhWT2N7ZZApcAqwa8cTHbwhvaLHxzXpBsb5V11zWyY+zxkvh0dyZlYIWxloqnrIPMTCi 1AeTEPW/d4OeK1erOwZCxon1XFXq3jQUuZZkFdrSWgvMEwSvYJDwldIi8+5DN53zGjwb rMmz8gbJL/8fIpwivQDbr79o2DKFw34o8ft3jwFv0K+CW7TtBEZ9Q+zve624DIASWy4c f5RcfxiDka1pu09tuei0k5IZsOaaItbvKbQhJZO7uAmPCpFX8DYM2qPQumR4gME5gd1a DPbA== X-Forwarded-Encrypted: i=1; AJvYcCURS3slPjPYiJ5VB4KYQ2gCgdWvWx7uLjXJE8Wp4VqsjFYqi7JFCHKUIXQaFvJQVQwW7thV@ietf.org X-Gm-Message-State: AOJu0YxgMeQiVyetXm0lMGw5JAQmosciQa25CTZxL7wd6LQvH2KrmDQ4 b1vYeN5Dzx1XdS+HWWUJ4VFIEvhmbwnMl4npKZanatysf04kH2a4 X-Google-Smtp-Source: AGHT+IH9TWarBDIeCyUPyvcuLccEm+jqIiPaVvsRRrxwjruqTstct3jTfSAQdNAhj7EsP0Xp8bS1YA== X-Received: by 2002:a17:90b:1497:b0:2e2:eba1:a1a1 with SMTP id 98e67ed59e1d1-2e8f11de2ddmr7742207a91.36.1730055873154; Sun, 27 Oct 2024 12:04:33 -0700 (PDT) Received: from smtpclient.apple (192-184-144-109.fiber.dynamic.sonic.net. [192.184.144.109]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-210bc02ecc8sm38223475ad.222.2024.10.27.12.04.31 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 27 Oct 2024 12:04:32 -0700 (PDT) Sender: Tony Li From: Tony Li Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_E23AA4BD-7310-47BC-9041-177C35F2B56E" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3818.100.11.1.3\)) Date: Sun, 27 Oct 2024 12:04:21 -0700 In-Reply-To: <2B0855FA-3266-4660-9AAB-FC85FFAAC0CB@gmail.com> To: Loa Andersson References: <2B0855FA-3266-4660-9AAB-FC85FFAAC0CB@gmail.com> X-Mailer: Apple Mail (2.3818.100.11.1.3) Message-ID-Hash: 7FTJMVKMJNSF54BE6BUNE2JOK3GDNEXN X-Message-ID-Hash: 7FTJMVKMJNSF54BE6BUNE2JOK3GDNEXN X-MailFrom: tony1athome@gmail.com 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 , Michael Menth X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5Bmpls=5D_Re=3A_Working_Group_Adoption_Poll_on_draft-mb-mpls-ioam?= =?utf-8?q?-dex?= List-Id: Multi-Protocol Label Switching WG Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --Apple-Mail=_E23AA4BD-7310-47BC-9041-177C35F2B56E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 [WG chair hat: off] Hi Loa, The point is that 4 additional octets in PSD may be much farther down in = the packet than it would be with ISD and thus may be outside of RLD. Tony > On Oct 27, 2024, at 6:36=E2=80=AFAM, Loa Andersson - loa.pi.nu at = gmail.com wrote: >=20 > Greg,=20 >=20 > I=E2=80=99m just saying that adding e.g 4 octets of ancillary data to = a MPLS packet, will impact the RLD the same regardless if you do it as = ISD or PSD.=20 >=20 > /Loa >=20 > Sent from my iPhone >=20 >> On 26 Oct 2024, at 18:13, Greg Mirsky wrote: >>=20 >> =EF=BB=BF >> Hi Loa, >> it seems that you misinterpreted RLD for LSE overhead introduced by = ISD or PSD. I think that in regard to RLD, PSD will always demonstrate = worse than ISD for HbH and Select modes because there highly likely be a = number of LSEs and probably other Post-stack headers between NAS and PSD = block. >>=20 >> Regards, >> Greg >>=20 >> On Sat, Oct 26, 2024 at 4:09=E2=80=AFAM Loa Andersson > wrote: >>> Fabian, >>>=20 >>> We are very much on the same page. Though in addition to what you = say,=20 >>> compatibility with RFC 9326 is important for me. >>>=20 >>> Inline please. >>>=20 >>> Den 25/10/2024 kl. 15:50, skrev Fabian Ihle: >>> > Stewart and Loa, >>> >=20 >>> > the "a bit trickier" part of PSD is: >>> >=20 >>> > 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. >>>=20 >>> Thought experiment: >>>=20 >>> Assume we need to transport 4 octets or mutable or variable = ancillary data. >>>=20 >>> For ISD you would need >>>=20 >>> - 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 >>>=20 >>> =3D 6 MNA LSEs. >>>=20 >>> For PSD you would need >>>=20 >>> - the MNA label >>> - a format B LSE, for the -p-bit or an OpCode to tell what NA the AD >>> belongs to >>>=20 >>> After the stack you would need >>>=20 >>> - 1 LSE carrying the type >>> - 1 LSE carrying the OpCOde + 16 bit of AD >>> - 1 LSE carrying 16 bits of data >>>=20 >>> =3D 5 MNA LSEs >>>=20 >>> It seems that RLD-wise in this case PSD will be more efficient. >>>=20 >>>=20 >>> /Loa >>>=20 >>> >=20 >>> > Our intention with a P4 implementation is not to deploy commercial = MNA=20 >>> > solutions but rather to show that a protocol extension such as the = MNA=20 >>> > framework can be implemented on constrained hardware. If it works = on=20 >>> > constrained P4 hardware, hardware engineers will most likely also = be=20 >>> > able to implement it. However, the reverse assumption, i.e., "if = it does=20 >>> > not work on P4 hardware, it will also not work on other hardware" = does=20 >>> > not apply. >>> >=20 >>> > We have mainly focused on an ISD implementation for now, the next = step=20 >>> > will be an extensive evaluation of the PSD version. >>> >=20 >>> > Best, >>> >=20 >>> > Fabian >>> >=20 >>> >=20 >>> > On 25.10.24 14:34, Loa Andersson wrote: >>> >> Stewart and Fabian, >>> >> >>> >> I think all implementation experiences are useful, also if the = they=20 >>> >> are done using the commercially non-deployed P4, you can always = draw=20 >>> >> some conclusions. >>> >> >>> >> What I would like is why PSD is trickier, and if "a bit trickier" = is=20 >>> >> significant enough to not go with PSD. Especially since we agree = that=20 >>> >> 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 = >=20 >>> >>>> wrote: >>> >>>> >>> >>>> I think that ISD is the way to go for the DEX option as an PSD=20= >>> >>>> implementation has proven to be a bit trickier in our P4 = version. >>> >>> >>> >>> Is this an issue with the protocol or an indication of = deficiencies=20 >>> >>> in P4? >>> >>> >>> >>> Is P4 deployed or likely to be deployed in a production = environment,=20 >>> >>> 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 = >>> >> >>> > --=20 >>> > Fabian Ihle >>> > Universit=C3=A4t T=C3=BCbingen >>> > Fachbereich Informatik Lehrstuhl Kommunikationsnetze >>> > Wilhelm-Schickard-Institut f=C3=BCr Informatik >>> > Sand 13, 72076 T=C3=BCbingen >>> >=20 >>> > Raum: B303 >>> > Telefonnr.: +49 7071 29-70545 >>> > E-Mail:fabian.ihle@uni-tuebingen.de = >>> > Internet: uni-tuebingen.de >>> >=20 >>>=20 >>> --=20 >>> Loa Andersson >>> Senior MPLS Expert >>> Bronze Dragon Consulting >>> loa@pi.nu >>> loa.pi.nu.@gmail.com >>>=20 >>> _______________________________________________ >>> mpls mailing list -- mpls@ietf.org >>> To unsubscribe send an email to mpls-leave@ietf.org = >> _______________________________________________ >> mpls mailing list -- mpls@ietf.org >> To unsubscribe send an email to mpls-leave@ietf.org > _______________________________________________ > mpls mailing list -- mpls@ietf.org > To unsubscribe send an email to mpls-leave@ietf.org --Apple-Mail=_E23AA4BD-7310-47BC-9041-177C35F2B56E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
[WG chair = hat: off]

Hi Loa,

The point is = that 4 additional octets in PSD may be much farther down in the packet = than it would be with ISD and thus may be outside of = RLD.

Tony


On Oct 27, 2024, at 6:36=E2=80=AFAM, Loa Andersson - = loa.pi.nu at gmail.com <mailforwards@cloudmails.net> = wrote:

Greg, 

I=E2=80=99m just saying that = adding e.g 4 octets of ancillary data to a MPLS packet, will impact the = RLD the same regardless if you do it as ISD or = PSD. 

/Loa

Sent from my = iPhone

On 26 Oct = 2024, at 18:13, Greg Mirsky <gregimirsky@gmail.com> = wrote:

=EF=BB=BF
Hi Loa,
it seems that you = misinterpreted RLD for LSE overhead introduced by ISD or PSD. I think = that in regard to RLD, PSD will always demonstrate worse than ISD for = HbH and Select modes because there highly likely be a number of = LSEs and probably other Post-stack headers between NAS and PSD = block.

Regards,
Greg

On Sat, = Oct 26, 2024 at 4:09=E2=80=AFAM Loa Andersson <loa@pi.nu> wrote:
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.

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

=3D 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

=3D 5 MNA LSEs

It seems that RLD-wise in this case PSD will be more efficient.


/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=C3=A4t T=C3=BCbingen
> Fachbereich Informatik Lehrstuhl Kommunikationsnetze
> Wilhelm-Schickard-Institut f=C3=BCr Informatik
> Sand 13, 72076 T=C3=BCbingen
>
> Raum: B303
> Telefonnr.: +49 7071 29-70545
> E-Mail:fabian.ihle@uni-tuebingen.de
> Internet: uni-tuebingen.de
>

--
Loa Andersson
Senior MPLS Expert
Bronze Dragon Consulting
loa@pi.nu
loa.pi.nu.@gmail.com

_______________________________________________
mpls mailing list -- mpls@ietf.org
To unsubscribe send an email to mpls-leave@ietf.org
= _______________________________________________
mpls= mailing list -- mpls@ietf.org
To unsubscribe send an = email to = mpls-leave@ietf.org
_____________= __________________________________
mpls mailing list -- = mpls@ietf.org
To unsubscribe send an email to = mpls-leave@ietf.org

= --Apple-Mail=_E23AA4BD-7310-47BC-9041-177C35F2B56E--