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

["[e-mail]" <[e-mail]>]

Is there anything new here?

Sent from my iPhone

On Apr 17, 2025, at 1:55 PM, Haoyu Song <[e-mail]> wrote:



WG,

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.

 

Regards,

Haoyu

 

From: Dongjie (Jimmy) <jie.dong=[e-mail]>
Sent: Thursday, April 17, 2025 12:55 AM
To: Tony Li <[e-mail]>; Zafar Ali (zali) <[e-mail]>
Cc: Nicolai Leymann <[e-mail]>; mpls <[e-mail]>; mpls-chairs <[e-mail]>; [e-mail]
Subject: [mpls] Re: Working Group Adoption Poll for draft-li-mpls-mna-nrp-selector

 

For 5G network slices a 32-bit identifier (S-NSSAI) is used. To facilitate the mapping between 5G network slices and NRPs, 32-bit NRP selector ID needs to be considered. draft-li-mpls-enhanced-vpn-vtn-id proposes to carry 32-bit NRP selector ID using PSD.

 

We may not need all these options in the end, maybe one for ISD and one for PSD. At current stage maybe it is wise to call for adoption of both the ISD and PSD based approaches.

 

Also the TEAS conclusion shows that there can be requirements to carry indicators for NRP-specific forwarding policy (e.g. indicator for strict match), draft-li-mpls-mna-nrp-selector doesn’t show how such indicators can be encapsulated.

 

Best regards,

Jie

 

From: Tony Li <[e-mail]> On Behalf Of Tony Li
Sent: Thursday, April 17, 2025 12:17 AM
To: Zafar Ali (zali) <[e-mail]>
Cc: Nicolai Leymann <[e-mail]>; mpls <[e-mail]>; mpls-chairs <[e-mail]>; [e-mail]
Subject: [mpls] Re: Working Group Adoption Poll for draft-li-mpls-mna-nrp-selector

 

 

[WG chair hat: off]

 

 

Hi Zafar,

 

 

 

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?

 

 

Scale.  Amidst the 5g hype, there have been various claims about the ‘millions’ of NRP selectors that will be required.  A 20 bit selector gives the operator more room for scale.

 

As noted elsewhere, this can be pruned after adoption.

 

 

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/" target="_blank" rel="nofollow">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).

 

 

You’re free to advocate for a PSD option as well.  There’s no reason to defer proceeding, things are decoupled.

 

 

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

 

 

This is a spec for one mechanism.

 

T