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

[Greg Mirsky <[e-mail]>]

Hi Loa,
thank you for your detailed response. In regard to you note (top-posting):

My concern with draft-mb-mpls-ioam-dex is something else.

Fabian says:

    The DEX option in this draft is not fully compliant with RFC9326,
    e.g., the 32-bit optional sequence number and flow id field is mapped
    to a 30-bit field in this draft. Therefore, the ISD version is a more
    restricted but also more lightweight implementation of DEX compared
    to PSD.

I believe that compatibility with RFC 9326 are a desired feature.
GIM>> The new version of the draft-mb-mpls-ioam-dex defines these fields as
four-octet fields. I hope that addresses your concern.

There is also another in-compatibility.

RFC 9326 have eight extension flags, while draf-mb-mpls-ioam-dex only
have six.
GIM>> RFC 9326 defined the use of two one-bit flags. The draft allows for
additional extensions and is future-proof.

Regards,
Greg

On Thu, Oct 17, 2024 at 12:53 PM Loa Andersson <[e-mail]> wrote:

> Greg,
>
> Sorry for late reply, you know I have been busy.
>
> Den 13/10/2024 kl. 20:08, skrev Greg Mirsky:
> > Hi Loa,
> > I read your thoughts on the discussion with great interest, thank you
> > for sharing. I've added my notes below tagged GIM>>.
> >
> > Regards,
> > Greg
> >
> > On Sat, Oct 12, 2024 at 11:49 AM Loa Andersson <[e-mail]
> > <mailto:[e-mail]>> wrote:
> >
> >     Aijun,
> >
> >     Sorry for the late reply. I have been otherwise occupied.
> >
> >     See inline please.
> >
> >     Den 29/09/2024 kl. 04:55, skrev Aijun Wang:
> >      > Hi, All:
> >      >
> >      > After reviewing the discussions on this topic on the list, my
> >      > suggestions for the WGLC of the mentioned document are the
> >     followings:
> >
> >     We are very much on the same page, though I have a couple small
> >     comments.
> >
> >      >
> >      > 1)Because such approach is one major update to the traditional
> MPLS
> >      > functions, before moving this document forward, it is better to
> >     make the
> >      > design more robust and challengeable with the help of different
> >      > implementations
> >
> >     I agree that it is important to take the input we can get from
> >     implementations. I'm quite surprised by the perceived resistance for
> >     the
> >     WG chair that has spoken up on this. Taking the lessons we can from
> >     existing implementations has been there for MPLS Standard Track RFCs,
> >     since the start.
> >
> > GIM>> I am surprised that you discard all the great work and
> > valuable information the group received from Michael Menth and
> > Fabiam Ihle on their outstanding work with implementing MNA on the P4
> > platform. As I understand it, they don't find any severe obstacles to
> > implementing the MNA ISD solution based on the current version of the
> draft.
>
> I think this is a misunderstanding, I'm talking about input from
> existing implementation, that incudes the work done and reported by
> Michael and Fabian at University of Tübingen.
>
> I reread my mail several of times and does still understand why I'm
> being accused of discarding "all the great work and valuable information
> the group received from Michael Menth and Fabiam Ihle".
>
> It is simply not true.
>
> I very much appreciate their work.
>
> As I read the mails from Fabian he says that both draft-mb-mpls-ioam-dex
> and draft-gandhi-mpls-mna-ioam-dex are implementable on the P4
> architecture.
>
> Obviously for some MPLS participants the P4 architecture leaves some
> questions, but since I'm not much of a HW guy I don't care much.
>
> Both are implementable.
>
> My concern with draft-mb-mpls-ioam-dex is something else.
>
> Fabian says:
>
>     The DEX option in this draft is not fully compliant with RFC9326,
>     e.g., the 32-bit optional sequence number and flow id field is mapped
>     to a 30-bit field in this draft. Therefore, the ISD version is a more
>     restricted but also more lightweight implementation of DEX compared
>     to PSD.
>
> I believe that compatibility with RFC 9326 are a desired feature.
>
> There is also another in-compatibility.
>
> RFC 9326 have eight extension flags, while draf-mb-mpls-ioam-dex only
> have six.
>
> On that level draft-gandhi-mpls-mna-ioam-dex id compatible with RFC 9326.
>
> So in a situation where we have on compatible and one in-compatible
> proposal, I think we should chose the the compatible one.
>
> > I agree that input from implementations is important but, as I
> > understand it, the MPLS WG never before required that to progress any
> > document. I believe that if the WG is transforming into an MPLS
> > maintenance group, then adopting a more protective charter which would
> > require validation by an implementation seems reasonable to me.
> > Otherwise, I cannot find any practical reason in further stalling the
> > progress of the MNA ISD document.
>
> This is misleading.
>
> It is correct that we never have REQUIRED implementations to progress
> documents.
>
> I don't believe that we should do so now!
>
> I also believe that if we are changing the MPLS data plane, this in
> itself is a very good reason to look at the feedback we get from for
> example University of Tübingen.
> >
> >
> >     However we have never wanted to make it a formal criteria, since we
> >     very
> >     quickly learnt that vendors are extremely reluctant to respond to
> >     implementation polls-
> >
> > GIM>> So how is the case on MNA different?
>
> I think I spent enough time trying to explain that is not :(.
>
> It is optional and, in my
> > opinion, is no different from any other MPLS extensions that use SPL.
>
> We have a long history of considering reports on implementations. The
> problem has been (still is) that very few implementers have agreed to
> report.
>
> In fact the Shepherd Write-Up template include a question on
> implementations, the chair used to send out a mail asking for
> information to be able to respond to this question.
>
> /Loa
> >
> >      >
> >      > 2)Based on the poll responses about "IOAM and PSD", the PSD based
> >      > solution is more suitable for the IOAM related scenarios. It is
> >     better
> >      > to define and assign the "R" bit in LSE format B as "P" bit for
> PSD
> >      > based solution.
> >
> >     I agree with this sentiment, though I think that there are more to
> this
> >     issue.
> >
> >     I'm not sure that we only have two ways of indicating the presence of
> >     PSD in an MPLS packet, I believe we should step back and look at
> >     this again.
> >
> >     There is one more thing, I've said several times. The P-flag and the
> >     PSD
> >     Present Op Code and the indicating the offset are by definition ISD,
> >     and
> >     should go in the ISD draft.
> >
> > GIM>> IETF, and MPLS WG in particular, have been extending protocols by
> > repurposing Reserved fields. Also, assigning new code points is a well-
> > known technique to extend the functionality. And extending ISD MNA using
> > any or both of these methods is no different from all previous
> > extensions done before. There's no apparent need to delay the progress
> > of the draft-ietf-mpls-mna-hdr for any future extension of MNA.
> >
> >
> >     On the people supporting progressing the draft-ietf-mpls-mna-hdr, say
> >     that already today we know how the presence of PSD should be
> specified,
> >     so based on their arguments I see no  reason to wait.
> >
> >      >
> >      > 3)It's time to make the WG adopt call for the PSD proposal. After
> >      > careful reviewing of the PSD by the WG, the current ISD draft can
> be
> >      > refined, to make the output of the community more sustainable.
> >
> >     I agree, I hope this will happen as part of the long awaited WGAP for
> >     draft-jags-mpls-psmna-hdr. It is now more than 3 months since Jags
> >     asked
> >     for the WGAP for the draft. The only thing that have happened is that
> >     one of the chairs (hat off) has informed the WG that he is "opposed"
> to
> >     running the WGAP, regardless of that "the poll" did show that there
> >     is a
> >     enough people wanting and prepared to work on the PSD solution.
> >
> > GIM>> As I've noted in https://mailarchive.ietf.org/arch/msg/mpls/
> > NSEOwfGZV766pzsWBE_kPZNKOJM/ <https://mailarchive.ietf.org/arch/msg/
> > mpls/NSEOwfGZV766pzsWBE_kPZNKOJM/> , there is no any dependency in MNA
> > HDR or MNA ISD from how internals of MNA PSD are defined. As we've
> > discussed, MNA HDR and ISD MNA are extendable and fully capable of
> > supporting not only new NAs, but PSD MNA as well. Can you demonstrate
> > that that is not the case?
> >
> >      >
> >      > 4)It is no hurry to finalize the MNA related documents. There is
> the
> >      > equivalent IPv6 based solutions, which is more easier to span the
> >      > different domains(all controlled by one service provider). Is
> >     there any
> >      > analysis for the pros and cons of these two solutions(MNA vs IPv6
> >     based
> >      > solutions)?
> >
> >     I think that the IPv6 based solutions are more or less of equivalent
> >     complexity as compared to MPLS solutions.
> >
> > GIM>> I believe that comparison of IPv6-based solutions, perhaps you
> > meant IPv6 Extension Headers, and MPLS Network Action is like comparing
> > apples and oranges. Besides, MPLS, by its definition, is applicable in a
> > single domain controlled by one network operator. Hence, MNA, unlike
> > IPv6 EH, is limited to a single domain.
> >
> >
> >     That said, you are right, there is no need to rush any solution
> through
> >     a WGLC and to a publication request, especially since the solutions
> are
> >     not yet hammered out.
> >
> > GIM>> I find that position that combines the requirement of HW-based
> > implementation with further delaying publication, self-contradicting and
> > not constructive.
> >
> >
> >     /Loa
> >
> >     PS
> >
> >     I'm aware of the the 2nd WGLC is closed, but I felt that I owed
> Aijun a
> >     response.
> >      >
> >      > Best Regards
> >      >
> >      > Aijun Wang
> >      >
> >      > China Telecom
> >      >
> >      > *发件人:*[e-mail]
> >     <mailto:[e-mail]>
> >      > [mailto:[e-mail]
> >     <mailto:[e-mail]>] *代表 *Tarek Saad
> >      > *发送时间:*2024年9月24日21:25
> >      > *收件人:*[e-mail] <mailto:[e-mail]>
> >      > *抄送:*MPLS Working Chairs <[e-mail] <mailto:mpls-
> >     [e-mail]>>; draft-ietf-mpls-mna-
> >      > [e-mail] <mailto:[e-mail]>
> >      > *主题:*[mpls] Working Group Last Call on draft-ietf-mpls-mna-hdr
> >     (2nd WG
> >      > call)
> >      >
> >      > Dear WG,
> >      >
> >      > This email starts a two-week Working Group last call for
> draft-ietf-
> >      > mpls-mna-hdr <https://datatracker.ietf.org/doc/draft-ietf-mpls-
> >     mna-hdr/ <https://datatracker.ietf.org/doc/draft-ietf-mpls-mna-hdr/>
> >      >  >. This is the 2^nd WG last call for this document.
> >      >
> >      > Please indicate your support or concern for this draft. If you are
> >      > opposed to the progression of the draft to RFC, please articulate
> >     your
> >      > concern. If you support it, please indicate that you have read the
> >      > latest version, and it is ready for publication in your opinion.
> As
> >      > always, review comments and nits are most welcome.
> >      >
> >      > Please send your comments to the mpls WG mailing list
> >     ([e-mail] <mailto:[e-mail]>
> >      > <mailto:[e-mail] <mailto:[e-mail]>>).
> >      >
> >      > If necessary, comments may be sent unidirectional to the WG
> chairs.
> >      >
> >      > Note, currently there are 5 IPR disclosures against this document
> at
> >      > https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-
> >     ietf- <https://datatracker.ietf.org/ipr/search/?
> >     submit=draft&id=draft-ietf->
> >      > mpls-mna-hdr <https://datatracker.ietf.org/ipr/search/ <https://
> >     datatracker.ietf.org/ipr/search/>?
> >      > submit=draft&id=draft-ietf-mpls-mna-hdr>
> >      >
> >      > This poll runs until October 8, 2024.
> >      >
> >      > Thank you,
> >      >
> >      > Tarek (for the MPLS WG co-chairs)
> >      >
> >      >
> >      > _______________________________________________
> >      > 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] <mailto:[e-mail]>
> >     [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]>
> >
>
> --
> Loa Andersson
> Senior MPLS Expert
> Bronze Dragon Consulting
> [e-mail]
> [e-mail]
>
>