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

[Greg Mirsky <[e-mail]>]

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 <[e-mail]> 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 -- [e-mail]
> >>> To unsubscribe send an email to [e-mail]
> >>
>
> --
> Loa Andersson
> Senior MPLS Expert
> Bronze Dragon Consulting
> [e-mail]
> [e-mail]
>
> _______________________________________________
> mpls mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>