Re: [Idr] I-D Action: draft-ietf-idr-bgp-fwd-rr-02.txt

> the egress PIC

Except this is not real egress PIC.

In egress PIC ASBRs or PEs receive EBGP paths and rarely act as RRs.

Here we seem to have a case of option C and IBGP domain where ABRs are
usually redundantly connected and they learn routes over IBGP from each
site.

I must admit that I have never seen a real practical analysis if in such
cases we should be doing PIC between ABRs acting as RRs. Especially for
infrastructure routes.

And btw propagating withdraws via good RRs last time I measured was taking
at most single milliseconds.

Cheers,
R.

On Mon, Mar 18, 2024 at 11:24 AM Igor Malyushkin <gmalyushkin@gmail.com>
wrote:

> Hi,
>
> AFAIK, the egress PIC is a widely deployed feature with labeled paths. One
> of its characteristics is to preserve traffic in-flight, that was sent just
> in time of a failure event or slightly after that. Traffic is almost always
> faster than any control plane stuff. The significant problem with PIC in
> this case is a possible temporal loop if a destination node fails, but it
> is a separate topic.
>
> My 2 cents.
>
> пн, 18 мар. 2024 г. в 08:40, Kaliraj Vairavakkalai <kaliraj=
> 40juniper.net@dmarc.ietf.org>:
>
>> Hi Robert, please see inline. KV>
>>
>>
>>
>> Thanks
>>
>> Kaliraj
>>
>>
>>
>> Juniper Business Use Only
>>
>> *From: *Robert Raszuk <robert@raszuk.net>
>> *Date: *Sunday, March 17, 2024 at 11:28 PM
>> *To: *Kaliraj Vairavakkalai <kaliraj@juniper.net>
>> *Cc: *idr@ietf. org <idr@ietf.org>
>> *Subject: *Fwd: I-D Action: draft-ietf-idr-bgp-fwd-rr-02.txt
>>
>> *[External Email. Be cautious of content]*
>>
>>
>>
>> Hi Kaliraj,
>>
>>
>>
>> Thx for posting the new version.
>>
>>
>>
>> I have one observation or clarification to be made in respect to text you
>> added in section 4.1:
>>
>>
>>
>> > However this approach does not allow the ABR-ABR tunnels to be
>>
>> > used as backup path, in the event where an ABR looses all tunnels
>>
>> > to upstream ASBR.
>>
>>
>>
>> So you are talking about the delta time it takes for ABR which looses all
>> tunnels to upstream ASBRs to send BGP withdraws for those learned
>> infrastructure routes - correct ?
>>
>>
>>
>> KV> Yes. Those withdrawals need to anyway happen, and reach both the
>> ingress PEs and adjoining/redundant ABR.
>>
>> KV> So that they can do BGP PIC repair based on that event.
>>
>> KV> Here I am saying that such BGP PIC repair can happen only at ingress
>> PE
>>
>> KV> (which may be multiple BGP hops away), and not at the adjoining ABR.
>>
>>
>>
>> So we are talking 10s of milliseconds here from the moment all such paths
>> are invalidated (which  -the detection and invalidation is needed in any
>> scenario).
>>
>>
>>
>> KV> The BGP update propagation can take longer, based on load on the BGP
>> propagation path. But BGP PIC itself can’t always
>>
>> KV> guarantee 10s of ms restoration. It only guarantees restoring the
>> traffic without depending on service-prefix scale
>>
>> KV> once the unreachability is detected (in this case: BGP withdrawal is
>> received).
>>
>>
>>
>> As you have established each ABR will set next hop self and advertise
>> routes to local PEs (directly or via yet one more pair of RRs (RR26 here)).
>> So each PE will already have backup paths all what you are observing here
>> is the time before PEs invalidate paths advertised by ASBR which
>> looses upstream tunnels.
>>
>>
>>
>> KV> Agreed.
>>
>>
>>
>> So if such failure models are really likely to happen (in spite of
>> redundant ABR connectivity in each area)  I would rather focus on fast
>> removal of broken paths from the network with one next hop invalidation
>> (single BGP or IGP message, single RIB to FIB switchover on PEs) etc ...
>>
>>
>>
>> KV> As explained above, that would also happen. But it may take longer
>> than if the repair happened at the ABR, which is closer to the failure
>> event.
>>
>> KV> Just a tradeoff to be aware of. Thx.
>>
>>
>>
>> Thx,
>> Robert
>>
>>
>>
>> ---------- Forwarded message ---------
>> From: <internet-drafts@ietf.org>
>> Date: Sun, Mar 17, 2024 at 6:42 AM
>> Subject: I-D Action: draft-ietf-idr-bgp-fwd-rr-02.txt
>> To: <i-d-announce@ietf.org>
>> Cc: <idr@ietf.org>
>>
>>
>>
>> Internet-Draft draft-ietf-idr-bgp-fwd-rr-02.txt is now available. It is a
>> work
>> item of the Inter-Domain Routing (IDR) WG of the IETF.
>>
>>    Title:   BGP Route Reflector with Next Hop Self
>>    Authors: Kaliraj Vairavakkalai
>>             Natrajan Venkataraman
>>    Name:    draft-ietf-idr-bgp-fwd-rr-02.txt
>>    Pages:   9
>>    Dates:   2024-03-16
>>
>> Abstract:
>>
>>    The procedures in BGP Route Reflection (RR) spec RFC4456 primarily
>>    deal with scenarios where the RR is reflecting BGP routes with next
>>    hop unchanged.  In some deployments like Inter-AS Option C
>>    (Section 10, RFC4364), the ABRs may perform RR functionality with
>>    nexthop set to self.  If adequate precautions are not taken, the
>>    RFC4456 procedures can result in traffic forwarding loop in such
>>    deployments.
>>
>>    This document illustrates one such looping scenario, and specifies
>>    approaches to minimize possiblity of traffic forwarding loop in such
>>    deployments.  An example with Inter-AS Option C (Section 10, RFC4364)
>>    deployment is used, where RR with next hop self is used at redundant
>>    ABRs when they re-advertise BGP transport family routes between
>>    multiple IGP domains.
>>
>> The IETF datatracker status page for this Internet-Draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-fwd-rr/
>> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-idr-bgp-fwd-rr/__;!!NEt6yMaO-gk!Hv7GNYr6n89i4QRD_aXV0QhV0N_J6YWRal9RjghMoB6DdmitfkQrjPi8YKCDbwPDc6YiEq2NYiMTgzkj$>
>>
>> There is also an HTMLized version available at:
>> https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-fwd-rr-02
>> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-fwd-rr-02__;!!NEt6yMaO-gk!Hv7GNYr6n89i4QRD_aXV0QhV0N_J6YWRal9RjghMoB6DdmitfkQrjPi8YKCDbwPDc6YiEq2NYmrSzwvH$>
>>
>> A diff from the previous version is available at:
>> https://author-tools.ietf.org/iddiff?url2=draft-ietf-idr-bgp-fwd-rr-02
>> <https://urldefense.com/v3/__https:/author-tools.ietf.org/iddiff?url2=draft-ietf-idr-bgp-fwd-rr-02__;!!NEt6yMaO-gk!Hv7GNYr6n89i4QRD_aXV0QhV0N_J6YWRal9RjghMoB6DdmitfkQrjPi8YKCDbwPDc6YiEq2NYmTSTQwU$>
>>
>> Internet-Drafts are also available by rsync at:
>> rsync.ietf.org::internet-drafts
>>
>>
>> _______________________________________________
>> I-D-Announce mailing list
>> I-D-Announce@ietf.org
>> https://www.ietf.org/mailman/listinfo/i-d-announce
>> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/i-d-announce__;!!NEt6yMaO-gk!Hv7GNYr6n89i4QRD_aXV0QhV0N_J6YWRal9RjghMoB6DdmitfkQrjPi8YKCDbwPDc6YiEq2NYmzhCeS9$>
>> _______________________________________________
>> Idr mailing list
>> Idr@ietf.org
>> https://www.ietf.org/mailman/listinfo/idr
>>
>