[mpls] Re: Example of MPLS RLD with IOAM Trace in PSD

Tony Li <tony.li@tony.li> Mon, 01 July 2024 19:15 UTC

Return-Path: <tony1athome@gmail.com>
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 D4D60C1D4A92 for <mpls@ietfa.amsl.com>; Mon, 1 Jul 2024 12:15:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.754
X-Spam-Level:
X-Spam-Status: No, score=-6.754 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_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_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 5jld2ICGWJYh for <mpls@ietfa.amsl.com>; Mon, 1 Jul 2024 12:15:30 -0700 (PDT)
Received: from mail-pf1-x42a.google.com (mail-pf1-x42a.google.com [IPv6:2607:f8b0:4864:20::42a]) (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 08C8AC1D4A7F for <mpls@ietf.org>; Mon, 1 Jul 2024 12:15:30 -0700 (PDT)
Received: by mail-pf1-x42a.google.com with SMTP id d2e1a72fcca58-70679845d69so2112993b3a.1 for <mpls@ietf.org>; Mon, 01 Jul 2024 12:15:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719861329; x=1720466129; 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=M7OLWTI5UWFBHSkSmziHT9bk2Qm3//v0GRJVd+aiEw0=; b=cew5Q80Wq2u97kraD8kOcE0gGby4JEDKF692JONz4HYUuha8bEoYAbCdWTCRUMbhet bP/i7HkaeyX7dPKoeYYmeiR5w5o+erG1HNTDlBAK6k/U4S/bkL7HcDrHHajsp7USZHqp rjG7WhNvyS3AN7P1Uv+aP3NiIIdj5jhIdlfQ9NIO6hOt91C6o1bVx4UHgt6nnLgGXowo Zk5paDG4soCELfCbR1ptx9MhuKEWWgpJFwaY6vOPAmJNjPfvWekY0PSqLsiLtcAxH3x/ EGbo/qTMh/FTFROkUBpyVi6UUkpRmBhtaLTpVu9i8cfAKcflSkZHrq9xDweL4zVqQrm9 KWuw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719861329; x=1720466129; 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=M7OLWTI5UWFBHSkSmziHT9bk2Qm3//v0GRJVd+aiEw0=; b=cS40FRUQZJRXb2QbkjskKws4eL/hktsar3WMTmHJgSboVi7Tem/bxyLKdgnTqaDG3b waIwiS+OaJrT5JgkShML5RwK2lq40HbubJFrl/e/5ciGX0FOGyX8mpplvW3xuBfpmc25 PExRPmacLAoQM8Ht1FMN2ivoqod/HT9XbDbKNUQFD8j/fg6X3z/WbyShGWC26qNgCCZR 7EftpnRh6ZrOOAkgJxFLVz64blJ/yFY38yNQzM7MjlKKtFASPC7wimmyro0O7e+dqXi3 RSRCX9waOa1c3CmOZFY6mcoa+U4bsxSvWNcRZGA+JZcoXU1g6VQs1b/ohGutTnDFkqjf qD3Q==
X-Gm-Message-State: AOJu0Yyt3yiuCdmrwz6J3YJVzgpGhJHWRaxtyuj5dflIrrEoVIWP84I2 KSXPffGVuTxui5VaF0xs0kEbL6J7w/2PWlzt3HpTLP96D+0kzAOBfUtYWg==
X-Google-Smtp-Source: AGHT+IFi7W4uu5mFyHD3hlUrKeboBPNsbzKht5qh5nmZo3nJo+DV5SGTclSfTZ5mI5Fy3AeEm46EpA==
X-Received: by 2002:a05:6a20:a11f:b0:1be:c35e:d47b with SMTP id adf61e73a8af0-1bef619949emr6166360637.34.1719861328913; Mon, 01 Jul 2024 12:15:28 -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 d9443c01a7336-1faceb78c6csm60876925ad.271.2024.07.01.12.15.28 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 Jul 2024 12:15:28 -0700 (PDT)
Sender: Tony Li <tony1athome@gmail.com>
From: Tony Li <tony.li@tony.li>
Message-Id: <2BFC1EAE-F3FF-4A58-8D2B-F06913E83D5D@tony.li>
Content-Type: multipart/alternative; boundary="Apple-Mail=_BB3C13CA-3C8B-45E5-8C2A-205E76E9CC6E"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\))
Date: Mon, 01 Jul 2024 12:15:17 -0700
In-Reply-To: <CAMZsk6e9xchYAZo281+jAqbjNywwuXgaxHfJr1Ljdbn4tK_d2g@mail.gmail.com>
To: Rakesh Gandhi <rgandhi.ietf@gmail.com>
References: <CAMZsk6cT-AZ8Dswd37Owu+Bhte=jR-3BmaA6JA7ftQmLgUQ5RQ@mail.gmail.com> <554BBF53-649A-4DB3-876A-8BC772813646@tony.li> <CAMZsk6esOb38twqWNAtLhtOoRSufqadhiYtGBLUFPC-dd-zrvg@mail.gmail.com> <E80AE688-87C3-423F-97E0-0832EB96275F@tony.li> <CAMZsk6emH3u0xw8nDHxQbxKP1WRqb3gyQ7z0bjSFuCx839YE4w@mail.gmail.com> <01795184-C956-4765-86A6-4A1A3C01C86D@tony.li> <CAMZsk6e9xchYAZo281+jAqbjNywwuXgaxHfJr1Ljdbn4tK_d2g@mail.gmail.com>
X-Mailer: Apple Mail (2.3774.600.62)
Message-ID-Hash: 33DJMOTYRXU6HX2HCWQMHFWRRVUNBZDJ
X-Message-ID-Hash: 33DJMOTYRXU6HX2HCWQMHFWRRVUNBZDJ
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 <mpls@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [mpls] Re: Example of MPLS RLD with IOAM Trace in PSD
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/NLpipPElOlVFVOnNFPOsnh71T0g>
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>

