[mpls] Re: Fwd: Fwd: Re: Discussion points for upcoming MPLS WG interim

["Dongjie (Jimmy)" <[e-mail]>]

Fully agree with Toerless on taking BIER as a precedent, as both BIER and MNA are innovations to the high-speed forwarding plane. 

As I mentioned during the interim, the changes introduced both to the MPLS architecture and to MPLS forwarding are different from any MPLS enhancements we ever had. Traditional MPLS only defined three foperations to the top label (PUSH, POP, SWAP), which does not change much in the past 25 years, while MNA requires new forwarding behaviors to the label stack (BTW update to both RFC 3031 and 3032 needs to be reflected in the draft). As discussed on the interim, this is also different from the processing of the entropy label. 

The concerns are that such big changes lack of the proof of implementation by the industry, and it is not clear whether and how much existing hardware can support the MNA operations and functionality. Even if the functionality can be supported, the impact to forwarding performance also needs to be evaluated, and possible changes to the spec may be needed to improve the performance. Also there is risk of inconsistent capability in the MNA processing by different vendors, which means interoperation also needs to be verified. 

Thus in order to make MNA a practical enhancement to MPLS, it would be necessary to put it in experimental track first to obtain the needed experience with its feasibility, performance, interoperability and backward compatibility.

Best regards,
Jie

