[mpls] Re: Adoption poll on draft-li-mpls-mna-nrp-selector

[Adrian Farrel <[e-mail]>]

Hi Jie,

 

Thanks for sharing your thoughts about this.

 

You have counted the "votes" for and against, but as you know, we don't
vote. Instead, we listen to opinions and attempt to address the issues
raised. 

 

You also, I think, seem to be treating this as though it was a last call.
But, of course, adoption is just the start of the working group's effort,
and we should expect a lot of ongoing discussion with the ability for
operators to talk about the functions they want to see enabled as well as
the pros and cons of how the different solutions impact on the network.

 

It should be noted that adoption by a working group does not imply ultimate
publication as an RFC (in fact, the history of the MPLS working group is
full of drafts that have been abandoned after adoption), and certainly does
not mean that the content or approach will remain unchanged through the life
of the draft. So, for example, your suggestion that there is a requirement
to carry an indication of a strict-match requirement could be worked on by
the working group.

 

My email closing the adoption poll attempts to look at the objections raised
and to indicate why these are either not a block to adoption, or why they
are not demonstrative of objection to adoption. I won't revisit those points
here - you can re-read the original email.

 

You commented on two specific points:

 

A.	NRP ID length

This is an issue that can be discussed further on an adopted document. The
fact that there is debate about this point suggests that this could be a
starting point for further work. There was some discussion of the S-NSSAI
defined by 3gpp, but (as co-author of RFC 9543) I'd like to point out that
the S-NSSAI identifies a slice not an NRP. This issue does not block
adoption, but will form part of the working group discussion.

 

[Jie] To me the WG needs to discuss how many different NRP ID length it
plans to support. If it is more than 2, then maybe a field with variable
length needs to be considered. 

 

That sounds like the beginning of a working group discussion. I suspect that
it may be lost deep within this thread. You might achieve a more expedient
debate by starting a new thread specific to this issue.

 

B.	ISD versus PSD

The chairs would be glad to see further work on
draft-li-mpls-enhanced-vpn-vtn-id and once/if draft-jags-mpls-ps-mna-hdr and
the authors think their draft is ready, then a request can be made for
adoption. There is, however, no need to fold the two drafts together. The WG
can debate whether it is desirable to synchronize the encodings as normal WG
work. But, unlike the IOAM case, there is no demonstrated need for the two
drafts to progress in lock-step and parsing of ISD and PSD is necessarily
different. ISD and PSD are in any case demonstrably different solutions.
This issue does not block adoption, but will form part of the working group
discussion.

 

[Jie] As a co-author of draft-li-mpls-enhanced-vpn-vtn-id, we think that
draft is ready and would like to request for WG adoption. To me this case is
similar to the IOAM one, if we want to support NRPs at different scale or
with further flexibility, the PSD based approach is needed. And if both
approaches are documented, some coordination between them would be needed.

 

Noted and I have updated the wiki at
https://wiki.ietf.org/en/group/mpls/doc-status to show that you have
requested adoption, and I sent mail to the list to set out the next steps.

 

Thanks,

Adrian

 

From: Dongjie (Jimmy) <[e-mail]> 
Sent: 14 May 2025 01:22
To: [e-mail]; 'mpls' <[e-mail]>
Subject: RE: [mpls] Adoption poll on draft-li-mpls-mna-nrp-selector

 

Hi Adrian, 

 

Thanks for your summary of the adoption call discussion. Please find some
further comments inline:

 

 

From: Adrian Farrel <[e-mail]> 
Sent: Tuesday, May 13, 2025 11:41 PM
To: 'mpls' <[e-mail]>
Subject: [mpls] Adoption poll on draft-li-mpls-mna-nrp-selector

 

Hi all,

 

The adoption poll for draft-li-mpls-mna-nrp-selector closed on 25th April,
just a few days before I became chair.

I have taken over as the document shepherd for the draft, and I have gone
back to look at the comments received during the period of the poll.

 

There was considerable support shown, but also some concerns raised as
below. This email is necessarily long because of the heated debate and the
need to carefully address all of the issues some of which are as much
process-related as they are technical.

 

[Jie] With my counting, there are 6 supports for the adoption, among which 2
are from the document authors, while there are 6 non-supports. To me this is
a relatively small group of the MPLS participants. Do you think more
feedback from the community (especially from the operators/customers who
want to use this technique) is needed?

 

