Dear TEAS WG chairs and the WG There was a fork of this thread to limit to MPLS WG (for a good reason). Connecting back to the comment relevant to TEAS.
I am not concerned about NRPS space on the control-plane side or its mapping to the data-plane. However, I am concerned about data plane mapping across different data planes (interworking). My concern is that earlier poll on this was very weakly participated (as acknowledged in one of the TEAS sessions) Why is 20-bit NRPS not enough across all data planes? Thanks Regards … Zafar On 12/3/25, 10:09 AM, "Zafar Ali (zali)" <[email protected] <mailto:[email protected]>> wrote: Hi I agree with Jie that " it would be better to have the same number of bits in the forwarding plane and in the control plane, which could make the mapping much easier". Keep length consistent between MPLS and SRv6 is also good as it makes mapping easier. I also believe that "a smaller" numbers of NRPs are required as each NRP represent an instance in management plane and hardware scale prohibits supporting larger numbers of NRP. I do not see any reason why a 20-bit NRP Selector would not suffice, across all data planes. Thanks Regards … Zafar On 12/1/25, 7:56 AM, "Dongjie (Jimmy)" <[email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>>> wrote: Hi Adrian, I thought I have replied to this mail, apparently I didn't press the send button. Regarding the length of the NRP Selector ID, I agree it would be better to have the same number of bits in the forwarding plane and in the control plane, which could make the mapping much easier. IMO the decision made by TEAS of allowing different length of the ID acknowledged the difference in data plane protocols, which makes sense. Protocols like MPLS may have limitation in encoding, and may not be required to provide the same scalability as IPv6/SRv6 does. If the length of NRP Selector ID in MPLS and SRv6 domain are different, mapping can be performed at the boundaries. Actually even if the length are the same, mapping of the ID value at domain boundaries may still be needed. That said, it would be good if there can be one option in which they have the same length, preferably it is also the same as the ID length in the control plane. Best regards, Jie Cisco Confidential -----Original Message----- From: Adrian Farrel <[email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>>> Sent: Monday, November 17, 2025 12:23 AM To: 'TEAS WG' <[email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>>>; [email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>>; [email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>> Cc: 'mpls' <[email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>>> Subject: [spring] MPLS WGLC on draft-ietf-mpls-mna-nrp-selector Please note that the MPLS working group is holding a last call on draft-ietf-mpls-mna-nrp-selector. I am the document shepherd. There are issues around the size of the NRP Selector / identifier that may be of relevance to TEAS, 6MAN, and SPRING. I'd appreciate it if any discussions could take place on the MPLS list so that it is easier to coordinate. The questions are: 1. How many bits are needed to encode the NRP Selector in the MPLS forwarding plane? It has been suggested that it is important to allow the same number of bits in the forwarding plane as are available in the control plane. It has also been pointed out that it is always possible to map between the control plane representation and the forwarding plane representation, and it is possible to limit the expression of the identifier in the control plane such that it is suitable for a particular data plane. Here, the opinion of TEAS may be helpful to us. 2. Should the encoding of the NRP Selector in the MPLS and SRv6 forwarding planes be identical? It has been suggested that in multi-technology-domain scenarios, it would be helpful to have the same NRP Selector values in each domain. This could make management and debugging simpler. It has been pointed out that if the sizes of NRP Selector are different in the two domains, the smaller can be used as a subset of the larger, to enable multi-domain operation, or that mapping can be performed at the domain boundaries. This question is particularly relevant to 6MAN and SPRING. Thanks for any thoughts. Adrian _______________________________________________ spring mailing list -- [email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>> To unsubscribe send an email to [email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>> _______________________________________________ mpls mailing list -- [email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>> To unsubscribe send an email to [email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>> _______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
