IETF Logo Mail Archive

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

Joel Halpern <jmh@joelhalpern.com> Sat, 29 June 2024 02:14 UTC

Return-Path: <jmh@joelhalpern.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 92393C151092 for <mpls@ietfa.amsl.com>; Fri, 28 Jun 2024 19:14:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.805
X-Spam-Level:
X-Spam-Status: No, score=-2.805 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=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 (1024-bit key) header.d=joelhalpern.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 NrmCa4fsStlp for <mpls@ietfa.amsl.com>; Fri, 28 Jun 2024 19:14:33 -0700 (PDT)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 A6A16C14CEFF for <mpls@ietf.org>; Fri, 28 Jun 2024 19:14:33 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4W9wqF28w8z1prKx; Fri, 28 Jun 2024 19:14:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1719627273; bh=6pgcOCrGnQUuSlUvl12+ax857NqSKGKpBy78lkNDUa0=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=kl5sHyo0qPIlYOQH4WSxrWTtrHybaKH3sy4F2ukXVNY9J/muh86EIc9MlQ5Pk041e OXlWxRQkQuG3oPt/dG7X+GoOQawrjL5eXQqF99JU9LDwN43NZzWHYh2Ue475taPNeV ezgmCEVPSnBZJLcPxfNR3/Go7yZ2TWWVHpRyQBLk=
X-Quarantine-ID: <UPEW1XJJPF0v>
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from [192.168.22.41] (unknown [50.233.136.230]) (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 mailb2.tigertech.net (Postfix) with ESMTPSA id 4W9wqD4Pm9z1ns0y; Fri, 28 Jun 2024 19:14:31 -0700 (PDT)
Content-Type: multipart/alternative; boundary="------------2QoTzesnGQ91TyG5UwSfU6Ux"
Message-ID: <43b621d2-a719-408a-ad95-b6529094a518@joelhalpern.com>
Date: Fri, 28 Jun 2024 22:14:29 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: Haoyu Song <haoyu.song@futurewei.com>
References: <CAMZsk6cT-AZ8Dswd37Owu+Bhte=jR-3BmaA6JA7ftQmLgUQ5RQ@mail.gmail.com> <BY3PR13MB4787B139A5D244002DB342BB9AD72@BY3PR13MB4787.namprd13.prod.outlook.com> <7cb5252c-a3c5-4420-95fd-25a3cc740cd3@joelhalpern.com> <BY3PR13MB47870E7FFECC993380CF54269AD72@BY3PR13MB4787.namprd13.prod.outlook.com> <dd5c3b8c-9e5e-4098-8dc3-5a3c9a255060@pi.nu> <c7fb6f16-fcb3-442d-8589-ccc711ed0b65@joelhalpern.com> <CAPOsKjFggj8yTTCf_PEcORispCs7c1wEegvVqBDLZDuV+nOF0w@mail.gmail.com> <23d95f69-355e-4b07-965e-618c2ac6effb@joelhalpern.com> <4567FBB8-CF23-4CA5-B4C1-8396BC83F81E@tony.li> <8589af53-81cf-4187-be54-73673f468e1f@joelhalpern.com> <526B1E1D-A9F2-4254-9793-BA49229088DE@tony.li> <CA+RyBmUx8kKJvL2=aNTj069kMymm4=oaghX-pYcATPEH=-wbJg@mail.gmail.com> <BY3PR13MB4787775561259447275654C89AD12@BY3PR13MB4787.namprd13.prod.outlook.com> <CA+RyBmVwytv2Ar9phekmvwXUW3RaGoB6YGpqw_WqFCZ9L8Q46A@mail.gmail.com> <BY3PR13MB478733156DF4A42C7DAC7E289AD12@BY3PR13MB4787.namprd13.prod.outlook.com>
Content-Language: en-US
From: Joel Halpern <jmh@joelhalpern.com>
In-Reply-To: <BY3PR13MB478733156DF4A42C7DAC7E289AD12@BY3PR13MB4787.namprd13.prod.outlook.com>
Message-ID-Hash: HAGLLHBWJU7YMDLQI7IODVFYU7IJMVVC
X-Message-ID-Hash: HAGLLHBWJU7YMDLQI7IODVFYU7IJMVVC
X-MailFrom: jmh@joelhalpern.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/34t-OL3NQGtcDoX4LmoF9EcBDIM>
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>

Haoyu, I presume your phrasing is a bit off?  I have heard plenty of 
operators in informal conversation state that they want particular 
subsets of features and have no interest in other subssets.  I have seen 
this in writing in RFPs.  I can not and will not speak for them as to 
what they want in IOAM.  But I am sure that different operators want 
different subsets.


Yours,

Joel

On 6/28/2024 9:10 PM, Haoyu Song wrote:
>
> Ok, that confirms my understanding. I never heard anyone said they 
> only care this and don’t care that.
>
> Best regards,
>
> Haoyu
>
> *From:* Greg Mirsky <gregimirsky@gmail.com>
> *Sent:* Friday, June 28, 2024 6:02 PM
> *To:* Haoyu Song <haoyu.song@futurewei.com>
> *Cc:* Tony Li <tony.li@tony.li>; Joel Halpern Direct 
> <jmh.direct@joelhalpern.com>; mpls <mpls@ietf.org>
> *Subject:* Re: [mpls] Re: Example of MPLS RLD with IOAM Trace in PSD
>
> Hi Haoyu,
>
> I don't think such a line of questioning is appropriate. As I 
> understand it, in IETF everyone speaks out only for himself/herself, 
> unless when acting in the capacity of the Liaison Officer.
>
> Regards,
>
> Greg
>
> On Fri, Jun 28, 2024 at 5:51 PM Haoyu Song <haoyu.song@futurewei.com> 
> wrote:
>
>     Hi Greg,
>
>     Do you make the statement on behalf of yourself or your customers
>     or the operators at large?
>
>     Best regards,
>
>     Haoyu
>
>     *From:* Greg Mirsky <gregimirsky@gmail.com>
>     *Sent:* Friday, June 28, 2024 5:41 PM
>     *To:* Tony Li <tony.li@tony.li>
>     *Cc:* Joel Halpern Direct <jmh.direct@joelhalpern.com>; mpls
>     <mpls@ietf.org>
>     *Subject:* [mpls] Re: Example of MPLS RLD with IOAM Trace in PSD
>
>     Hi Tony,
>
>     As I understand it, the interest is in the IOAM-DEX, not any of
>     the options that collect telemetry information in the data packet
>     equipped with the IOAM header, e.g., IOAM Preallocated Trace or
>     Incremental Trace. Also, the Proof-of-Transit is out of scope.
>
>     Regards,
>
>     Greg
>
>     On Fri, Jun 28, 2024 at 5:24 PM Tony Li <tony.li@tony.li> wrote:
>
>         Can they be more specific about the types of IOAM that they
>         care about?
>
>         T
>
>             On Jun 28, 2024, at 3:35 PM, Joel Halpern
>             <jmh.direct@joelhalpern.com> wrote:
>
>             Yes, talking to my colleagues who deal with OAM
>             aspects,they tell me we have use for IOAM.
>
>             Yours,
>
>             Joel
>
>             On 6/28/2024 5:25 PM, Tony Li wrote:
>
>                 Hi Joel,
>
>                 I agree completely.  In fact, RLD suggests that it is
>                 stronger to encode things in ISD whenver possible.
>
>                 That said, do you agree that we need to support IOAM?
>
>                 T
>
>                     On Jun 28, 2024, at 1:09 PM, Joel Halpern
>                     <jmh@joelhalpern.com> <mailto:jmh@joelhalpern.com>
>                     wrote:
>
>                     I agreed that the RLD issue affects both ISD and
>                     PSD.  So RLD is not a basis for deciding that we
>                     need PSD.
>
>                     Yours,
>
>                     Joel
>
>                     On 6/28/2024 11:27 AM, Jaganbabu Rajamanickam wrote:
>
>                         The RLD issue is common to both ISD and PSD.
>
>                         There was an argument that, in the case of
>                         ISD, duplicating the NAS is an option.
>                         However, if the intermediate node cannot read
>                         the NAS, even when duplicated, it results in
>                         the same predicament.
>
>                         In my opinion, it is imperative that the node
>                         which inserts the NAS (ISD or PSD) MUST ensure
>                         that the intermediate node is capable of
>                         processing the necessary Network Actions.
>
>                         Thanx,
>
>                         Jags
>
>                         On Fri, Jun 28, 2024 at 8:46 AM Joel Halpern
>                         <jmh@joelhalpern.com> wrote:
>
>                             Readable Label Depth is as far as I know
>                             the amount of header that the
>                             device can process in the fast path. In
>                             the PSD case, that needs to
>                             include data that is part the bottom of
>                             stack indication.  It is still
>                             subject to the fast path data length
>                             limitation, even if it is PSD.
>                             (Yes, PSD is don't technically "labels". 
>                             But it still needs to be read
>                             and processed, as Tony Li as been pointing
>                             out.)
>
>                             Yours,
>
>                             Joel
>
>                             On 6/28/2024 4:30 AM, Loa Andersson wrote:
>                             > Joel,
>                             >
>                             > Excuse a naive questions. What is the
>                             RLD for PSD?
>                             >
>                             > /Loa
>                             >
>                             > Den 2024-06-28 kl. 00:12, skrev Haoyu Song:
>                             >>
>                             >> No. I just acknowledge the implication
>                             of RLD and figure out the ways
>                             >> to handle it. I don’t think it’s the
>                             obstacle forbidding us to
>                             >> develop either ISD or PSD.
>                             >>
>                             >> Haoyu
>                             >>
>                             >> *From:* Joel Halpern <jmh@joelhalpern.com>
>                             >> *Sent:* Thursday, June 27, 2024 12:50 PM
>                             >> *To:* Haoyu Song <haoyu.song@futurewei.com>
>                             >> *Cc:* mpls <mpls@ietf.org>
>                             >> *Subject:* Re: [mpls] Re: Example of
>                             MPLS RLD with IOAM Trace in PSD
>                             >>
>                             >> Hmmm.
>                             >>
>                             >> If I read folks pushing PSD correctly,
>                             you were objecting to the RLD
>                             >> implications of ISD.  But you don't
>                             care about the RLD implication of
>                             >> PSD?
>                             >>
>                             >> Yours,
>                             >>
>                             >> Joel
>                             >>
>                             >> On 6/27/2024 2:44 PM, Haoyu Song wrote:
>                             >>
>                             >>      1. Even one can put ISD in any
>                             place, depending on the ISD size
>                             >> and the RLD, it’s still possible that
>                             the ISD can’t be
>                             >> supported.
>                             >>      2. If exceeding the RLD
>                             limitation, there are two choices: skip
>                             >> it on incapable nodes or don’t use it.
>                             >>
>                             >>     Haoyu
>                             >>
>                             >> *From:* Joel Halpern <jmh@joelhalpern.com>
>                             >> <mailto:jmh@joelhalpern.com>
>                             >> *Sent:* Thursday, June 27, 2024 11:39 AM
>                             >>     *To:* Haoyu Song
>                             <haoyu.song@futurewei.com>
>                             >> <mailto:haoyu.song@futurewei.com>
>                             >>     *Cc:* mpls <mpls@ietf.org>
>                             <mailto:mpls@ietf.org>
>                             >> *Subject:* Re: [mpls] Re: Example of
>                             MPLS RLD with IOAM Trace in PSD
>                             >>
>                             >>     I am missing something in your
>                             analysis. With ISD, using the
>                             >> knowledge of the RLD, the head end can
>                             put duplicate substacks in
>                             >> various places so as to ensure
>                             visibility of the actions within
>                             >>     the RLD.  With PSD, that is simply
>                             not possible.  Meaning that if
>                             >>     the PSD needs to be processed by
>                             intermediate nodes with RLD
>                             >> limitations, I can not figure out what
>                             remediation the hed end can
>                             >> undertake to make it work.
>                             >>
>                             >> Yours,
>                             >>
>                             >>     Joel
>                             >>
>                             >>     On 6/27/2024 2:15 PM, Haoyu Song wrote:
>                             >>
>                             >> When an MNA action is applied on a data
>                             path, whether it’s ISD
>                             >> or PSD, the operator needs to ensure
>                             the network will not run
>                             >> into the RLD issue through control
>                             plane mechanisms. That is,
>                             >> all the nodes that participate in the
>                             MNA processing will have
>                             >> RLD large enough to cover the ISD/PSD,
>                             and some nodes that
>                             >> won’t participate in the MNA
>                             processing, if there’s any, can
>                             >> safely forward the packet. In case all
>                             nodes must support an
>                             >> action to work, there’ll be a Yes or No
>                             decision on applying
>                             >> the action. With such provision,
>                             there’ll be no performance
>                             >> issue since no slow path processing is
>                             allowed and possible.
>                             >>
>                             >> The bottom line is: we can’t guarantee
>                             that every node on an
>                             >> existing network can support a PSD
>                             action (this applies to ISD
>                             >> action as well). One can argue the
>                             likelihood, but still
>                             >> there’s no guarantee, so the control
>                             plane discovery and
>                             >> negotiation are needed to ensure the
>                             performance.
>                             >>
>                             >> Best,
>                             >>
>                             >> Haoyu
>                             >>
>                             >> *From:* Tony Li <tony1athome@gmail.com>
>                             >> <mailto:tony1athome@gmail.com> *On
>                             Behalf Of *Tony Li
>                             >> *Sent:* Thursday, June 27, 2024 10:37 AM
>                             >> *To:* Rakesh Gandhi
>                             <rgandhi.ietf@gmail.com>
>                             >> <mailto:rgandhi.ietf@gmail.com>
>                             >> *Cc:* mpls <mpls@ietf.org>
>                             <mailto:mpls@ietf.org>
>                             >> *Subject:* [mpls] Re: Example of MPLS
>                             RLD with IOAM Trace in PSD
>                             >>
>                             >> [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> 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>
>                             >>             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> 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.
>                             >>
>                             >> 1.
>                             >>
>                             https://www.ietf.org/archive/id/draft-ietf-mpls-mna-usecases-10.html#name-in-situ-oam
>                             >>
>                             <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.
>                             >>
>                             >> 1.
>                             >>
>                             https://datatracker.ietf.org/doc/html/draft-gandhi-mpls-mna-ioam-dex-01
>                             >>
>                             <https://datatracker.ietf.org/doc/html/draft-gandhi-mpls-mna-ioam-dex-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
>                             tompls-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
>
>                     _______________________________________________
>                     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>
>
>         _______________________________________________
>         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 tompls-leave@ietf.org

v2.27.8 | Report a Bug | By Email | System Status