New comments and concerns were received after the end of the adoption poll.
Normally, late comments are considered useful when they are review comments
(such as editorials, or pointers to specific technical issues), but are
thought to be questionable when they are simply late statements of support
or non-support. In this case, the late comments seem to overlap with other
comments made during the adoption poll and so may be considered along with
those comments in the text below.

 

Tianran expressed his opposition as follows:

> 1. I don't think it's necessary to apply nrp selector in mna. There are

>    easy way to do the same function.

> 2. The encoding designed is not optimal. Not easy to implement.

> 3. I don't like the IPRs applied to this draft. We have other choice.

 

Jie objected as follows:

> The current draft proposes to allocate 3 opcodes for the NRP selector,
which

> is a waste of the opcode resource. This would also increase the complexity
in

> interoperability. 

> 

> There is another draft on using PSD to carry NRP selector:

>
https://datatracker.ietf.org/doc/html/draft-li-mpls-enhanced-vpn-vtn-id-05.

> Similar to the adoption call on MNA based IOAM, both ISD and PSD based

> approach for NRP need to be called for adoption together, and the WG needs

> to have some discussion on whether ISD or PSD or both should be used for

> carrying NRP related information.

 

Zafar objected as follows:

> 1a. Why there are multiple encoding for NRP ID needed - It should be
simply

>        limited to one encoding (this is to be implemented in HW and
encoding

>        simplicity is a key). 

> .         13-bit NRP Selector (NRPS13) Action 

> .         20-bit NRP Selector (NRPS20) Action 

> .         20-bit Entropy and NRP Selector (ENRPS20) Action 

> 

> 1b. Why 13-bit NRP ID is not sufficient?

> 

> 2a. This is an "application" draft that focuses only on the ISD option. I
have

>       "serious" concerns about encoding "segregation/ differences" in
encoding

>        application data in ISD vs. PSD. As an implementor, I would like to
see

>        encoding synergy between the two options. In this case, there is
another

>        draft that defines NRP encoding for the PSD option

