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

[Loa Andersson <[e-mail]>]

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]