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

[Igor Malyushkin <[e-mail]>]

Well, maybe there is some gap in terminology. I always considered this
behavior as a PIC, because we can switch between the next hops without any
dependency on the number of prefixes above. An egress characteristic here
is that it happens on a failed next-hop node (an ingress is not aware
at the moment or is just starting to react). But we can find a better name
for this to avoid confusion.

Speaking about the propagation of withdraws. As I've previously mentioned,
traffic may be sent slightly before (a few milliseconds) or just in time of
a failure. Without "protection" at egress, it will be lost if ABRs do not
exchange their routes (e.g., because of the same CLUSTER ID).
Another moment to consider is that the fast propagation not only depends on
the diameter of the BGP network (the number of BGP hops from a source of
the event to all its potential receivers) but also on the situation on
every such hop (e.g., CPU spikes). In other words, it is not constant.

пн, 18 мар. 2024 г. в 14:54, Robert Raszuk <[e-mail]>:

> > 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 <[e-mail]>
> 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=
>> [e-mail]>:
>>
>>> Hi Robert, please see inline. KV>
>>>
>>>
>>>
>>> Thanks
>>>
>>> Kaliraj
>>>
>>>
>>>
>>> Juniper Business Use Only
>>>
>>> *From: *Robert Raszuk <[e-mail]>
>>> *Date: *Sunday, March 17, 2024 at 11:28 PM
>>> *To: *Kaliraj Vairavakkalai <[e-mail]>
>>> *Cc: *idr@ietf. org <[e-mail]>
>>> *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: <[e-mail]>
>>> Date: Sun, Mar 17, 2024 at 6:42 AM
>>> Subject: I-D Action: draft-ietf-idr-bgp-fwd-rr-02.txt
>>> To: <[e-mail]>
>>> Cc: <[e-mail]>
>>>
>>>
>>>
>>> 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
>>> [e-mail]
>>> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/idr
>>>
>>