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

[Robert Raszuk <[e-mail]>]

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.

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.

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.

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.


> 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.

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.

- - -

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

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

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

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 ?

Thx,
R.