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

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
>