[WG chair hat: off]

Hi Rakesh,

So you’re proposing that for each and every PSD action, we also define 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 PM, Rakesh Gandhi <rgandhi.ietf@gmail.com> 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
> 
> <image.png>
> 
> 
> Thanks,
> Rakesh
> 
> 
> 
> On Thu, Jun 27, 2024 at 3:42 PM Tony Li <tony.li@tony.li <mailto:tony.li@tony.li>> wrote:
>> 
>> [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’t build routers with oracles in them.
>> 
>> Let’s suppose that a router recieves a packet and parses down it’s RLD.  It finds an MNA indication, but PSD does not lie within that RLD.  How do you know that it’s IOAM?  You haven’t 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’s 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 PM, Rakesh Gandhi <rgandhi.ietf@gmail.com <mailto: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 PM Tony Li <tony.li@tony.li <mailto: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’m still missing your point here. There are cases that work, there are cases that don’t. Are you trying to say something more?
>>>> 
>>>> We can’t 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 AM, Rakesh Gandhi <rgandhi.ietf@gmail.com <mailto: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
>>>>> 
>>>>> 
>>>>> 
>>>>> On Thu, Jun 27, 2024 at 11:54 AM Tony Li <tony.li@tony.li <mailto:tony.li@tony.li>> wrote:
>>>>>> [WG chair hat: off]
>>>>>> 
>>>>>> Hi Rakesh,
>>>>>> 
>>>>>> I’m missing some point that I think you’re trying to make.
>>>>>> 
>>>>>> Suppose that a node in this network only has an RLD of 64 octets (i.e., 16 LSE equivalents).  Won’t 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 AM, Rakesh Gandhi <rgandhi.ietf@gmail.com <mailto: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.
>>>>>>> https://www.ietf.org/archive/id/draft-ietf-mpls-mna-usecases-10.html#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-dex-01
>>>>>>>  
>>>>>>>  
>>>>>>> _______________________________________________
>>>>>>> mpls mailing list -- mpls@ietf.org <mailto:mpls@ietf.org>
>>>>>>> To unsubscribe send an email to mpls-leave@ietf.org <mailto:mpls-leave@ietf.org>
>>>>>> 
>>>> 
>>