[mpls] Re: Request WG adoption for draft-jags-mpls-ps-mna-hdr-03.txt

Loa Andersson <loa@pi.nu> Fri, 28 June 2024 09:03 UTC

Return-Path: <loa@pi.nu>
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 8EDA7C14F5FB; Fri, 28 Jun 2024 02:03:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.906
X-Spam-Level:
X-Spam-Status: No, score=-6.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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
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 S5tnY3K3HF8g; Fri, 28 Jun 2024 02:03:48 -0700 (PDT)
Received: from srv.pi.nu (srv.pi.nu [46.246.39.30]) (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 6017DC14F700; Fri, 28 Jun 2024 02:03:46 -0700 (PDT)
Message-ID: <0e374a64-83ed-48e6-b6b7-770fae51e987@pi.nu>
Date: Fri, 28 Jun 2024 11:03:44 +0200
MIME-Version: 1.0
To: Greg Mirsky <gregimirsky@gmail.com>
References: <MN2PR11MB4064044709C9B25C7A7C39DBD0D62@MN2PR11MB4064.namprd11.prod.outlook.com> <20fade0a-e70a-4e62-a9d3-504e29940843@pi.nu> <7c285cf9-8f6c-4a57-b340-77e0772bef9b@joelhalpern.com> <74fb062b-3342-47e8-a62c-d160a04e5600@pi.nu> <CA+RyBmW6qmuH5=yEp2tJtbUejcgzVG6XWs+D0cerHgdiqA4k7w@mail.gmail.com>
Content-Language: sv, en-GB
From: Loa Andersson <loa@pi.nu>
In-Reply-To: <CA+RyBmW6qmuH5=yEp2tJtbUejcgzVG6XWs+D0cerHgdiqA4k7w@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Message-ID-Hash: PJNG7UOZARRIHE4PDKMG6YXJODHLEEQE
X-Message-ID-Hash: PJNG7UOZARRIHE4PDKMG6YXJODHLEEQE
X-MailFrom: loa@pi.nu
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>, "draft-jags-mpls-ps-mna-hdr@ietf.org" <draft-jags-mpls-ps-mna-hdr@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [mpls] Re: Request WG adoption for draft-jags-mpls-ps-mna-hdr-03.txt
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/vuDncjg0Bd_Y19M0oQEs9jMxISE>
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>

Greg,

Sorry I was not clear. I have three bullets
- the first is related to direct export
- the second and third is not (directly ) related to direct export.

So I'm not "mentioning" time stamp in the context of direct export, I 
mention time stamp in the second bullet, which is am observation on 
mutable data in ISD.

I don't think the problem with encoding the sequence number goes away 
because it is optional. It is optional, meaning that it might be there, 
it is mutable and can't be present in the first 20 bits, since they 
might be used for ECMP hashing.

I have not thought about how many bits we need, you specified it as 22 
bits, and I checked how to encode this in ISD, it takes two LSEs and 
disrupts the extension flags. With PSD you could easily allow for 32 
bits (as in RFC 9326).

/Loa

Den 2024-06-27 kl. 15:25, skrev Greg Mirsky:
> Hi Loa,
> thank you for sharing your opinion. I do agree that mutability of 
> IOAM-DEX, as mutability in general, is a restricting aspect in ECMP 
> environments that use the label stack information to generate entropy 
> used in load-balancing. I read the latest version of the draft and 
> have several questions on it and your notes:
>
>   * You mention timestamp in connection with IOAM-DEX. Could you
>     please point out to me where and how a timestamp information is
>     used in RFC 9326 <https://datatracker.ietf.org/doc/rfc9326/>,
>     draft-mb-mpls-ioam-dex
>     <https://datatracker.ietf.org/doc/draft-mb-mpls-ioam-dex/>, or
>     draft-jags-mpls-ps-mna-hdr
>     <https://datatracker.ietf.org/doc/draft-jags-mpls-ps-mna-hdr/>?
>   * As I understand RFC 9326
>     <https://datatracker.ietf.org/doc/rfc9326/>, the Sequence Number
>     is optional and is not used for Loss Measurement but, in
>     combination with the Flow ID, help correlating telemetry
>     information generated by the same packet equipped with the
>     IOAM-DEX. In your opinion, how large space is useful for the
>     Sequence Number for the purpose described in RFC 9326
>     <https://datatracker.ietf.org/doc/rfc9326/>?
>   * And a more general question. How draft-jags-mpls-ps-mna-hdr
>     <https://datatracker.ietf.org/doc/draft-jags-mpls-ps-mna-hdr/> can
>     be used in RLD-limited environment?
>
> Regards,
> Greg
>
>
> On Thu, Jun 27, 2024 at 3:11 AM Loa Andersson <loa@pi.nu> wrote:
>
>     Joel, wg, wg-chairs,
>
>     No I don't think we are in the first case, ISD and PSD is not
>     equally good
>     for all cases.
>
>     - both Rakesh and I have demonstrated that PSD is much more
>     straightforward
>        for direct export, and it is possible to align nicely with the
>     base
>     direct
>        export RFC. We don't miss bits here and there, we don't need to
>     use
>     two LSEs
>        for the sequence number optional filed, we don't need to map
>     extension flags
>        from 8 bits to 6 bits. This is a case two situation. PSD would
>     be better.
>
>     - it has earlier demonstrated that 19 octets worth of mutable data
>     as ISD,
>        personally I believe that that is a too serious limit, since to my
>     understanding
>        you for example you typically need at least 8 octets for a
>     timestamp.
>     This is
>        mutable data, so you can only put two timestamps in one packet.
>     That
>     seems to
>        me to be a limitation that we can't live with. This is a case 3
>     situation.
>        ISD can't solve m ore than 2 timestamps, PSD can. I'm   not a an
>     expert in the
>        area, so I leave it to the experts to tell me if I'm right or
>     wrong.
>
>     - We also seen cases where adding "too much" ISD into the stack,
>     gives
>     us label
>        stacks that are too deep. If you want to put two timestamp in
>     as ISD,
>     you will
>        need to increase the label stack with 12 LSEs, which seem to
>     excessive. A case
>        3 situation.
>
>     Yeah, so we need PSD. Please poll the draft-jags-mpls-ps-mna-hdr for
>     working group
>     adoption.
>
>     /Loa
>
>
>
>     Den 2024-06-26 kl. 21:35, skrev Joel Halpern:
>     > Loa, you list three bullet points with three different results.
>     > However, what has been shown so far seems to correspond to your
>     first
>     > case, which you state does not justify two solutions. Adopting a
>     > post-stack data solution before we decide we are in case three,
>     or in
>     > case 2 and feel the tradeoff is right, seems premature. It may well
>     > be that the ps draft is the right starting point once we have
>     agreed
>     > on the problems to be solved. Which is why I am trying to
>     understand
>     > the motivations for Rakesh' iOAM dex draft.  (I do think we need to
>     > support IOAM DEX.)
>     >
>     > Yours,
>     >
>     > Joel
>     >
>     > On 6/26/2024 3:30 PM, Loa Andersson wrote:
>     >> Jags, authors, chairs, working group,
>     >>
>     >>
>     >> I support making draft-jags-mpls-ps-mna-hdr a working group
>     document.
>     >>
>     >> It has repeatedly been said by those who want ISD-solutions that
>     >> PSD-solutions ar not needed.
>     >>
>     >> I think this is a fundamentally flawed way of asking the question.
>     >>
>     >> - if we have a choice between two solutions and they are
>     equally good
>     >>   for all cases, then it makes sense to try to find consensus for
>     >> adopting
>     >>   one of the solutions
>     >> - if we have a choice between two solutions there both
>     solutions "can
>     >> do" all
>     >>   cases, but there one is significantly better for one set of
>     cases
>     >> and the
>     >>   other is significantly better for the remaining cases, we should
>     >> cases we
>     >>    should seriously consider going for two solutions.
>     >> - if we we have the a choice between two solutions there one can
>     >> solve part of
>     >>   the cases and the other the remaining cases, the we need to
>     go for two
>     >>   solutions.
>     >>
>     >> /Loa
>     >>
>     >>
>     >> Den 2024-06-26 kl. 04:50, skrev Jaganbabu Rajamanickam (jrajaman):
>     >>>
>     >>> Hello Chairs,
>     >>>
>     >>>    We would like to request WG adoption for
>     draft-jags-mpls-ps-mna-hdr.
>     >>>
>     >>>    Updated the draft with the initial review comments and the
>     latest
>     >>> MNA header format.
>     >>>
>     >>>   Welcome your review comments and suggestions.
>     >>>
>     >>> Thanx,
>     >>>
>     >>> Jags
>     >>>
>     >>>
>     >>> _______________________________________________
>     >>> mpls mailing list -- mpls@ietf.org
>     >>> To unsubscribe send an email to mpls-leave@ietf.org
>     >>
>
>     -- 
>     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
>

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