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

[Nagendra Kumar <[e-mail]>]

HI Ketan,

Thanks a lot for your response and clarifying most of the queries. I just
have one follow up query based on the response.

KT> This is covered in RFC9256 in section 2 and more specifically the
tiebreaker in section 2.9.

<Nagendra> Thanks. I think I read RFC9256 before crafting my previous query
and re-read the highlighted section again. I am not sure if that clarifies
(or if I am confused) :).

Section 2.9 appears to discuss the tie breaker from SRPM point of view
between different paths received from heterogeneous sources/protocols (BGP,
PCEP, manual, etc).

As per Section 2.4 of RFC9256, When BGP is the signaling protocol, BGP will
provide ASN-ID and Node-ID for the candidate paths. Once the candidates
paths are with the BGP process, this draft suggests the below:

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.

The above statement (from sender perspective) is followed by the processing
procedure (receiver perspective) details when receiving multiple candidate
paths with different distinguishers.

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
<https://www.rfc-editor.org/info/rfc9256>].

So it appears to assume that different candidate paths with the same
<Color, Endpoint> will always be received with different distinguishers. I
am wondering what is the action when it is not the case. When the headend
receives the BGP update with the same <Color, Endpoint> and same
distinguisher in the NLRI with different candidate paths, how will the
headend treat the same?.

Once again, thanks a lot for the response and clarifying the queries.

Thanks,
Nagendra




On Mon, Mar 4, 2024 at 11:47 PM 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
>>
>>
>>
>>