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 2F7BEC1519A7 for ; Thu, 27 Jun 2024 12:42:32 -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 38wKCUDJV_89 for ; Thu, 27 Jun 2024 12:42:28 -0700 (PDT) Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com [IPv6:2607:f8b0:4864:20::529]) (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 68419C1519A2 for ; Thu, 27 Jun 2024 12:42:28 -0700 (PDT) Received: by mail-pg1-x529.google.com with SMTP id 41be03b00d2f7-656d8b346d2so5901300a12.2 for ; Thu, 27 Jun 2024 12:42:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719517348; x=1720122148; 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=pLSEcLPMTUxVh18Z37yoQfEDkjo5vrOeDZbbuJ2I1sc=; b=NPOC2TaEGfBv8O6vUYRbakyyGkJONSfAif5UPWxyVKYPt4AsB7xicoSa/OVCh2rpKB LKW65xmy3ryZxIoVy0UO30O8I1uiNNFceEWaIVj8eUIPCFapLA+gCX9wKEhb2F/tCzve pJkzEXtoRJkB4KvP0B4ywyObr91DBbOMPBfBk5TdY9+BKdX2qszgQaHm1Kel4dlZgRUg 0Rn/sH1xw17PXAzUcPFUe89Y3NZeFyK0XGK7rKJqbTpftaDkhz9Y7xuzB3oOLfBZzDXK sDcYgGzK8CVQe52A4prvJyW+8IA7TFMPjNqOiSq1oyGMeQ+sC0KP5FDyU4MKYg4zhVQh BCsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719517348; x=1720122148; 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=pLSEcLPMTUxVh18Z37yoQfEDkjo5vrOeDZbbuJ2I1sc=; b=CX9buPAX8mWcIMJNSZMscH4+hqosdX87JwRImk+KbwkmJLxMfZIMZ4jxIwBFyqfXdk PSqG+Wj7CHMsyMkBvYdHmwEHch2Az7xJvpay+5QzoetPGSIVfyInYLx38Acf8ExY5OI/ +0ArA/WJnX+0eY5uLgwHDu0GwZt1VLJi4Iq9c6pNjs19dllaBFb5RMRTtwVg+v87fpFv D0ltQKElRCn6cbARW9AYJoLbderrmr8uqDYaWinJprWYDOyFODFSM6KsQ67ooWF3nL3D qfXiMKzPv9TeUyv8eSKZOcwOUNi5JyBRcDZ1xJ/HA4O4jGxcYRT1gB3KttFMaJ4mYJrG +UNw== X-Gm-Message-State: AOJu0Yw/X8iskI+57tDfiw6d8VZXvTtkAbzSlXujs/0+VZmwdOJzwYMl OnWJTN7GUdRMaE9N8wwx4AuNtjohT7EjbCF4oDQuY7nnx+IBmNn4 X-Google-Smtp-Source: AGHT+IERdZZ1jZjyCzrOh2aQmmmVKmohuyjS6k8RwNEVf7oJ7a/ZkLfaNJa2s8CIoUp7oZJSXLQPXg== X-Received: by 2002:a05:6a20:a924:b0:1bd:2a28:cad2 with SMTP id adf61e73a8af0-1bd2a28cb51mr6063989637.62.1719517347375; Thu, 27 Jun 2024 12:42:27 -0700 (PDT) Received: from smtpclient.apple (c-73-93-167-4.hsd1.ca.comcast.net. [73.93.167.4]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-70801f57d2dsm99087b3a.31.2024.06.27.12.42.26 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Jun 2024 12:42:27 -0700 (PDT) Sender: Tony Li From: Tony Li Message-Id: <01795184-C956-4765-86A6-4A1A3C01C86D@tony.li> Content-Type: multipart/alternative; boundary="Apple-Mail=_7737C639-E375-4503-8599-718433C68B3B" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\)) Date: Thu, 27 Jun 2024 12:42:16 -0700 In-Reply-To: To: Rakesh Gandhi References: <554BBF53-649A-4DB3-876A-8BC772813646@tony.li> X-Mailer: Apple Mail (2.3774.600.62) Message-ID-Hash: 4LXOROJVXABZCYG6SG3UC3NLBDBQJTUA X-Message-ID-Hash: 4LXOROJVXABZCYG6SG3UC3NLBDBQJTUA 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 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: --Apple-Mail=_7737C639-E375-4503-8599-718433C68B3B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 [WG chair hat: off] Hi Rakesh, Haoyu, Please allow me to be very direct for a second: what you are proposing = is 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 do you know that it=E2=80=99s IOAM? You haven=E2=80= =99t parsed PSD yet. You 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 you would make incorrect = forwarding decisions. Thus, you cannot choose to just skip IOAM because it=E2=80=99s not in = RLD. 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: >=20 > Hi Tony, > =20 > 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 = case and forward the packet downstream. > =20 > Thanks, > Rakesh >=20 >=20 > On Thu, Jun 27, 2024 at 1:36=E2=80=AFPM Tony Li > wrote: >>=20 >> [WG chair hat: off] >>=20 >> Hi Rakesh, >>=20 >> 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 packet 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. =20 >>=20 >> 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 = have the problem (just make the IOAM request larger). And there are = also cases where things will work just fine (just make RLD larger). >>=20 >> 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? >>=20 >> We can=E2=80=99t change the RLD 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. >>=20 >> Regards, >> Tony >>=20 >>=20 >>=20 >>> On Jun 27, 2024, at 9:16=E2=80=AFAM, Rakesh Gandhi = > wrote: >>>=20 >>> Hi Tony, >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> thanks, >>> Rakesh >>>=20 >>>=20 >>>=20 >>> On Thu, Jun 27, 2024 at 11:54=E2=80=AFAM Tony Li > wrote: >>>> [WG chair hat: off] >>>>=20 >>>> Hi Rakesh, >>>>=20 >>>> I=E2=80=99m missing some point that I think you=E2=80=99re trying = to make. >>>>=20 >>>> 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? >>>>=20 >>>> It seems to me that the further down we push data, the more likely = we are to run into issues. >>>>=20 >>>> T >>>>=20 >>>>=20 >>>>> On Jun 27, 2024, at 8:35=E2=80=AFAM, Rakesh Gandhi = > wrote: >>>>>=20 >>>>> Hi WG, >>>>> =20 >>>>> There were some comments regarding how MPLS Readable Label Depth = (RLD) can affect pre-allocated IOAM trace data carried in MNA PSD. >>>>> =20 >>>>> 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) >>>>> =20 >>>>> 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? >>>>> =20 >>>>> 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). >>>>> =20 >>>>> Are we missing anything? >>>>> =20 >>>>> Thanks, >>>>> Rakesh >>>>> =20 >>>>> P.S. >>>>> =20 >>>>> 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.html#name-= in-situ-oam >>>>> =20 >>>>> Following MNA draft defines a PSD solution for this use-case. >>>>> = https://datatracker.ietf.org/doc/html/draft-gandhi-mpls-mna-ioam-dex-01 >>>>> =20 >>>>> =20 >>>>> _______________________________________________ >>>>> mpls mailing list -- mpls@ietf.org >>>>> To unsubscribe send an email to mpls-leave@ietf.org = >>>>=20 >>=20 --Apple-Mail=_7737C639-E375-4503-8599-718433C68B3B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

[WG chair hat: = off]

Hi Rakesh, = Haoyu,

Please allow me to be very direct for a = second: what you are proposing is = 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 do you = know that it=E2=80=99s IOAM?  You haven=E2=80=99t parsed PSD yet. =  You 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 you would make incorrect forwarding = decisions.

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

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


<= blockquote type=3D"cite">
On Jun 27, 2024, at 12:25=E2=80=AFPM, = Rakesh Gandhi <rgandhi.ietf@gmail.com> 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 case and forward = the packet downstream.

 

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 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 = packet 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 have the = problem (just make the IOAM request larger).  And there 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 RLD 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, 2024, at 9:16=E2=80=AFAM, Rakesh = Gandhi <rgandhi.ietf@gmail.com> = 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
<= br>


On Thu, Jun 27, 2024 at 11:54=E2=80=AFAM = Tony Li <tony.li@tony.li> wrote:
[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).  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 <rgandhi.ietf@gmail.com> = 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.

 

Following MNA draft defines a PSD solution for this use-case.

 

 

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

=


= --Apple-Mail=_7737C639-E375-4503-8599-718433C68B3B--