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

[Ketan Talaulikar <[e-mail]>]

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
>
>
>
>