>
(https://datatracker.ietf.org/doc/draft-li-mpls-enhanced-vpn-vtn-id/) I

>        would like to see the two documents merged and processed together
for

>        NRP (and for NMA applications in general). 

> 

> 2b. One issue related to 2a is that the PSD document status is not clear
to

>        me (as far as I know, it is still an individual draft. I think the
WG should

>        work on adopting and working on the PSD document. This way the WG

>        can work on the applications of MNA in a coherent manner. 

> 

> 3. The draft should list other options for encoding NRP data with 

>      comparison/guidance for implementor and operators (In particular, 

>      MPLS label in TEAS draft, PSD/ ISD, and how these options they can

>      work or cannot work together, etc.). 

> 

> 4. I am concerned/ not comfortable about the IPR statement "Reasonable 

>      and Non-Discriminatory License to All Implementers with Possible

>      Royalty/Fee". 

> 

> Overall, the document is not ready for adoption.

 

Haoyu did not express an opinion on adoption, but said:

> For interoperability, I prefer to only support PSD-based solution 

> to avoid the limitation on the ID size.

> If some think ISD is necessary, then the draft should take the

> IOAM use case as an example and combine them as a coherent

> solution to avoid duplicated efforts and potential incompatibility.

 

 

This all leads me to the following discussion threads:

 

A.	NRP ID length

This is an issue that can be discussed further on an adopted document. The
fact that there is debate about this point suggests that this could be a
starting point for further work. There was some discussion of the S-NSSAI
defined by 3gpp, but (as co-author of RFC 9543) I'd like to point out that
the S-NSSAI identifies a slice not an NRP. This issue does not block
adoption, but will form part of the working group discussion.

 

[Jie] To me the WG needs to discuss how many different NRP ID length it
plans to support. If it is more than 2, then maybe a field with variable
length needs to be considered. 

 

B.	ISD versus PSD

The chairs would be glad to see further work on
draft-li-mpls-enhanced-vpn-vtn-id and once/if draft-jags-mpls-ps-mna-hdr and
the authors think their draft is ready, then a request can be made for
adoption. There is, however, no need to fold the two drafts together. The WG
can debate whether it is desirable to synchronize the encodings as normal WG
work. But, unlike the IOAM case, there is no demonstrated need for the two
drafts to progress in lock-step and parsing of ISD and PSD is necessarily
different. ISD and PSD are in any case demonstrably different solutions.
This issue does not block adoption, but will form part of the working group
discussion.

 

[Jie] As a co-author of draft-li-mpls-enhanced-vpn-vtn-id, we think that
draft is ready and would like to request for WG adoption. To me this case is
similar to the IOAM one, if we want to support NRPs at different scale or
with further flexibility, the PSD based approach is needed. And if both
approaches are documented, some coordination between them would be needed.

 

Best regards,

Jie

 

C.	ISD is not the right way to do this

It is perfectly valid to not like a technical approach and to consider it
sub-optimal or a poor choice. If there is a good body of people wanting to
work on such a solution then the normal approach is to let them carry on
with that work in the knowledge that poor ideas ultimately fail the
implementation/deployment test. While this may result in some waste of WG
time, no one is obliged to participate in reviewing or otherwise assisting
the development of the draft, and so the wasted time is mainly with the
authors and supporters. Similarly, no one is required to implement or deploy
ideas they do not like. If the level of dislike arises from explicit
technical faults (of the order of, "This will not work in the following
deployments or scenarios") then, of course, this is a different issue and
will need to be resolved by the working group.

 

D.	Overlap with other I-Ds

One issue raised was that there are other documents handling how to carry
the NRP ID in MPLS. Documents mentioned were:

 

*	draft-ietf-teas-ns-ip-mpls

As Pavan, co-chair of TEAS, said, this draft discusses the notion of
carrying an NRP selector (marking) in a packet's network layer header to map
the packet to the associated NRP and provide the corresponding forwarding
treatment to the packet. One of the options draft-ietf-teas-ns-ip-mpls
discusses for carrying this marking is using a dedicated identifier called
NRP Selector ID.  The latest version (-05) of draft-ietf-teas-ns-ip-mpls
captures the conclusions drawn from a long, drawn-out discussion (which
followed an interim meeting on the topic) on NRP Selector ID). The TEAS WG
is not responsible for defining the actual data-plane-specific encoding for
the NRP Selector ID. For the MPLS data-plane, the onus for defining this
lies with the MPLS WG (for obvious reasons).

My review of this draft suggests that work is needed to remove specific
examples of MPLS encoding of NRPs. I will talk to Pavan and the document
authors about making that happen. But that does not block our draft.

 

*	draft-li-mpls-enhanced-vpn-vtn-id

This draft advocates for a PSD solution in contrast to the ISD solution in
draft-li-mpls-mna-nrp-selector. As discussed in point B (above) there is no
requirement to progress the solutions together or merge them, but if this
draft can be readied for adoption and there is support, the two documents
can be worked on in parallel in the working group.

 

*	draft-ietf-6man-enhanced-vpn-vtn-id

This draft was only mentioned in passing. No suggestion was made to tie its
progress to the work in the MPLS WG.

 

*	draft-ietf-spring-sr-for-enhanced-vpn

This I-D expired recently and was not mentioned by anyone during the
discussion.

     

E.	IPR licensing terms

Concern was expressed about the licensing terms "Reasonable and
Non-Discriminatory License to All Implementers with Possible Royalty/Fee"
contained in one of the IPR disclosures. I note that similar terms are found
in an IPR disclosure against draft-li-mpls-enhanced-vpn-vtn-id, so anyone
objecting on the grounds of IPR license might be viewed as inconsistent if
they oppose one document, but support progress on the other. 

In general, participants are free to object to progressing a document on the
grounds of unacceptable licensing terms. The usual approach here, is to
accompany the objection with a proposal of how to solve the problem without
being subject to the IPR in question. No such proposal has been forthcoming.

In view of this, the chairs must look for rough consensus. In this case,
only one person objected on the grounds of the licensing terms, and my
judgement is that the consensus in the working group is that this is not a
reason to block adoption.

 

F.	Comparison between approaches

A suggestion was made that this draft should call out other means of
carrying the NRP ID (in MPLS or in all protocols?). It is not usually a
requirement for drafts to catalogue and compare with all other solutions
especially those not yet standardised. If, however, the working group
decides that it wants to do this (and people provide text!) there is no
reason for this not to happen once the I-D has been adopted and the WG has
control of the contents.

 

Therefore, my judgement is that there sufficient support for this document
to be adopted by the MPLS WG and no blocking issues.

I ask the authors to report the draft as draft-ietf-mpls-mna-nrp-selector-00
taking care to make no changes except to the name and date of the document.
Please also take care to set the "replaces" information correctly.

 

I hope that the working group will move forward in the spirit of
collegiality to refine this work taking into account the many points of
discussion. I will remind you all that helping others advance their work is
often repaid when you want to advance your own work, and that the best way
to change and improve a draft is to suggest text.

 

Many thanks,

Adrian