[Teas] Re: [Idr] Re: Mahesh Jethanandani's Discuss on draft-ietf-idr-sr-policy-nrp-11: (with DISCUSS and COMMENT)

["Dikshit, Saumya" <[e-mail]>]

Hello Authors of  draft-ietf-teas-ns-ip-mpls, Teas-WG,

Any response to below suggestion. Aye/Nay/Thinking-in-progress !!!

Thanks,
Saumya.

From: Dikshit, Saumya <[e-mail]>
Date: Thursday, 13 August 2026 at 12:04 AM
To: [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: Re: [Idr] Re: Mahesh Jethanandani's Discuss on draft-ietf-idr-sr-policy-nrp-11: (with DISCUSS and COMMENT)



Hi Authors of  draft-ietf-teas-ns-ip-mpls, Teas-WG,

This note follows a discussion in the IDR thread on draft-ietf-idr-sr-policy-nrp, where Ketan suggested that the TEAS document is the right place to anchor the NRP-ID type definition rather than each protocol-specific document defining its own encoding.

draft-ietf-teas-ns-ip-mpls currently does not state explicitly that the NRP-ID is a 32-bit unsigned integer.
I think, protocol documents citing it (such as the IDR SR Policy NRP draft) have to infer the encoding, which risks per-protocol divergence.

FWIW, following text may help:

> "The NRP-ID is represented as a 32-bit unsigned integer. Protocol-specific documents may define placement in their own encodings, but the value type and semantics are inherited from this definition."

Please let know your views on this.

Thanks,
Saumya

From: Ketan Talaulikar <[e-mail]>
Date: Wednesday, 12 August 2026 at 10:36 AM
To: Dikshit, Saumya <[e-mail]>
Cc: The IESG <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: [Idr] Re: Mahesh Jethanandani's Discuss on draft-ietf-idr-sr-policy-nrp-11: (with DISCUSS and COMMENT)

Hi Saumya,

Sure, please post to the TEAS WG on this topic referring to this conversation. However, please exclude the IDR WG and the IESG, as that matter is for the TEAS WG.

Thanks,
Ketan


On Wed, Aug 12, 2026 at 12:07 AM Dikshit, Saumya <[e-mail]<mailto:[e-mail]>> wrote:


Hi Ketan, thanks, and agreed.

+1 to keeping a single source of truth in the TEAS document to avoid per-protocol divergence.

A  text if  that could help or you think it’s better to be implicit? :

“NRP ID is represented as a 32-bit unsigned integer value.
Protocol-specific documents may define placement in their own encodings, but the value type and semantics are inherited from this definition.”

Or

“The NRP-ID carried in this sub-TLV is the NRP identifier defined in [draft-ietf-teas-ns-ip-mpls], encoded here in 4 octets.”

Thanks,
Saumya

Why this is the right posture with an AD:
1. You are aligning with consistency across WGs.
2. You are still helping with concrete text.
3. You avoid reopening a control-plane ownership argument in IDR.

If you want, I can also draft a TEAS-list-only follow-up note (short, non-political) proposing exactly the normative wording for their next revision.
From: Ketan Talaulikar <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, 11 August 2026 at 8:42 PM
To: Dikshit, Saumya <[e-mail]<mailto:[e-mail]>>
Cc: The IESG <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Idr] Re: Mahesh Jethanandani's Discuss on draft-ietf-idr-sr-policy-nrp-11: (with DISCUSS and COMMENT)

Hi Saumya,

If each protocol spec starts defining its own way of representing the NRP ID defined in the TEAS WG document, we risk inconsistency. I will suggest that the authors of that TEAS document (copied here) update the NRP ID description to indicate that it is represented as a 32-bit unsigned integer.

Thanks,
Ketan


On Sun, Aug 9, 2026 at 2:36 PM Dikshit, Saumya <saumya.dikshit=[e-mail]<mailto:[e-mail]>> wrote:
Hi Mahesh, authors, chairs,

A small text clarification that may help in the draft :

In Section 3 (or where the sub-TLV is first defined),

  *
if we can add one sentence that the 32-bit NRP-ID in this document is the BGP control-plane encoding defined by this specification, and is not inherited from draft-ietf-teas-ns-ip-mpls.

This keeps ownership of encoding semantics local to the IDR document while remaining consistent with the TEAS architecture reference.

Best Regards,
Saumya/

From: Mahesh Jethanandani via Datatracker <[e-mail]<mailto:[e-mail]>>
Date: Friday, 26 June 2026 at 9:49 PM
To: The IESG <[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]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: [Idr] Mahesh Jethanandani's Discuss on draft-ietf-idr-sr-policy-nrp-11: (with DISCUSS and COMMENT)

