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

[Ketan Talaulikar <[e-mail]>]

Hi Nagendra,

Please check inline with KT2.


On Fri, Mar 22, 2024 at 2:35 AM Nagendra Kumar <
[e-mail]> wrote:

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

KT2> There is no such assumption - it is simply the recommendation of how
things should be done when the desire is to signal multiple CPs (say for
fallback from one to the other) from the same controller via BGP.



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

KT2> In this case, these are two paths for the same "route" - i.e., it is
the same CP being signaled (perhaps two copies being received via two RRs).
And so in this case BGP will run its bestpath and send only that bestpath
to SRPM. This is covered in section 4.2.


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

KT2> Thanks for your review and I hope the above clarifies your query.

Thanks,
Ketan


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