[email protected] <[email protected]>g
Thanks for the reply Ketan. I added the spring nrp authors to the thread to respond and consider the changes requested below. On Thu, Jul 23, 2026 at 1:18 AM Ketan Talaulikar <[email protected]> wrote: > + 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]