> -----Original Message-----
> From: Toerless Eckert <[e-mail]>
> Sent: Wednesday, February 19, 2025 1:49 AM
> To: Adrian Farrel <[e-mail]>
> Cc: 'Joel Halpern' <[e-mail]>; Dongjie (Jimmy)
> <[e-mail]>; 'mpls' <[e-mail]>
> Subject: Re: [mpls] Re: Fwd: Fwd: Re: Discussion points for upcoming MPLS
> WG interim
> 
> > So, a possible advantage of eSPL is that there is no shortage. Doing MNA on
> eSPL would mean it did not need to be Experimental. Even if there was a need
> to version MNA, it could just use another eSPL.
> 
> We where/are linking BIER headers from MPLS label stacks through just normal
> MPLS labels, so no code point worries, but that did not mean that BIER was
> initially considered fit for PS by IETF.
> 
> Instead it was first put into experimental track until there was enough
> evidence of ability to support on different vendor hardware and enough PoC or
> other implementation experience to know the operational model implied by
> BIER was sane. And unlike LISP, BIER equally was a question of implementation
> in high speed forwarding hardware like MNA is.
> 
> So i disagree with your unqualified "it (MNA) did not need to be Experimental
> (if we would just use ePSD)".
> 
> Cheers
>     Toerless
> 
> P.S.: If you where involved in BIER (especially RFC wise), there's a chance to get
> yourself a great 10 year anniversary t-shirt that GregS designed - check out the
> bier mailing list thread ;-)) [end of shameless plug]
> 
> On Tue, Feb 18, 2025 at 12:32:18PM -0000, Adrian Farrel wrote:
> > I continue to wish that we could separate our discussion of eSPL from
> > the discussion of Experimental :-)
> >
> > What is the benefit of using eSPL over bSPL?
> > There have been voices saying that MNA is too unproven to risk using a bSPL.
> The "risk" is that as implementations of MNA progress, it is discovered that
> changes to the encoding are needed and, because there is no versioning built
> in to the MNA header. In this event, assuming deployments on the first bSPL, a
> second bSPL would be needed for the new MNA version.
> > I *think* this is one of the reasons given for making the work Experimental.
> >
> > So, a possible advantage of eSPL is that there is no shortage. Doing MNA on
> eSPL would mean it did not need to be Experimental. Even if there was a need
> to version MNA, it could just use another eSPL.
> >
> > To be clear, I'm not taking a position on this. I don't have an implementation
> and don't plan to have one. But I would like the discussion to move on so that
> we can decide what we are doing with MNA, and then spend our time on
> other things.
> >
> > Cheers,
> > Adrian
> >
> > -----Original Message-----
> > From: Joel Halpern <[e-mail]>
> > Sent: 18 February 2025 06:48
> > To: Dongjie (Jimmy) <[e-mail]>; mpls <[e-mail]>
> > Subject: [mpls] Re: Fwd: Fwd: Re: Discussion points for upcoming MPLS
> > WG interim
> >
> > I am missing something.  What is the benefit of using an eSPL for the
> > MNA HDR?  whether the difference between a bSPL and eSPL is significant
> > or not, this seems the canocal case for using a bSPL.   As far as I
> > know, the only argument for using an eSPL was if one assumed
> > experimental status, then one has to use an eSPL.
> >
> > It is also completely unclear to me what the "experiment" would tell
> > us, or even what experiment is envisioned.  I have not seen a clear
> > articulation of the "experiment" that is desired.
> >
> > Yours,
> >
> > Joel
> >
> > On 2/18/2025 1:36 AM, Dongjie (Jimmy) wrote:
> > > Hi Adrian and Loa,
> > >
> > > Thanks for raising the discussion about the encoding efficiency. I agree with
> Adrian that the difference between eSPL and bSPL become less significant for
> large MNA constructs, and I agree with Loa that the evaluation on the impact
> of using eSPL vs bSPL could be part of the experiment.
> > >
> > > Best regards,
> > > Jie
> > >
> > >> -----Original Message-----
> > >> From: Loa Andersson <[e-mail]>
> > >> Sent: Sunday, February 16, 2025 11:23 PM
> > >> To: mpls <[e-mail]>; Joel Halpern <[e-mail]>;
> > >> Adrian Farrel <[e-mail]>
> > >> Subject: [mpls] Fwd: Fwd: Re: Discussion points for upcoming MPLS
> > >> WG interim
> > >>
> > >> Working Group,
> > >>
> > >> I made an addressing mistake, and the below weas only sent to
> > >> Adrian, but was really intended for the entire WG.
> > >>
> > >> /Loa
> > >>
> > >>
> > >> Adrian and Joel,
> > >>
> > >> If we are digging into LSE counting there are more alternatives :).
> > >>
> > >> - we could assign an eSPL for PSD, and use 11 bits (TC and TTL) for the
> offset.
> > >>
> > >> or
> > >>
> > >> - we could appoint one eSPL per PSD network action type, 11 bits
> > >> for offset
> > >>
> > >> or
> > >>
> > >> - one eSPL per combination of PSD network action types
> > >>
> > >> or
> > >>
> > >> - do the same for each combination of ISD and PSD
> > >>
> > >> The efficiency of the above obviously depends on how many NAs we
> > >> think we’ll have per packet. I have no answer to that.
> > >>
> > >> I’m not particularly in favor of any of these, but sonfar I had no
> > >> possibility to evaluate any of the ideas. This is one aspect where I believe
> “an experiment”
> > >> could be useful.
> > >>
> > >> /Loa
> > >>
> > >>
> > >> On Sun, 16 Feb 2025 at 12:13, Adrian Farrel <[e-mail]
> > >> <mailto:[e-mail]>> wrote:
> > >>
> > >>       Hi Joel,
> > >>
> > >>        > Well, since email discussion is useful to more folks than
> > >> the interim
> > >>
> > >>       :-)
> > >>
> > >>        > I will respond to your primary question here.
> > >>        >
> > >>        > From where I sit, no, using an eSPL for the MNA HDR is not a
> good
> > >>        > choice.  Running any kind of experiment will not tell us if using
> > >>       a bSPL
> > >>        > would be ffective / useful.  And from where I sit, the whole
> > >>       point was
> > >>        > to avoid using an eSPL.  If MNA HDR uses an eSPL, the
> marginal
> > >>       value of
> > >>        > using MNA HDR over defining new free-standing mYours,
> > >>
> > >>       I'd like to untangle that a little because I think that the "should
> > >>       it be / does it need to be experimental?" is a different question
> > >>       from "bSPL or eSPL?"
> > >>
> > >>       Your email is a little truncated, but your point appears to be that
> > >>       the "minimal" MNA cost moves from 2 LSEs with bSPL (Format A
> plus
> > >>       Format B) to 3 LSEs with eSPL, and that that increase makes the
> use
> > >>       of MNA of marginal benefit compared to other approaches that
> could
> > >>       be invented.
> > >>
> > >>       I suppose that the marginality becomes less significant for larger
> > >>       MNA constructs. For example, looking at
> draft-ietf-mpls-mna-ioam-00
> > >>       for the ISD variant, results in Format A, Format B, and a number of
> > >>       Format D LSEs. AFAICS there are two mandatory Format D LSEs
> and two
> > >>       optional Format D LSEs. So a potential 7 LSEs with bSPL or 8 with
> eSPL.
> > >>
> > >>       Now, I am not a hardware engineer and I am not trying to
> influence
> > >>       this debate. I just want to get to the facts and then help people
> > >>       decide bSPL or eSPL.
> > >>
> > >>       My belief is that the debate over Experimental is orthogonal to
> this
> > >>       discussion. It's a debate we should have, but we can make the
> > >>       discussion of that point simpler if we first resolve the b/e
> discussion.
> > >>
> > >>       Cheers,
> > >>       Adrian
> > >>
> > >>       On 2/15/2025 8:41 AM, Adrian Farrel wrote:
> > >>        > Hi all,
> > >>        >
> > >>        > In the light of the agenda which reads...
> > >>        >> Discuss the progress of MNA related WG documents,
> including:
> > >>        >> -
> https://datatracker.ietf.org/doc/html/draft-ietf-mpls-mna-hdr
> > >>       <https://datatracker.ietf.org/doc/html/draft-ietf-mpls-mna-hdr>
> > >>        >> - https://datatracker.ietf.org/doc/draft-jags-mpls-ps-mna-hdr
> > >>       <https://datatracker.ietf.org/doc/draft-jags-mpls-ps-mna-hdr>
> > >>        > ...I thought I would send out a couple of questions I would like
> > >>       to see answered.
> > >>        >
> > >>        > 1. Are we happy to use an eSPL for MNA?
> > >>        > The current version of draft-ietf-mpls-mna-hdr uses an eSPL.
> This
> > >>       was introduced at 09 as part of moving to Experimental. I believe
> > >>       the reasoning was that there is no scope for an Experimental bSPL.
> > >>        > I understand that the resulting encoding is not optimal (an eSPL
> > >>       takes two LSEs to sign MNA, where a bSPL would only take one).
> > >>        > But how significant is this issue?
> > >>        > Is it something we could live with or will it make MNA
> completely
> > >>       infeasible?
> > >>        >
> > >>        > 2. If we can accept using an eSPL, would this remove the need
> to
> > >>       be Experimental?
> > >>        > There is clearly no shortage of eSPLs (while there is a
> > >>       considerable restriction on the available bSPLs).
> > >>        > The abundance of eSPLs means that we can effectively version
> MNA
> > >>       using a new eSPL if we find the need to make changes to MNA.
> > >>        > That would mean that we could safely publish MNA using eSPL
> on
> > >>       the Standards Track.
> > >>        >
> > >>        > 3. If we remain as Experimental, what is the scope of the
> experiment?
> > >>        > The current draft only says...
> > >>        >     This document
> > >>        >     describes an experiment whose purpose is to demonstrate
> that
> > >>       the MNA
> > >>        >     can be implemented and deployed.
> > >>        > Looking at draft-bonica-gendispatch-exp, there is a lot more
> that
> > >>       it would be helpful to add.
> > >>        >
> > >>        > Thanks for answering in advance, or for thinking about it and
> > >>       arriving at the meeting with opinions.
> > >>        >
> > >>        > Cheers,
> > >>        > Adrian
> > >>        >
> > >>        > _______________________________________________
> > >>        > mpls mailing list -- [e-mail] <mailto:[e-mail]>
> > >>        > To unsubscribe send an email to [e-mail]
> > >>       <mailto:[e-mail]>
> > >>
> > >>       _______________________________________________
> > >>       mpls mailing list -- [e-mail] <mailto:[e-mail]>
> > >>       To unsubscribe send an email to [e-mail]
> > >>       <mailto:[e-mail]>
> > >>
> > >> _______________________________________________
> > >> mpls mailing list -- [e-mail]
> > >> To unsubscribe send an email to [e-mail]
> >
> > _______________________________________________
> > mpls mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> >
> > _______________________________________________
> > mpls mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> 
> --
> ---
> [e-mail]