[mpls] Re: Working Group Last Call on draft-ietf-mpls-mna-hdr (2nd WG call)

[Greg Mirsky <[e-mail]>]

Hi Loa,
I agree with you that each method has issues and these must be thoroughly
investigaved. But I fail to understand how that can prevent the WG from
progressing the current version of draft-ietf-mpls-mna-hdr. AFAICS, if we
need the P-bit - the PSD specification re-defines the R(eserved) flag (that
what reserved fields are for, and we've used that technique number of times
before). And if we choose Opcode - the PSD draft will define it without any
other impact on the MNA Header. Am I missing something here?

Regards,
Greg

On Thu, Oct 3, 2024 at 1:13 AM Loa Andersson <[e-mail]> wrote:

> Greg,
>
> I think the jury is still out on this!
>
> If we know that the MNA PS header follow the LSE with the BoS set or if
> there are no other PS headers present, the the p-flag is enough.
>
> It also have the benefit that it saves a LSE compared to the
> OpCode/Offset method.
>
> Tony said in a mail 2024-09-02 "Some of us consider saving one LSE per
> packet to be ample reward."
>
> On the other hand if the MNA PS header is not immediately after the LSE
> with the BoS set, I think we need the OpCode/Offset, but I have not yet
> dug deep enough to say so.
>
> Also if we could specify both methods (p-flag and  OpCode/Offset) so we
> can optimize when possible. However two methods also have drawbacks.
>
> Currently I don't think this has been discussed enough.
>
> /Loa
>
> Den 02/10/2024 kl. 20:39, skrev Greg Mirsky:
> > I agree with John on the P-bit usefulness. As was discussed (and I
> > presented on DetNet and BIER cases), many applications use their Post-
> > stack Headers (PSHs). As a result, we cannot assume that PSD always
> > immediately follows the BoS, and thus PSD requires explicit
> > specification of the offset from the BoS LSE. That can be done using PSD
> > Option code point. With that said, what is the role of the P-bit that
> > some insist on? Indicate that somewhere in the NAS there's PSD Option?
> > That doesn't look useful to me.
> >
> > Regards,
> > Greg
> >
> > On Wed, Oct 2, 2024 at 11:06 AM John Drake
> > <je_drake=[e-mail]
> > <mailto:[e-mail]>> wrote:
> >
> >     Further, if we decide to use an opcode with ancillary data
> >     indicating the offset to the PSD we would not need a PSD indicator
> bit
> >
> >     On Wednesday, October 2, 2024 at 11:01:58 AM PDT, John Drake
> >     <je_drake=[e-mail]
> >     <mailto:[e-mail]>> wrote:
> >
> >
> >     Joel is correct.  We have had many discussions of how PSD indicators
> >     can be added to the framework provided by the subject draft, none of
> >     which require any changes now to that draft.  So, assuming that we
> >     ever decide that we need PSD, we can easily add those PSD indicators
> >     to that draft.
> >
> >     On Wednesday, October 2, 2024 at 10:31:05 AM PDT, Joel Halpern
> >     <[e-mail] <mailto:[e-mail]>> wrote:
> >
> >
> >     No, that does not follow.   PSD can build on the ISD draft. There
> >     are no
> >     changes required to the ISD (mna-hdr) draft to enable supporting PSD.
> >     Additional opcdes, flags, or other indications can be added in
> whatever
> >     PSD draft the working group adopts, if it ever does.
> >
> >     The only justification for holding up the ISD draft that I can see
> >     would
> >     be if there was support needed in nodes that support ISD and not PSD.
> >     There is  no indication of such a need.
> >
> >     Please do not put words in my mouth.  I have been very clear that the
> >     ISD draft should be advanced.
> >
> >     Yours,
> >
> >     Joel
> >
> >     On 10/2/2024 1:21 PM, Loa Andersson wrote:
> >      > Joel,
> >      >
> >      > Since you agree that PSD can't be done in isolation, but will
> depend
> >      > on ISD (or at least the MPLS label stack), I guess that you also
> >     agree
> >      > that we should wait with progress the ISD draft.
> >      >
> >      > /Loa
> >      >
> >      > Den 02/10/2024 kl. 14:57, skrev Joel Halpern:
> >      >> You highlight one of many open questions about what a P-flag
> would
> >      >> mean.  Which strongly suggests that deferring adding it until we
> >     have
> >      >> a working group draft on PSD, which can add it, would be
> sensible.
> >      >> And you have not responded meaningfully to my earlier concern
> that
> >      >> ther ei sno benefit to assigning the bit isntead of reserving
> >     it, as
> >      >> the draft currently does.
> >      >>
> >      >> Yours,
> >      >>
> >      >> Joel
> >      >>
> >      >> On 10/2/2024 6:01 AM, Loa Andersson wrote:
> >      >>> Zafar and Tianran,
> >      >>>
> >      >>> I certainly think that we should have the p-flag re-inserted.
> >      >>>
> >      >>> The problematic part is that we can't guarantee that the MNA
> Post-
> >      >>> Stack header directly after the LSE with the BoS set. There
> >     might be
> >      >>> some CW there and we need to be able (one way or another) to
> tell
> >      >>> where the MNA Post-stack header starts. OpCode + offset? That
> >     is by
> >      >>> definition ISD, so we need to think a bit about how we specify
> >     this.
> >      >>>
> >      >>> /Loa
> >      >>>
> >      >>>
> >      >>>
> >      >>> Den 01/10/2024 kl. 18:37, skrev Zafar Ali (zali):
> >      >>>> Dear chairs and the WG,
> >      >>>>
> >      >>>> I agree with Tianran.
> >      >>>>
> >      >>>> I am also concerned about lack of implementation experience and
> >      >>>> interoperability for a data plane change addressing a subset
> >     of the
> >      >>>> MNA architecture.
> >      >>>>
> >      >>>> These are hardware changes that are not proven or demonstrated
> in
> >      >>>> the field, yet.
> >      >>>>
> >      >>>> Thanks
> >      >>>>
> >      >>>> Regards … Zafar
> >      >>>>
> >      >>>> *From: *Tianran Zhou <zhoutianran=[e-mail]
> >     <mailto:[e-mail]>>
> >      >>>> *Date: *Monday, September 30, 2024 at 8:08 PM
> >      >>>> *To: *Joel Halpern <[e-mail]
> >     <mailto:[e-mail]>>
> >      >>>> *Cc: *mpls <[e-mail] <mailto:[e-mail]>>
> >      >>>> *Subject: *[mpls] Re: Working Group Last Call on
> >      >>>> draft-ietf-mpls-mna- hdr (2nd WG call)
> >      >>>>
> >      >>>> Looking at the use case draft, PSD can address all use cases
> and
> >      >>>> future proof. In this sense, there is no need to implement ISD
> >     at all.
> >      >>>>
> >      >>>> I also started a thread in the working group mailing list to
> >      >>>> investigate the operators requirements. I only got one
> >     requirement
> >      >>>> on noffrr. There’s rare interest on existing MNA.
> >      >>>>
> >      >>>> I can’t believe we are going to publish such paper work in a
> >     hurry.
> >      >>>>
> >      >>>> Tianran
> >      >>>>
> >      >>>>
> >      >>>>
> >      >>>>
> >
>  ------------------------------------------------------------------------
> >      >>>>
> >      >>>>
> >      >>>>
> >      >>>> Sent from WeLink
> >      >>>>
> >      >>>> *发**件人： *Joel Halpern<[e-mail]
> >     <mailto:[e-mail]>
> >      >>>> <mailto:[e-mail] <mailto:[e-mail]>>>
> >      >>>>
> >      >>>> *收件人： *Tianran Zhou<[e-mail]
> >     <mailto:[e-mail]>
> >      >>>> <mailto:[e-mail] <mailto:[e-mail]
> >>>
> >      >>>>
> >      >>>> *抄送： *mpls<[e-mail] <mailto:[e-mail]>
> >     <mailto:[e-mail] <mailto:[e-mail]>>>
> >      >>>>
> >      >>>> *主**题**： *Re: [mpls] Re: Working Group Last Call on draft-
> >     ietf-
> >      >>>> mpls- mna-hdr (2nd WG call)
> >      >>>>
> >      >>>> *时间**： *2024-09-30 10:40:20
> >      >>>>
> >      >>>> Given that the PSD proposal on the table requires the ISD
> draft,
> >      >>>> and does not require any changes to the ISD draft, I do not
> >      >>>> understand your comments.  You have said you do not want any
> ISD
> >      >>>> solution, and now you are suggesting we adopt a PSD solution
> that
> >      >>>> requires ISD?
> >      >>>>
> >      >>>> And it is not clear that we need a PSD solution at all.
> >      >>>>
> >      >>>> If we need a PSD solution, I expect with some clarifications
> and
> >      >>>> modifications the jags psd draft can serve as a basis for
> further
> >      >>>> work.  I would strongly prefer to get the ISD work done.  Then
> we
> >      >>>> can have the debate about whethere we need PSD, and then
> discuss
> >      >>>> what a solution should look like.
> >      >>>>
> >      >>>> Yours,
> >      >>>>
> >      >>>> Joel
> >      >>>>
> >      >>>> On 9/29/2024 10:16 PM, Tianran Zhou wrote:
> >      >>>>
> >      >>>>     Then why not adopting that PSD proposal as the base for
> >      >>>> discussion?
> >      >>>>     And find out how it will require the
> draft-ietf-mpls-mna-hdr.
> >      >>>>
> >      >>>>     Best,
> >      >>>>
> >      >>>>     Tianran
> >      >>>>
> >      >>>>     *From:*Joel Halpern [mailto:[e-mail]
> >     <mailto:[e-mail]>
> >      >>>>     <mailto:[e-mail] <mailto:[e-mail]>>]
> >      >>>>     *Sent:* Monday, September 30, 2024 9:43 AM
> >      >>>>     *To:* Tianran Zhou <[e-mail]
> >     <mailto:[e-mail]>>
> >      >>>>     <mailto:[e-mail]
> >     <mailto:[e-mail]>>
> >      >>>>     *Cc:* mpls <[e-mail] <mailto:[e-mail]>>
> >     <mailto:[e-mail] <mailto:[e-mail]>>
> >      >>>>     *Subject:* Re: [mpls] Re: Working Group Last Call on
> >     draft-ietf-
> >      >>>>     mpls-mna-hdr (2nd WG call)
> >      >>>>
> >      >>>>     So we should hold up the ISD draft for some proposal to
> >      >>>> appear?  The
> >      >>>>     one PSD proposal we have on the table does not require any
> >     changes
> >      >>>>     to the mna-hdr ISD draft.    That seems to request
> >     arbitrary delay
> >      >>>>     from the WG without justification.
> >      >>>>
> >      >>>>     Yours,
> >      >>>>
> >      >>>>     Joel
> >      >>>>
> >      >>>>     On 9/29/2024 9:36 PM, Tianran Zhou wrote:
> >      >>>>
> >      >>>>         So the next step for the WG is to work out the PSD and
> >     see how
> >      >>>>         ISD and PSD can complement and be compatible.
> >      >>>>
> >      >>>>         It’s not the time to finalize draft-ietf-mpls-mna-hdr
> in
> >      >>>> hurry.
> >      >>>>
> >      >>>>         Especially when there is no hands on implementation.
> >      >>>>
> >      >>>>         Tianran
> >      >>>>
> >      >>>>         *From:*Joel Halpern [mailto:[e-mail]
> >     <mailto:[e-mail]>
> >      >>>>         <mailto:[e-mail] <mailto:
> [e-mail]>>]
> >      >>>>         *Sent:* Monday, September 30, 2024 9:06 AM
> >      >>>>         *To:* Tianran Zhou <[e-mail]
> >     <mailto:[e-mail]>>
> >      >>>>         <mailto:[e-mail]
> >     <mailto:[e-mail]>>
> >      >>>>         *Cc:* mpls <[e-mail] <mailto:[e-mail]>>
> >     <mailto:[e-mail] <mailto:[e-mail]>>
> >      >>>>         *Subject:* Re: [mpls] Re: Working Group Last Call on
> >      >>>> draft-ietf-
> >      >>>>         mpls-mna-hdr (2nd WG call)
> >      >>>>
> >      >>>>         If someone wants to put a proposal on the table for
> >     PSD that
> >      >>>>         does not require ISD, they can do so.  And the WG can,
> >     if the
> >      >>>>         process moves that far, consider that solution. But, by
> >      >>>>         definition, if the solution does not use ISD then it
> >     has no
> >      >>>>         impact on advancing the mna-hdr draft solution for
> >     those cases
> >      >>>>         which use ISD.  I still do not see the coupling you are
> >      >>>> asserting.
> >      >>>>
> >      >>>>         In particular, while the requirements permit such a
> >     solution,
> >      >>>>         they do not mandate it.  Since we do not even have a
> >     proposal
> >      >>>>         for how to do PSD without ISD, it seems really
> >     confusing to be
> >      >>>>         objecting to advancing the mna-hdr draft on such a
> basis.
> >      >>>>
> >      >>>>         Yours,
> >      >>>>
> >      >>>>         Joel
> >      >>>>
> >      >>>>         On 9/29/2024 8:43 PM, Tianran Zhou wrote:
> >      >>>>
> >      >>>>             Hi Greg,
> >      >>>>
> >      >>>>             Please see below:
> >      >>>>
> >      >>>>                 5.   Subject to the constraints in these
> >      >>>> requirements, a
> >      >>>>             Network
> >      >>>>
> >      >>>>                      Action solution MAY carry MNA information
> >      >>>> in-stack,
> >      >>>>             post-stack,
> >      >>>>
> >      >>>>                      or both in-stack and post-stack.
> >      >>>>
> >      >>>>                 6.   Solution specifications MUST NOT require
> an
> >      >>>>             implementation to
> >      >>>>
> >      >>>>                      support in-stack ancillary data, unless
> the
> >      >>>>             implementation
> >      >>>>
> >      >>>>                      chooses to support an NA that uses
> in-stack
> >      >>>>             ancillary data.
> >      >>>>
> >      >>>>             Tianran
> >      >>>>
> >      >>>>             *From:*Greg Mirsky [mailto:[e-mail]
> >     <mailto:[e-mail]>
> >      >>>>             <mailto:[e-mail]
> >     <mailto:[e-mail]>>]
> >      >>>>             *Sent:* Monday, September 30, 2024 8:24 AM
> >      >>>>             *To:* Tianran Zhou <[e-mail]
> >     <mailto:[e-mail]>>
> >      >>>>             <mailto:[e-mail]
> >     <mailto:[e-mail]>>
> >      >>>>             *Cc:* Tony Li <[e-mail]
> >     <mailto:[e-mail]>> <mailto:[e-mail]
> >     <mailto:[e-mail]>>;
> >      >>>>             Zafar Ali (zali) <[e-mail]
> >     <mailto:[e-mail]>> <mailto:[e-mail]
> >     <mailto:[e-mail]>>;
> >      >>>>             mpls <[e-mail] <mailto:[e-mail]>>
> >     <mailto:[e-mail] <mailto:[e-mail]>>; mpls-chairs
> >      >>>>             <[e-mail] <mailto:mpls-
> >     [e-mail]>> <mailto:[e-mail] <mailto:mpls-
> >     [e-mail]>>;
> >      >>>> draft-
> >      >>>> [e-mail] <mailto:[e-mail]>
> >     <mailto:draft-ietf-mpls-mna- <mailto:draft-ietf-mpls-mna->
> >      >>>> [e-mail] <mailto:[e-mail]>>
> >      >>>>             *Subject:* Re: [mpls] Re: Working Group Last Call
> on
> >      >>>> draft-
> >      >>>>             ietf-mpls-mna-hdr (2nd WG call)
> >      >>>>
> >      >>>>             Hi Tianran,
> >      >>>>
> >      >>>>             Please point me to the part of RFC 9613 <https://
> >      >>>> datatracker.ietf.org/doc/rfc9613/ <http://
> >     datatracker.ietf.org/doc/rfc9613/>> that supports your
> >      >>>> request.
> >      >>>>
> >      >>>>             Regards,
> >      >>>>
> >      >>>>             Greg
> >      >>>>
> >      >>>>             On Sun, Sep 29, 2024 at 4:44 PM Tianran Zhou
> >      >>>>             <zhoutianran=[e-mail]
> >     <mailto:[e-mail]>
> >      >>>>             <mailto:[e-mail]
> >     <mailto:[e-mail]>>> wrote:
> >      >>>>
> >      >>>>                 The IPR poll for the two document did not hit
> the
> >      >>>> point.
> >      >>>>
> >      >>>>                 The point is how can the MNA mechanism disable
> >     the ISD
> >      >>>>                 and use PSD only.
> >      >>>>
> >      >>>>                 The draft-ietf-mpls-mna-hdr need to resolve
> this.
> >      >>>>
> >      >>>>                 Tianran
> >      >>>>
> >      >>>>                 *From:*Tony Li [mailto:[e-mail]
> >     <mailto:[e-mail]>
> >      >>>>                 <mailto:[e-mail]
> >     <mailto:[e-mail]>>] *On Behalf Of *Tony Li
> >      >>>>                 *Sent:* Monday, September 30, 2024 12:13 AM
> >      >>>>                 *To:* Zafar Ali (zali) <[e-mail]
> >     <mailto:[e-mail]>
> >      >>>>                 <mailto:[e-mail] <mailto:[e-mail]
> >>>
> >      >>>>                 *Cc:* Tianran Zhou <[e-mail]
> >     <mailto:[e-mail]>
> >      >>>>                 <mailto:[e-mail]
> >     <mailto:[e-mail]>>>; Dongjie (Jimmy)
> >      >>>>                 <[e-mail]
> >     <mailto:[e-mail]> <mailto:[e-mail]
> >     <mailto:[e-mail]>>>;
> >      >>>>                 Tarek Saad <[e-mail]
> >     <mailto:[e-mail]>
> >      >>>>                 <mailto:[e-mail]
> >     <mailto:[e-mail]>>>; mpls <[e-mail]
> >     <mailto:[e-mail]>
> >      >>>>                 <mailto:[e-mail]
> >     <mailto:[e-mail]>>>; mpls-chairs <mpls-
> >      >>>> [e-mail] <mailto:[e-mail]> <mailto:mpls-
> >     [e-mail] <mailto:[e-mail]>>>; draft-
> >      >>>> [e-mail] <mailto:[e-mail]>
> >      >>>> <mailto:draft-ietf-mpls-mna- <mailto:draft-ietf-mpls-mna->
> >      >>>> [e-mail] <mailto:[e-mail]>>
> >      >>>>                 *Subject:* Re: Working Group Last Call on
> >     draft-ietf-
> >      >>>>                 mpls-mna-hdr (2nd WG call)
> >      >>>>
> >      >>>>                 Hi Zafar,
> >      >>>>
> >      >>>>                     I am aware of the thread but all we hear
> >     is that
> >      >>>>                     chairs are discussing the responses and
> >     will share
> >      >>>>                     further update, “interest” vs. “consensus”
> >     debate,
> >      >>>>                     the chairs are discussing how to initiate
> >     the PSD
> >      >>>>                     debate, etc. There were 65 emails on the
> >     original
> >      >>>>                     PSD poll. I am not sure why we need another
> >      >>>> round of
> >      >>>>                     debate and what will be the nature of that
> >     debate.
> >      >>>>                     Why not just start WG adoption call and
> gauge
> >      >>>> the WG
> >      >>>>                     “consensus”.
> >      >>>>
> >      >>>>                 That’s exactly what we’re doing. The process
> >     for doing
> >      >>>>                 this begins with an IPR poll.
> >      >>>>
> >      >>>>                 Nic started the IPR poll on draft-mb-mpls-
> >     ioam-dex and
> >      >>>>                 draft-gandhi-mpls-ioam-dex on Sept 3.
> >      >>>>
> >      >>>> https://mailarchive.ietf.org/arch/msg/mpls/ <https://
> >     mailarchive.ietf.org/arch/msg/mpls/>
> >      >>>>                 XU3Ycij6Oq2kGWi14k3eXmpdQvM/ <https://
> >      >>>> mailarchive.ietf.org/arch/msg/mpls/ <http://
> >     mailarchive.ietf.org/arch/msg/mpls/>
> >      >>>>                 XU3Ycij6Oq2kGWi14k3eXmpdQvM/>
> >      >>>>
> >      >>>> https://mailarchive.ietf.org/arch/msg/ <https://
> >     mailarchive.ietf.org/arch/msg/>
> >      >>>>                 mpls/7NmJqyMHDairPxEn7PGxz99KNiI/ <https://
> >      >>>> mailarchive.ietf.org/arch/msg/ <http://mailarchive.ietf.org/
> >     arch/msg/>
> >      >>>>                 mpls/7NmJqyMHDairPxEn7PGxz99KNiI/>
> >      >>>>
> >      >>>>                 Tony
> >      >>>>
> >      >>>> _______________________________________________
> >      >>>>                 mpls mailing list -- [e-mail]
> >     <mailto:[e-mail]>
> >      >>>> <mailto:[e-mail] <mailto:[e-mail]>>
> >      >>>>                 To unsubscribe send an email to mpls-
> >     [e-mail] <mailto:[e-mail]>
> >      >>>>                 <mailto:[e-mail] <mailto:mpls-
> >     [e-mail]>>
> >      >>>>
> >      >>>>             _______________________________________________
> >      >>>>
> >      >>>>             mpls mailing list [e-mail] <mailto:--
> >     [e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>
> >      >>>>
> >      >>>>             To unsubscribe send an email [e-mail]
> >     <mailto:[e-mail]>
> >      >>>> <mailto:[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] <mailto:[e-mail]>
> >     To unsubscribe send an email to [e-mail] <mailto:mpls-
> >     [e-mail]>
> >     _______________________________________________
> >     mpls mailing list -- [e-mail] <mailto:[e-mail]>
> >     To unsubscribe send an email to [e-mail] <mailto:mpls-
> >     [e-mail]>
> >     _______________________________________________
> >     mpls mailing list -- [e-mail] <mailto:[e-mail]>
> >     To unsubscribe send an email to [e-mail] <mailto:mpls-
> >     [e-mail]>
> >
>
> --
> Loa Andersson
> Senior MPLS Expert
> Bronze Dragon Consulting
> [e-mail]
> [e-mail]
>
>