Early Review of draft-ietf-idr-sr-policy-safi-01
review-ietf-idr-sr-policy-safi-01-opsdir-early-nainar-2024-03-04-00

Hi,

I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written with the intent of improving the operational aspects of
the IETF drafts per guidelines in RFC5706.

Comments that are not addressed in last call may be included
in AD reviews during the IESG review.  Document editors and WG chairs should
treat these comments just like any other last call comments.

Overall Summary:

This draft is a standard track proposing SR Policy NLRI and the relevant TLVs
along with the handling procedures. Overall this is a well written document and
addresses all potential operational aspects. I am marking it as "Has issues"
only to get some clarification on the below as I could not get any clarity
based on my reading.

More details below:

An SR Policy intended only for the receiver will, in most cases, not
   traverse any Route Reflector (RR, [RFC4456]).

--> Normally, it is expected to have BGP session between the PEs and the RRs.
The above statement appears to give an impression that - in addition to the
PE-RR session(s), does this machinery require additional/adhoc sessions between
the PEs?. Or is this statement only applicable for the PCE-PE scenario?. Can
you clarify the same?

It has to be noted that if several candidate paths of the same SR
   Policy (endpoint, color) are signaled via BGP to a headend, then it
   is RECOMMENDED that each NLRI uses a different distinguisher.  If BGP
   has installed into the BGP table two advertisements whose respective
   NLRIs have the same color and endpoint, but different distinguishers,
   both advertisements are passed to the SRPM as different candidate
   paths along with their respective originator information (i.e., ASN
   and BGP Router-ID) as described in section 2.4 of [RFC9256].

--> What happens when the BGP receives several candidate paths for the <Color,
Endpoint> but with the same distinguisher?. Will it override or the preference
sub-TLV will handle it?. I was looking into the related drafts/RFCs but I am
not sure if this is handled properly and would like to add here to clarify as
required.

--> What happens if a node receives the SR Policy NLRI with the length field of
the Binding SID Sub-TLV set to 6 and the label value from the reserved range
(0-15 may be)?

--> Section 2.4.3 describes the Sub-TLV for SRv6 BSID. Any reason why section
2.4.2 includes a length field and describes another way to represent SRv6 BSID?

Thanks,
Nagendra