+ SPRING WG Hi Darren,
Thanks for your review and feedback. Especially thanks for "looking beyond" just this document. Since this review is somewhat late (but very welcome), I would like to clarify some aspects so it is brought to the attention of the appropriate WGs and author teams. On Thu, Jul 23, 2026 at 5:55 AM Darren Dukes via Datatracker < [email protected]> wrote: > Document: draft-ietf-idr-sr-policy-nrp > Title: BGP SR Policy Extensions for Network Resource Partition > Reviewer: Darren Dukes > Review result: Ready with Issues > > I was asked to review revision 11 of this draft as part of the IntArea > directorate. Since then revision 13 has been posted and I've revised this > review to that version. This review is for the Int AD IESG review and may > be > considered by authors as last call review comments. > > General Observations: > The specification is compact and the wire encoding is straightforward. > The encoding and the separation between BGP validation and SR Policy > Module (SRPM) semantic processing are consistent with RFC 9830. > > After reviewing the draft and its normative references I'm left with one > ISSUE around validity checking. > > This draft defines the NRP ID Sub TLV and its encoding, but > does not specify, nor fully abdicate, the validity checking of the NRP ID > to > draft-ietf-spring-sr-policy-nrp. > > draft-ietf-spring-sr-policy-nrp-02 does not yet define > deterministic behavior when a syntactically valid NRP association cannot be > used by the receiving head end. > KT> This is for the SPRING WG to resolve as it pertains to a SPRING WG draft. May I request the authors of that document to track this as an issue? > > Further more this draft contains select normative language about how NRP > IDs are > associated with candidate paths, but that text says essentially nothing > normative. > > This draft states in Operational Considerations: > Although the updates to SR Policy architecture in > [I-D.ietf-spring-sr-policy-nrp] allow different candidate paths in > one SR Policy to be associated with different NRPs, in normal network > scenarios it is considered that no matter which candidate path is > active, the association between an SR Policy and NRP is consistent. > In such case all candidate paths of one SR Policy SHOULD be > associated with the same NRP. The cases where different candidate > paths of an SR Policy are associated with different NRPs is valid but > NOT RECOMMENDED. > > This does not tell an implementor of this specification anything other than > "anything other NRP ID 0 is valid". > > ISSUE 1: I suggest this text say something deterministic or is removed > completely and replaced with text stating "NRP ID validation is out of > scope > and defined in draft-ietf-spring-sr-policy-nrp" > KT> This is very good suggestion and aligned with BGP SR Policy SAFI draft where the semantic validation is left to the SRPM module. Request the authors to consider this. > > ISSUE 2 (not an issue for this draft): In addition > draft-ietf-spring-sr-policy-nrp should be updated at the earliest to > specify > normative validity checking of NRP IDs and the requirements around their > permitted values in SR Policy candidate paths, and their lack of existence > when > NRP ID 0 may be received but the TLV is ignored. > KT> This is also a very good suggestion for the authors of the SPRING WG document and I request that they take care of this at the earliest. Thanks, Ketan
_______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
