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 C50F5C1519A8 for ; Mon, 1 Jul 2024 12:46:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.104 X-Spam-Level: X-Spam-Status: No, score=-7.104 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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=ham 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 vLvU1Vo79PCN for ; Mon, 1 Jul 2024 12:46:44 -0700 (PDT) Received: from mail-yw1-x1131.google.com (mail-yw1-x1131.google.com [IPv6:2607:f8b0:4864:20::1131]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B74EEC14F704 for ; Mon, 1 Jul 2024 12:46:44 -0700 (PDT) Received: by mail-yw1-x1131.google.com with SMTP id 00721157ae682-642035f8c4eso34335257b3.0 for ; Mon, 01 Jul 2024 12:46:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719863203; x=1720468003; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=1CEILF6Pz9c0k+mDDXRIXd962gpR8uCVRSEXjnb+ySs=; b=mT+/4CbyHGwTwO6zpfHqOdXH1olKDNDhM0NvdJh6rcySqzX2yks+RDtCnbbfRt6qM+ jK1QP42xi73RYPrXobh42LCqgBJ7x64qfmiauhYeOnu5WTPmPmMADnxPDO0RVItD2tkk SDSPKqZ1EL1P8BpWfIKLFnYm4JhYRAztKoftl1VCqEkF5r9KY+p7KmfnHs0y8teSPuiE FULFxVf/2pMXdf/cryl9mMYjeSqWk86uXOUvQl+8EXueg5mKDx47C8DbRkr/SlkHLT10 NXZOU+KNjJEtCuGxLTIby36TESqZ0Gd8ZGWnUXiYyeCJBdqToOQf5wHQn2REPfl1M6KN gBTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719863203; x=1720468003; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=1CEILF6Pz9c0k+mDDXRIXd962gpR8uCVRSEXjnb+ySs=; b=Z5kjXO0lU0JldLRr0dHgRmaR7HZBNH76jG/HnJUgZZYLUo2rC6rwoHJe8LZItfAAVR EPg/AhtqFj+ebJoTEr4q2wYvdPvxy6thkD6jnwdYVbpRnOJYJiwsajzU8TqaIpFUZRks nOW+LLaIDp+EikVW/jxRQnkPxXdvOMNZKLj7n38Em+LEBb3CUnGsVq0RLZfI1vrjrpmB U61d6X9JJmBdWUnyTlQdWenevtsHeIgU8Kty1Grdd2jKFpMPAxY3vWDLW5ls552J5OXi dvrxkKtAOoUzrT1H+GuZKxHNF8jP1kbcWQjpjIoPoh1VRzpSf0cbjDyS3fen1qO9GAmN 6Kww== X-Forwarded-Encrypted: i=1; AJvYcCUn6iTXnKTh+87yhNxYEUU00SkmIdOUb9FRYGVcr2Ng8zKBjVnbqtKmQDBepSOYrA7iqpdZEUk8hJVVLC8v X-Gm-Message-State: AOJu0YwkQTz+0EUot8n5OYiyH8NWo5VbicEwybda97JgjqEj0b8qdpeu CNYB5auRX0NeI6d+tvLB8WAdGOAwoXb5JPm2nCYHc7QSX+jMeArWwcOYqLhArf3zTIlW/ZE0GDi fbwTQ7Z93CzRFJ+n+A4nuAcw8JTs= X-Google-Smtp-Source: AGHT+IG+I+ff8jivCJjLoZvcc8e/QNwABx9qx0Gf7FcQyDtNT33xI2bspCBHTPRr19tspqfQkm/H/l+qR8wJYbZlIsM= X-Received: by 2002:a05:690c:710:b0:64b:8e82:1f9 with SMTP id 00721157ae682-64c7123bf4amr72867447b3.18.1719863203299; Mon, 01 Jul 2024 12:46:43 -0700 (PDT) MIME-Version: 1.0 References: <554BBF53-649A-4DB3-876A-8BC772813646@tony.li> <01795184-C956-4765-86A6-4A1A3C01C86D@tony.li> <2BFC1EAE-F3FF-4A58-8D2B-F06913E83D5D@tony.li> In-Reply-To: <2BFC1EAE-F3FF-4A58-8D2B-F06913E83D5D@tony.li> From: Greg Mirsky Date: Mon, 1 Jul 2024 12:46:32 -0700 Message-ID: To: Tony Li Content-Type: multipart/alternative; boundary="0000000000004b8e23061c34dba4" Message-ID-Hash: K2DYFWHPTM7BJONYC3A2BKALMEGVMCNP X-Message-ID-Hash: K2DYFWHPTM7BJONYC3A2BKALMEGVMCNP X-MailFrom: gregimirsky@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 X-Mailman-Version: 3.3.9rc4 Precedence: list Subject: =?utf-8?q?=5Bmpls=5D_Re=3A_Example_of_MPLS_RLD_with_IOAM_Trace_in_PSD?= List-Id: Multi-Protocol Label Switching WG Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --0000000000004b8e23061c34dba4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thinking about PSD and RLD some more. Do we expect that the indication of PSD presence in the packet conveys additional information that can be useful in avoiding punting the packet out of the fast-path processing? It seems to me that a mere indication that an HBH or Selectscope MNA use PSD that immediately follows the BoS LSE guarantees that that PSD can be inspected in the fast path, i.e., it is within RLD space. If we agree that processing PSD MUST NOT negatively affect forwarding performance and potentially cause out-of-order delivery, then what could be a sufficient set of indicators that must be conveyed in the ISD along with the corresponding Option? Regards, Greg On Mon, Jul 1, 2024 at 12:16=E2=80=AFPM Tony Li wrote: > > [WG chair hat: off] > > Hi Rakesh, > > So you=E2=80=99re proposing that for each and every PSD action, we also d= efine and > consume ISD space to indicate that the action is present in PSD? > > This seems somewhat inefficient. > > T > > > On Jun 27, 2024, at 12:59=E2=80=AFPM, Rakesh Gandhi > wrote: > > Hi Tony, > > Thanks for the discussions and comments. > > Node would know it's IOAM using the IOAM In-Stack Network action defined > with PSD offset in Data. PSD offset would help to know if IOAM start is > within RLD without parsing PSD. It can use this information to skip the > IOAM network action and forward the packet downstream if not within RLD. > > - > https://www.ietf.org/archive/id/draft-gandhi-mpls-mna-ioam-dex-01.html= #name-in-stack-network-actions > > > > > > Thanks, > Rakesh > > > > On Thu, Jun 27, 2024 at 3:42=E2=80=AFPM Tony Li wrote: > >> >> [WG chair hat: off] >> >> Hi Rakesh, Haoyu, >> >> Please allow me to be very direct for a second: what you are proposing i= s >> impossible. >> >> You cannot act on information that you do not have and we don=E2=80=99t = build >> routers with oracles in them. >> >> Let=E2=80=99s suppose that a router recieves a packet and parses down it= =E2=80=99s RLD. >> It finds an MNA indication, but PSD does not lie within that RLD. How d= o >> you know that it=E2=80=99s IOAM? You haven=E2=80=99t parsed PSD yet. Y= ou cannot. It is >> inaccessible on the fast path. Further, there may be MNA actions in PSD >> that affect forwarding. If you do not parse PSD to find that out, then y= ou >> would make incorrect forwarding decisions. >> >> Thus, you cannot choose to just skip IOAM because it=E2=80=99s not in RL= D. >> >> Haoyu is correct: we can use the control plane information to constrain >> the network to only the cases where IOAM and RLD are compatible. However= , >> the further we push actions down the packet, the more we will limit the >> cases that we can support. >> >> Tony >> >> >> On Jun 27, 2024, at 12:25=E2=80=AFPM, Rakesh Gandhi >> wrote: >> >> Hi Tony, >> >> >> We would not implement it to punt the packet (to slow-path) if node >> cannot perform MNA IOAM network action for any reason (including RLD >> limit). The node would simply skip the MNA IOAM network action in this c= ase >> and forward the packet downstream. >> >> >> Thanks, >> Rakesh >> >> >> On Thu, Jun 27, 2024 at 1:36=E2=80=AFPM Tony Li wrote: >> >>> >>> [WG chair hat: off] >>> >>> Hi Rakesh, >>> >>> We know that MNA can contain actions that affect the forwarding of the >>> packet. If a node finds a packet that has MNA actions (ISD or PSD) that= are >>> not wholly inside of RLD, then full forwarding information would not be >>> available to the fast path. I see no alternative but to punt the packe= t to >>> the slow path. This will result in a performance issue. As long as >>> the packet is on the slow path already, you might as well perform the >>> associated functions. Note that this is not IOAM specific. >>> >>> For a given IOAM request and a given set of RLDs on the path, things >>> will either have this performance issue or they will not. This seems >>> binary. And it seems like one can always construct examples that will h= ave >>> the problem (just make the IOAM request larger). And there are also ca= ses >>> where things will work just fine (just make RLD larger). >>> >>> So I=E2=80=99m still missing your point here. There are cases that work= , there >>> are cases that don=E2=80=99t. Are you trying to say something more? >>> >>> We can=E2=80=99t change the RLD in a brownfield network, so the best th= at we can >>> do in our designs is to try to ensure that MNA information fits within = the >>> existing RLDs. >>> >>> Regards, >>> Tony >>> >>> >>> >>> On Jun 27, 2024, at 9:16=E2=80=AFAM, Rakesh Gandhi >>> wrote: >>> >>> Hi Tony, >>> >>> In your example, that midpoint would not have updated the IOAM data >>> (timestamp in this case) due to the RLD reachability. This just means, = IOAM >>> data is missing from the node that it is not capable of. >>> >>> P.S. RLD would be much higher than 64-byte in reality, but ok for the >>> sake of discussion. >>> P.S. Nodes (or operators) enabling the IOAM encapsulation would have >>> some knowledge of RLDs and could enable IOAM accordingly. >>> >>> thanks, >>> Rakesh >>> >>> >>> >>> On Thu, Jun 27, 2024 at 11:54=E2=80=AFAM Tony Li wrot= e: >>> >>>> [WG chair hat: off] >>>> >>>> Hi Rakesh, >>>> >>>> I=E2=80=99m missing some point that I think you=E2=80=99re trying to m= ake. >>>> >>>> Suppose that a node in this network only has an RLD of 64 octets (i.e.= , >>>> 16 LSE equivalents). Won=E2=80=99t there be a perfomance issue? >>>> >>>> It seems to me that the further down we push data, the more likely we >>>> are to run into issues. >>>> >>>> T >>>> >>>> >>>> On Jun 27, 2024, at 8:35=E2=80=AFAM, Rakesh Gandhi >>>> wrote: >>>> >>>> Hi WG, >>>> >>>> >>>> There were some comments regarding how MPLS Readable Label Depth (RLD) >>>> can affect pre-allocated IOAM trace data carried in MNA PSD. >>>> >>>> >>>> Using an example: >>>> For 10 hops with 10 LSEs (sub-total 40 bytes) >>>> + 2 LSEs for MNA in MPLS header (sub-total 48 bytes) >>>> + 2 words for PSD Headers (sub-total 56 bytes) >>>> + 10 words of pre-allocated IOAM space for recording 4-byte timestamp >>>> fraction (sub-total 96 bytes) >>>> + adding 4-byte IOAM Namespace (sub-total 100 bytes or 25 words) >>>> >>>> >>>> This means the *first midpoint* will *need 100-byte (or 25-word) RLD* >>>> to record 32-bit timestamp fraction in MNA IOAM PSD for 10-hop SR path= , >>>> right? >>>> >>>> >>>> If a midpoint node supports *RLD of 128-byte*, MPLS can support >>>> per-hop delay measurement use-case for 10-hop SR-path using IOAM trace >>>> option (pre-allocated). >>>> >>>> >>>> Are we missing anything? >>>> >>>> >>>> Thanks, >>>> Rakesh >>>> >>>> >>>> P.S. >>>> >>>> >>>> Following MNA use-case draft lists IOAM Pre-allocated trace option >>>> use-case. >>>> >>>> - >>>> https://www.ietf.org/archive/id/draft-ietf-mpls-mna-usecases-10.htm= l#name-in-situ-oam >>>> >>>> >>>> Following MNA draft defines a PSD solution for this use-case. >>>> >>>> - >>>> https://datatracker.ietf.org/doc/html/draft-gandhi-mpls-mna-ioam-de= x-01 >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 > --0000000000004b8e23061c34dba4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thinking about PSD and RLD some more.
Do we expect tha= t the indication of PSD presence in the packet conveys additional informati= on that can be useful in avoiding punting the packet out of the fast-path p= rocessing? It seems to me that a mere indication that an HBH or Selectscope= =C2=A0MNA use PSD that immediately follows=C2=A0the BoS LSE guarantees that= that PSD can be inspected in the fast path, i.e., it is within=C2=A0RLD sp= ace. If we agree that processing PSD MUST NOT negatively affect forwarding = performance and potentially cause out-of-order delivery, then what could be= a sufficient set of indicators that must be conveyed in the ISD along with= the corresponding Option?

Regards,
Greg=

On Mon, Jul 1, 2024 at 12:16=E2=80=AFPM Tony Li <tony.li@tony.li> wrote:

[WG chair hat: off]
Hi Rakesh,

So you=E2=80=99re prop= osing that for each and every PSD action, we also define and consume ISD sp= ace to indicate that the action is present in PSD?

This seems somewhat inefficient.

T


On Jun 27, 2024, at 12:59=E2=80=AFPM, Rakesh Gandhi = <rgandhi.iet= f@gmail.com> wrote:

Hi Tony,

Thanks for the discussions and comments.

Node would know it's IOAM using th= e IOAM In-Stack Network action defined with PSD offset in Data. PSD offset = would help to know if IOAM start is within RLD without parsing PSD. It can = use this information to skip the IOAM network action and forward the packet= downstream if not within RLD.

On Thu, Jun 27, 2= 024 at 3:42=E2=80=AFPM Tony Li <tony.li@tony.li> wrote:

[WG chair hat: off]
Hi Rakesh, Haoyu,

Please allow me to b= e very direct for a second: what you are proposing is impossible.

You cannot act on information that you do not have and we d= on=E2=80=99t build routers with oracles in them.

L= et=E2=80=99s suppose that a router recieves a packet and parses down it=E2= =80=99s RLD.=C2=A0 It finds an MNA indication, but PSD does not lie within = that RLD.=C2=A0 How do you know that it=E2=80=99s IOAM?=C2=A0 You haven=E2= =80=99t parsed PSD yet.=C2=A0 You cannot. It is inaccessible on the fast pa= th. Further, there may be MNA actions in PSD that affect forwarding. If you= do not parse PSD to find that out, then you would make incorrect forwardin= g decisions.

Thus, you cannot choose to just skip = IOAM because it=E2=80=99s not in RLD.

Haoyu is cor= rect: we can use the control plane information to constrain the network to = only the cases where IOAM and RLD are compatible. However, the further we p= ush actions down the packet, the more we will limit the cases that we can s= upport.

Tony


On Jun 27, 2024, at 12:25=E2=80=AFPM, Rakesh Ga= ndhi <rgandh= i.ietf@gmail.com> wrote:

Hi Tony,

=C2=A0

We would not im= plement it to punt the packet (to slow-path) if node cannot perform MNA IOAM network action for any reason (including RLD limit). The n= ode would simply skip the MNA IOAM network action in this case and forward the = packet downstream.

=C2=A0

Thanks,
Rakesh


= On Thu, Jun 27, 2024 at 1:36=E2=80=AFPM Tony Li <tony.li@tony.li> wrote:

[WG chair = hat: off]

Hi Rakesh,

We know th= at MNA can contain actions that affect the forwarding of the packet. If a n= ode finds a packet that has MNA actions (ISD or PSD) that are not wholly in= side of RLD, then full forwarding information would not be available to the= fast path.=C2=A0 I see no alternative but to punt the packet to the slow p= ath. =C2=A0This will result in a performance issue. =C2=A0As l= ong as the packet is on the slow path already, you might as well perform th= e associated functions.=C2=A0 Note that this is not IOAM specific. =C2=A0

For a given IOAM request and a given set of RLDs on= the path, things will either have this performance issue or they will not.= This seems binary. And it seems like one can always construct examples tha= t will have the problem (just make the IOAM request larger).=C2=A0 And ther= e are also cases where things will work just fine (just make RLD larger).

So I=E2=80=99m still missing your point here. There= are cases that work, there are cases that don=E2=80=99t. Are you trying to= say something more?

We can=E2=80=99t change the R= LD in a brownfield network, so the best that we can do in our designs is to= try to ensure that MNA information fits within the existing RLDs.

Regards,
Tony



On Jun 27, 20= 24, at 9:16=E2=80=AFAM, Rakesh Gandhi <rgandhi.ietf@gmail.com> wrote:

<= div>
Hi Tony,

In your example, that midpoint would not have updated the IOAM data (time= stamp in this case) due to the RLD reachability. This just means, IOAM data= is missing from the node that it is not capable of.

P.S. RLD would be much higher than 64-byte in reality, but ok for th= e sake of discussion.
P.S. Nodes (or operators) enabling the IOAM= encapsulation would have some knowledge of RLDs and could enable IOAM acco= rdingly.

thanks,
Rakesh



On Thu, Jun 27, 2024 at 11:54=E2=80=AFAM Tony Li <tony.li@tony.li> w= rote:
= [WG chair hat: off]

Hi Rakesh,

I=E2= =80=99m missing some point that I think you=E2=80=99re trying to make.

Suppose that a node in this network only has an RLD of= 64 octets (i.e., 16 LSE equivalents).=C2=A0 Won=E2=80=99t there be a perfo= mance issue?

It seems to me that the further down = we push data, the more likely we are to run into issues.

T


On Jun 27, 2024, at 8:35=E2=80=AFAM, Ra= kesh Gandhi <rgandhi.ietf@gmail.com> wrote:

= Hi WG,

=C2=A0

There were some comments regarding how MPLS Readable Label Depth (RLD) can affect pre-allocated IOAM= trace data carried in MNA PSD.

=C2=A0

Usi= ng an example:
For 10 ho= ps with 10 LSEs (sub-total 40 bytes)
+ 2= LSEs for MNA in MPLS header (sub-total 48 bytes)
+ 2 words for PSD Headers (sub-total 56 bytes)
+ 1= 0 words of pre-allocated IOAM space for recording 4-byte timestamp fraction (sub-total 96 bytes)
+ adding 4-byte IOAM Namespace (sub-total 100 bytes or 25 words)

=C2=A0

This means the first midpoint will need 100-byte (or 25-word) RLD to record 32-bit timestamp fract= ion in MNA IOAM PSD for 10-hop SR path, right?

=C2=A0

If a midpoint node supports RLD of 128-byte, MPLS can support per-hop delay measurement use-case for 10= -hop SR-path using IOAM trace option (pre-allocated).
<= p class=3D"MsoNormal" style=3D"margin:0cm;font-size:11pt;font-family:Aptos,= sans-serif">=C2=A0

Are we missing anything?
<= p class=3D"MsoNormal" style=3D"margin:0cm;font-size:11pt;font-family:Aptos,= sans-serif">=C2=A0

Thanks,
Rakesh

=C2=A0

P.S.=

=C2= =A0

Following MNA use-case draft lists IOAM Pre-allocated trace option use-case.
_______________________________________________
mpls mailing list -- mpls@ietf.org
To uns= ubscribe send an email to mpls-leave@ietf.org




__________________________________= _____________
mpls mailing list -- mpl= s@ietf.org
To unsubscribe send an email to mpls-leave@ietf.org
--0000000000004b8e23061c34dba4--