Mahesh Jethanandani has entered the following ballot position for
draft-ietf-idr-sr-policy-nrp-11: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!NpxR!lVPxIP6qIwK5I6pHxJu69FATokPD8OsLev5PktWEVGhHfALd0DiPf4DGMY6a3FObZt_2pxHfmzF0M6N8$
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-idr-sr-policy-nrp/__;!!NpxR!lVPxIP6qIwK5I6pHxJu69FATokPD8OsLev5PktWEVGhHfALd0DiPf4DGMY6a3FObZt_2pxHfm-cbKQxW$



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Section 9.1, normative reference [I-D.ietf-spring-sr-policy-nrp]:

263 >    [I-D.ietf-spring-sr-policy-nrp]
264 >               Yue, Chen, R., Dong, J., Lin, C., and J. Wenying, "Segment
265 >               Routing Policy Extension for Network Resource Partition",
266 >               Work in Progress, Internet-Draft, draft-ietf-spring-sr-
267 >               policy-nrp-00, 3 March 2026,

draft-ietf-spring-sr-policy-nrp is a normative reference to a WG
document in the SPRING working group that is not in the RFC Editor
queue. Its current datatracker state is "I-D Exists." Per RFC 3967
(BCP 97), normative references to Internet-Drafts that are not in the
RFC Editor queue requires explicit justification and warrants a DISCUSS.

The dependency is architectural: this draft defines the framework for
associating NRPs with SR Policy candidate paths; the current document
defines the BGP signaling that carries those associations. The current
document cannot stand on its own without the referenced document being
published. Furthermore, draft-ietf-spring-sr-policy-nrp is at version
00, adopted by the SPRING WG on 3 March 2026, indicating it is at a
very early stage with an uncertain publication timeline, and subject
to change.

The shepherd writeup directly addresses the WG Last Call objections
about SPRING dependencies, and records the following resolution: "Spring
documents should remain informative rather than normative references."
This is inconsistent with the current draft, which lists
[I-D.ietf-spring-sr-policy-nrp] as a normative reference in Section
9.1. Either the document was updated after the shepherd writeup without
a corresponding update to the writeup, or this reference classification
was never reconciled. In either case, the reference currently violates
both the RFC 3967 criterion and the WG's own decision.

Section 9.1, normative reference [I-D.ietf-teas-ns-ip-mpls]:

272 >    [I-D.ietf-teas-ns-ip-mpls]
273 >               Saad, T., Beeram, V. P., Dong, J., Halpern, J. M., and S.
274 >               Peng, "Realizing Network Slices in IP/MPLS Networks", Work
275 >               in Progress, Internet-Draft, draft-ietf-teas-ns-ip-mpls-
276 >               07, 28 February 2026,

The same is true of this draft. The exception is that in the Shepherd Report
its reference check that "all normative references are freely available RFCs."
This is factually incorrect for the current version of the document:
[I-D.ietf-teas-ns-ip-mpls] is listed in Section 9.1 as a normative reference
and is not an RFC.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 6, Security Considerations:

236 >    The security considerations of BGP [RFC4271] and BGP SR Policy
237 >    [RFC9830] apply to this document.
238 >
239 >    The security considerations of SR Policy [RFC9256] and SR Policy NRP
240 >    extensions [I-D.ietf-spring-sr-policy-nrp] apply to this document.

The security section addresses the document's attack surface solely by
reference. This document introduces a new mechanism: associating SR
Policy candidate paths with NRP identifiers via a new BGP sub-TLV.
An adversary able to inject or modify BGP SR Policy updates could cause
traffic to be associated with incorrect NRPs, violating resource
isolation guarantees that are central to network slicing. This threat
is specific to the NRP ID signaling defined here and is not covered by
the security considerations of the referenced documents. The section
should address it explicitly.

Additionally, as the GENART reviewer Mallory (thanks!) noted, citing
[I-D.ietf-spring-sr-policy-nrp] in the security section is fragile: if
the current document is published before that draft, the security
reference will point to an unpublished work. The relevant security
considerations from that draft should be summarized here directly.

----------------------------------------------------------------------

Section 3, Procedures, SHOULD for NRP consistency:

205 >    Although the proposed mechanism allows different candidate paths in
206 >    one SR policy to be associated with different NRPs, in normal network
207 >    scenarios it is considered that the association between an SR Policy
208 >    and NRP is consistent, in such case all candidate paths of one SR
209 >    policy SHOULD be associated with the same NRP.

Why a SHOULD and not a MUST? I support Gunter Van de Velde's
DISCUSS on the receiver behavior aspect of this issue.

Per BCP 14, a SHOULD requires identification of circumstances under
which the alternative behavior is acceptable. The text acknowledges
"non-normal network scenarios" but does not identify them. As a
consequence, both the conditions for deviation and the receiver behavior
when deviation occurs are unspecified.



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