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

[Loa Andersson <[e-mail]>]

Greg,

It did not address my concerns, and made me more confused :(.

Your figure looks like this:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |1|         Namespace-ID          |    Resv   |S|     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |1|            IOAM-Trace-Type-MNA            |S|O|R| Ext-Flags |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     Flow ID MNA (Optional)                    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                 Sequence Number MNA (Optional)                |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          Figure 1: IOAM Direct Export Option Type Format in an MPLS
                           Network Action Framework

First, I suppose you mean "Network" not "Framework" in the figure naming?

Second, the "Flow ID MNA" and the "Sequence Number MNA" are in-stack, 
and is Format D LSEs.

There are good reasons why we defined leading 1's to protect against 
mistaking the Format D LSE for a bSPL. This is critical. You also need 
the s-bit "sakrosant", i.e. not used.

You agree to that:

    *  Flow ID MNA is an optional four-octet field.  The semantics of the
       Flow ID MNA field is as of the Flow ID field defined in
       Section 3.2 of [RFC9326].  The most significant bit MUST be set to
       1.  Bit 23 MUST be set according to the definition of Bottom of
       Stack field in [RFC3032].

    *  Sequence Number MNA is an optional four-octet field.  The
       semantics of the Sequence Number MNA field is as of the Sequence
       Number field defined in Section 3.2 of [RFC9326].  The most
       significant bit MUST be set to 1.  Bit 23 MUST be set according to
       the definition of Bottom of Stack field in [RFC3032].

But you give us a very confusing figure, where it is is implied that the 
most significant bit and the s-bit are part of the "Flow ID MNA" and the 
"Sequence Number MNA" and part of a 32 bit field the controls the 
functionality specified by the optional field.

They are not, the leading bit and the s-bit are allocated for other 
purposes.  You only have a 30-bit field.

The statement that these two fields in your draft are semantically 
identical to the field in RFC 9326 are simply not true.

As for the statement:

   RFC 9326 defined the use of two one-bit flags. The draft allows
   for additional extensions and is future-proof.

This also not true. RFC 9326 has specified 8 flags, and assigned 
semantics to two of them.

draft-mb-mpls-ioam-dex has specified 6 flags and assigned semantics to 
two of them. This is not identical, nor compatible with the RFC 9326.

Nor are they future-proof, when RFC 9326 assigns the the seventh flag, 
you will have to change draft-mb-mpls-ioam-dex, if you want to be 
functionally identical.

I really think it is time to drop draft-mb-mpls-ioam-dex!

/Loa



Den 21/10/2024 kl. 16:59, skrev Greg Mirsky:
> 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] 
> <mailto:[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]>
>      > <mailto:[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/ <https://mailarchive.ietf.org/arch/msg/mpls/>
>      > NSEOwfGZV766pzsWBE_kPZNKOJM/ <https://mailarchive.ietf.org/arch/
>     msg/ <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]>>
>      >      > [mailto:[e-mail]
>     <mailto:[e-mail]>
>      >     <mailto:[e-mail]
>     <mailto:[e-mail]>>] *代表 *Tarek Saad
>      >      > *发送时间:*2024年9月24日21:25
>      >      > *收件人:*[e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>
>      >      > *抄送:*MPLS Working Chairs <[e-mail]
>     <mailto:[e-mail]> <mailto:mpls- <mailto:mpls->
>      > [e-mail] <mailto:[e-mail]>>>; draft-ietf-mpls-mna-
>      >      > [e-mail] <mailto:[e-mail]> <mailto:[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- <https://datatracker.ietf.org/doc/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]>>
>      >      > <mailto:[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- <https://datatracker.ietf.org/ipr/search/?
>     submit=draft&id=draft->
>      >     ietf- <https://datatracker.ietf.org/ipr/search/ <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/> <https://
>      > datatracker.ietf.org/ipr/search/ <http://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]>
>     <mailto:[e-mail] <mailto:[e-mail]>>
>      >      > To unsubscribe send an email to [e-mail]
>     <mailto:[e-mail]> <mailto:mpls- <mailto:mpls->
>      > [e-mail] <mailto:[e-mail]>>
>      >
>      >     --
>      >     Loa Andersson
>      >     Senior MPLS Expert
>      >     Bronze Dragon Consulting
>      > [e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>
>      > [e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>
>      >
>      >     _______________________________________________
>      >     mpls mailing list -- [e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>
>      >     To unsubscribe send an email to [e-mail]
>     <mailto:[e-mail]> <mailto:mpls- <mailto:mpls->
>      > [e-mail] <mailto:[e-mail]>>
>      >
> 
>     -- 
>     Loa Andersson
>     Senior MPLS Expert
>     Bronze Dragon Consulting
>     [e-mail] <mailto:[e-mail]>
>     [e-mail] <mailto:[e-mail]>
> 

-- 
Loa Andersson
Senior MPLS Expert
Bronze Dragon Consulting
[e-mail]
[e-mail]