[mpls] Re: Working Group Adoption Poll for draft-li-mpls-mna-nrp-selector

["Zafar Ali (zali)" <[e-mail]>]

Hi Tony

By “signaling”, in this context, I meant carrying NRD-ID in the packet.
Part of the HW processing is about reading the NRP-ID from packet (which can be carried in PSD, ISD).
Part of it setting up the internals (per hop behavior) to respect the “requested/ signaled” NRP-ID.
My point is to have synergy between the PSD and ISD carriers.

Thanks

Regards … Zafar

From: Tony Li <[e-mail]> on behalf of Tony Li <[e-mail]>
Date: Thursday, April 17, 2025 at 1:48 AM
To: Zafar Ali (zali) <[e-mail]>
Cc: Greg Mirsky <[e-mail]>, Joel Halpern Direct <[e-mail]>, mpls <[e-mail]>
Subject: Re: [mpls] Working Group Adoption Poll for draft-li-mpls-mna-nrp-selector
[WG chair hat: off]

Hi Zafar,

Typically, ’signaling’ refers to control plane mechanisms, not forwarding plane/data plane, which is obviously where this draft applies.

If folks feel that you would like the data plane formats to be the same, they are more than welcome to change the PSD format to match.  I don’t recommend it, but you’re certainly free to do so.  As you know, the ISD formats are somewhat constrained.

As to the IPR statement, I’m not happy about it either, but as you know, there is absolutely nothing that the authors can do about it. As has been noted here many times, anyone can place an IPR statement on any document.The WG is free to consider the existence and terms of IPR in its deliberations but cannot discuss the applicability of any particular IPR.

Tony


On Apr 16, 2025, at 9:37 PM, Zafar Ali (zali) - zali=40cisco.com at dmarc.ietf.org <[e-mail]> wrote:

Hi Greg, Tony,

The draft is a “signaling” mechanism for NRP ID using ISD option.
Another draft “draft-li-mpls-enhanced-vpn-vtn-id” is also a “signaling” mechanism for NRP ID using PSD option.
Given that the implementation of the NRP ID processing needs to be done in hardware, I would like to keep it independent of the “signaling mechanism” and consistent across the “signaling mechanism”.

In the context of this adoption call:

  *   I am also concerned/ not comfortable about the IPR statement “Reasonable and Non-Discriminatory License to All Implementers with Possible Royalty/Fee”.

Thanks

Regards … Zafar

From: Greg Mirsky <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, April 16, 2025 at 1:37 AM
To: Zafar Ali (zali) <[e-mail]<mailto:[e-mail]>>
Cc: Joel Halpern <[e-mail]<mailto:[e-mail]>>, mpls <[e-mail]<mailto:[e-mail]>>
Subject: Re: [mpls] Re: Working Group Adoption Poll for draft-li-mpls-mna-nrp-selector
Hi Zafar,
I cannot find any technical dependency of the ISD MNA solution on a PSD solution. Can you kindly point me to anything I am missing here?

Regards,
Greg

On Tue, Apr 15, 2025, 22:21 Zafar Ali (zali) <zali=[e-mail]<mailto:[e-mail]>> wrote:
Hi Joel

For the reason I provided in the earlier email, I would like to see ISD and PSD work (applications, base) to progress in lock steps.

Thanks

Regards … Zafar

From: Joel Halpern <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, April 16, 2025 at 12:49 AM
To: Zafar Ali (zali) <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: Re: [mpls] Re: Working Group Adoption Poll for draft-li-mpls-mna-nrp-selector

Is your ask that we do what we did with the IOAM drafts, and adopt both the ISD and PSD drafts in parallel?  If the chairs want to do that, I have no problem with it.

If you ask is that this draft include an analysis of other people's proposals, I think that would tend to be unfair both to this draft and to those other proposals.  For example, I would not want to get the working group tangled up in arguing up with of ISD and PSD is best for which cases.  I could easily see how such an argument could force me to oppose the PSD draft, which I would prefer not to do.

Yours,

Joel
On 4/16/2025 12:44 AM, Zafar Ali (zali) wrote:
Hi Joel

Many thanks for your follow-up.
I agree with you that the WG can discuss and close on the encoding size.
However, in this case concern 1 has a tight association with concerns 2 and 3.

Thanks

Regards … Zafar

From: Joel Halpern <[e-mail]><mailto:[e-mail]>
Date: Tuesday, April 15, 2025 at 11:43 PM
To: Zafar Ali (zali) <[e-mail]><mailto:[e-mail]>, [e-mail]<mailto:[e-mail]> <[e-mail]><mailto:[e-mail]>
Subject: Re: [mpls] Re: Working Group Adoption Poll for draft-li-mpls-mna-nrp-selector

Commenting only on your first concern, it seems to me this ought not be blocking for adoption.  It would indeed be blocking for WG last call.   I presume that during the WG work on the draft we will discuss the various size choices, the use cases that drive them, and which one or ones we want to retain.  I would not be surprised if 13 bits turned out to be sufficient, but that is a detail in the overall approach.

Yours,

Joel
On 4/15/2025 11:37 PM, Zafar Ali (zali) wrote:
Dear chairs and the WG,

I oppose to the WG adoption of the draft based on the following technical/ process concerns:


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.

Thanks

Regards … Zafar

From: [e-mail]<mailto:[e-mail]> <[e-mail]><mailto:[e-mail]>
Date: Tuesday, April 15, 2025 at 4:31 AM
To: [e-mail]<mailto:[e-mail]> <[e-mail]><mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]><mailto:[e-mail]>, [e-mail]<mailto:[e-mail]> <[e-mail]><mailto:[e-mail]>
Subject: [mpls] Working Group Adoption Poll for draft-li-mpls-mna-nrp-selector
Dear WG,

This email starts a two-week poll on adopting draft-li-mpls-mna-nrp-selector as a MPLS working group document.

Please send your comments (support/not support) to the MPLS working group mailing list ([e-mail]<mailto:[e-mail]>).
Please give a technical motivation for your support/not support, especially if you think that the document
should not be adopted as a working group document.

There are three IPR disclosures against this document.

https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-li-mpls-mna-nrp-selector

All the authors/contributors have stated on the MPLS WG mailing list that they are unaware of any
undisclosed IPR that relates to this document.

This working group adoption poll ends April 29th, 2025.

Regards,

Nic (as MPLS WG Co-chair)



_______________________________________________

mpls mailing list -- [e-mail]<mailto:[e-mail]>

To unsubscribe send an email to [e-mail]<mailto:[e-mail]>
_______________________________________________
mpls mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>
_______________________________________________
mpls mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>