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

[Nagendra Kumar <[e-mail]>]

Thanks for the clarification.

On Thu, Mar 21, 2024 at 7:36 PM Ketan Talaulikar <[e-mail]>
wrote:

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