[Int-dir] Re: draft-ietf-idr-sr-policy-nrp-13 telechat Intdir review

[Darren Dukes <[e-mail]>]

[e-mail]
<[e-mail]>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 <[e-mail]>
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 <
> [e-mail]> 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
>
>