Re: [Idr] Opsdir early review of draft-ietf-idr-sr-policy-safi-01

[Ketan Talaulikar <[e-mail]>]

Hi Nagendra,

FYI an update has been posted for this draft:
https://datatracker.ietf.org/doc/html/draft-ietf-idr-sr-policy-safi-02

Please let me know if there is anything outstanding to address your
comments.

Thanks,
Ketan


On Tue, Mar 5, 2024 at 10:16 AM Ketan Talaulikar <[e-mail]>
wrote:

> Hi Nagendra,
>
> Thanks for your review and please check inline below for responses.
>
>
> On Tue, Mar 5, 2024 at 8:16 AM Nagendra Nainar via Datatracker <
> [e-mail]> wrote:
>
>> Reviewer: Nagendra Nainar
>> Review result: Has Issues
>>
>> 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.
>>
>
> KT> That is for BGP VPN services. This is a different SAFI.
>
>
>> 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?
>>
>
> KT> Yes, there is further text in the section that describes the same.
> Since this is a BGP spec, the term "controller" is used as opposed to PCE
> which is construed by many as a PCEP construct.
>
>
>>
>> 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.
>>
>
> KT> This is covered in RFC9256 in section 2 and more specifically the
> tiebreaker in section 2.9.
>
>
>>
>> --> 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)?
>>
>
> KT> That is handled by the SRPM and outside the scope of BGP. In this
> specific case, the specified BSID is not usable/available and the behavior
> is covered by section 6.2 of RFC9256.
>
>
>>
>> --> 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?
>>
>
> KT> Section 2.4.2 specifies the SR BSID sub-TLV that was used for both
> SR-MPLS and SRv6. But it was defined during the early stages of SR
> evolution and did not cover the SRv6 aspects fully and hence the SRv6 BSID
> sub-TLV was introduced in section 2.4.3. For backward compatibility with
> existing implementations, the use of SR BSID sub-TLV for SRv6 was retained
> (with a reduced functionality).
>
> Thanks,
> Ketan
>
>
>>
>> Thanks,
>> Nagendra
>>
>>
>>
>>