Zafar, As far as the TEAS WG chairs are concerned, there hasn't been any WG discussion or input that would suggest any changes to the conclusions that were drawn regarding NRP selectors early last year [ https://mailarchive.ietf.org/arch/msg/teas/hpvVY_De48SyMWVQ3YItEUSS-HA/].
>> Why is 20-bit NRPS not enough across all data planes? TEAS WG recommends a minimum length of 8 bits. There is no guidance on the maximum length. That said, it should be safe to assume that 20 bits is more than enough. The actual data-plane-specific encodings are outside the scope of the TEAS WG and should be based solely on optimal encoding options specific to the data plane. Please feel free to propose text to draft-ietf-teas-ns-ip-mpls if you would like to see any specific IETF network slice realization scenario elaborated upon. Regards, -Pavan On Wed, Dec 3, 2025 at 8:59 AM Zafar Ali (zali) <zali= [email protected]> wrote: > 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)" <jie.dong= > [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]>> > > > > > > > > > > _______________________________________________ > mpls mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
