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

[Greg Mirsky <[e-mail]>]

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]> 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 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.

>
> 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? It is optional and, in my
opinion, is no different from any other MPLS extensions that use SPL.

> >
> > 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/ ,
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]] *代表 *Tarek Saad
> > *发送时间:*2024年9月24日21:25
> > *收件人:*[e-mail]
> > *抄送:*MPLS Working Chairs <[e-mail]>; draft-ietf-mpls-mna-
> > [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/
> >  >. 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]>).
> >
> > 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-
> > mpls-mna-hdr <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]
> > 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]
>