Re: [Idr] I-D Action: draft-kaliraj-idr-multinexthop-attribute-01.txt

[Kaliraj Vairavakkalai <[e-mail]>]

> And how would you detect liveness of all of those parallel links ? Static + BFD ?

BFD to the BGP nexthop elements. (instead of the bgp-peer address).

> What's wrong with today's solution of using loopback for next hop + disable-connected-check knob and point static routes to resolve such next hop over parallel links ? Sure you can use more then one loopback here as well and that loopback is only significant locally over EBGP boundary.

Firstly, when not using ebgp-multihop and doing N parallel-links and N ebgp-sessions over them to be able to do ECMP/WECMP. In this model (call it model A), the RIB-size is increased N times, where N is the number of parallel links. With N=4 or 8 this may be tolerable today. But when N goes higher 128, 512, this model is un-manageable. So we need to go ebgp-multihop between the loopbacks (model B). But then we need an intermediate static route to a) provide connectivity and b) to resolve the BGP PNH over. And in that scenario, following problems exist for the “nexthop resolution (b) part”:


  *   Different service-routes cannot take different set of parallel-links. This would have been possible earlier in model-A.
  *   All service-routes need to share the same load-balancing treatment that is given to the static-route to the lo0. IOW, the per-service route different WECMP treatment that was earlier possible with model-A can no longer be guaranteed.

So  in essence, we don’t get the same functionality as model-A. Further,


  *   The EBGP routes use nexthop-resolution, because now the BGP PNHs are not directly connected. Which is not bad, but is additional load on the system. May be desirable to avoid.
  *   Traffic restoration on link-failure is no longer “a local-repair event confined to Forwarding-plane” because the PNH are not directly connected interface-addresses. The control-plane has to assist in detecting some unreachability events.
  *   Some platforms may not support preserving nexthop chain/hierarchy in forwarding plane, in which case convergence will take longer. All these problems are avoided if we just use a ECMP(Unlist nexthop) of directly-connected nexthops in forwarding-plane.

When using MNH (model C), we retain the nexthop-formation properties of model A, along with the RIB-size reduction properties of model-B. Use one ebgp-multihop session, and advertise N (e.g. 512) nexthops in the MNH attribute for a route, and 8 nexthops for another route. And each route can have its own ECMP/WECMP/Relative-Preference specified. So operator has better controls on which service routes to give what treatment on the ASBR boundary, thus can continue to monetize (like in model-A) those services being offered with reduced RIB-size consumption.

2> When such interface IngressIP1 or IP2 goes down you need to repair the encapsulation all the way in the edge instead of just performing local repair to get to the same loopback in milliseconds.

No. The repair happens at the nearest BN called the Forwarding-Helper. So the repair happens in sub-second. And actually this is orthogonal to whether we use IngressIP or lo0. In this case the IngressIP used as PNH are not visible outside this region at-all. So there is no way a convergence event propagates until the other edge-PE. The BN does a label-swap to the ingressIP to make forwarding happen. So it absorbs any failure event within this region.

And the BN needs more optimal forwarding information, such that intra-fabric hops can be avoided. This was a virtualization solution, where a physical box was split into multiple Virtual-Network-Functions. But the same model is followed when multiple physical boxes are involved too (e.g. N PEs and a pair of BNs in a region), and they are represented by one Anycast-nexthop to the rest of the network. The real PE-loopbacks are not visible outside their home region, thus reducing network-wide transport-layer scale.

Thanks
Kaliraj
From: Robert Raszuk <[e-mail]>
Date: Saturday, July 3, 2021 at 12:46 PM
To: Kaliraj Vairavakkalai <[e-mail]>
Cc: Minto Jeyananth <[e-mail]>, idr@ietf. org <[e-mail]>
Subject: Re: I-D Action: draft-kaliraj-idr-multinexthop-attribute-01.txt
[External Email. Be cautious of content]

Hi,

> KV2> EBGP is not discounted. One simple example where this can be useful for EBGP
> is the inter-AS parallel-links case. Even when using one bgp-session between loopbacks
> over the parallel-links, the MNH can be used to specify how the load-balancing should
> happen on the parallel links.

And how would you detect liveness of all of those parallel links ? Static + BFD ?

What's wrong with today's solution of using loopback for next hop + disable-connected-check knob and point static routes to resolve such next hop over parallel links ? Sure you can use more then one loopback here as well and that loopback is only significant locally over EBGP boundary.


KV2> there are some scenarios where it could be. The PE sends the RD:Pfx with MNH(IngressIP1, IngressIP2) thus attracting traffic to the more-optimal ingress-Forwarding-elements. Avoiding intra-fabric hops. The mechanism was invented to solve such a scenario only.

IMO this use case is a pretty bad idea. When such interface IngressIP1 or IP2 goes down you need to repair the encapsulation all the way in the edge instead of just performing local repair to get to the same loopback in milliseconds. It almost smells like some solution to fix platform deficiency in deployments of BGP as an IGP.

Tx,R.


Juniper Business Use Only