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

[Kaliraj Vairavakkalai <[e-mail]>]

Pls see inline. KV2>


From: Robert Raszuk <[e-mail]>
Date: Saturday, July 3, 2021 at 4:28 AM
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,

Few follow up points ...

KV>  All resolved(reachable) legs of the MNH will be installed to FIB.

That is huge change BGP <--> RIB interaction. Note today unless you install more next hops *only* if multipath is enabled.

KV2> An implementation can chose to apply that kind of local policy knob to MNH as-well. I meant an implementation that intends to use the MNH treats the PNHs received in the MNH just like it would treat a PNH received in attr 3,14 and do nexthop-resolution (multihop) or interface-check (singlehop). And all useable legs will be installed to FIB, capped by the max-num-ECMP of the platform.

Besides you can safely do it only when network is doing encapsulation end to end. If you are doing hop by hop lookup and you do not even know if all nodes support MNH loops can form.

KV2> agree. This is intended for use in tunneled networks (bgp free core).
KV> Let us say the max-num-ECMP supported by a router is 16. Then it will install the first 16 nexthops (as per the ‘Relative-preference’ field) received in the MNH. It will not install all the nexthops. So the same existing ecmp-limit safeguards can be

Nope that was not the point ... I am talking about control plane RAM when the attacker is using MNH attribute fill to the top of the UPDATE MSG SIZE to kill your box regardless if this will get down to RIB or FIB.

KV2> That’s a good point. But the same max-num-ECMP checks can be applied during bgp update processing as-well to validate a MNH. An implementation can chose via local defaults/configs what is an acceptable max-limit for number of PNHs that can exist in a MNH. A route with an unacceptable MNH should be given ‘ignore the MNH-attribute exists’ treatment. And forwarding can happen based on PNH in attr 3, 14 – in those cases.

Today prefix limit saves you from this type of attacks. When one deployed MNH with the peers it opens up his network ... I would love to see this type of threat discussed in security section.

KV2> Sure. Will discuss it more.
used. The only difference is how the nexthops are received. Instead being received in 100 routes, it is received in 1 route.

Nope ... peers today sends you the single path as best unless you allow him to do add-paths all.

KV2> I see your point about the value of having capability-negotiation. It provides another level of  control on whether to accept MNH from a peer or not, especially the EBGP-case. I will add a capability for this MNH.

KV> they could potentially get called-back when effective-igp-cost of the route changes. Pls note, this proposal does not increase number of unique PNHs in the system/network, for e.g. that is a function of how many PEs exist in the network. Just what changes is how those PNHs are conveyed in bgp-updates as ecmp/pic nexthops for a bgp-prefix. Number of routes required to convey that relationship is greatly reduced, while providing more control to the advertiser on signaling the ecmp/pic relationships.

If you allow this for EBGP you are changing the BGP game completely. Especially if you allow this for SAFI 1.

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 this can be done on a per route level. The mechanisms that exist today can at-best provide “per nexthop set” granularity load-balancing options (configuring a static-route to the lo0 PNH with the desired load-balancing)
- - -

Btw ... who would build this MNH attribute ? ASBR/PE if not doing next hop self ?

KV2> it can be PE/ASBR with doing nexthop-self.


Can it be build say in transit RR from paths received via add-paths from PEs ?

KV2> And it can be the RR as-well in some cases which may do a “nexthop-change to an anycast-address”. RR in essence acts like a controller. The MNH actually provides better granularity controls to a controller to install routes on receiving BGP speakers. I will be presenting one such usecase in IETF111, “Scaling Seamless-MPLS networks using BGP-MPLS-Namespaces”

If you talking labels ... considering each VPNv4/v6 route has a unique per VRF RD such MNH would be not very useful anyway.

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. Section 2 tries to explain the use-cases in brief. I will try to go over it in some detail during the above IETF111 presentation. Also, the EBGP parallel-links usecase is not currently recorded in section 2. I will record it.

If not I am not sure what is the big gain here. Yes it could be done (with lots of work) but I am a bit missing the need for it considering that you can get the required functionality today already.

Is there anything it actually brings to the table other then ton of implementation and new operational issues ?

KV2> I do think it brings in value of better scaling and finer-grained traffic engineering controls, with some moderate implementation complexity. Only time will tell for sure. :). Thanks.

Thx,
R.



Juniper Business Use Only