Re: [Idr] decraene-idr-next-hop-capability <-> ietf-idr-bgp-nh-cost

[David Lamparter <[e-mail]>]

On Wed, Mar 25, 2015 at 07:56:48PM +0000, [e-mail] wrote:
> > From: David Lamparter [mailto:[e-mail]] > Sent: Tuesday, March 24, 2015 4:30 PM
> > the next-hop-capability draft currently seems to target using the new nexthop
> > capability on a per-advertisement level.  Considering that draft-idr-bgp-nh-
> > cost adds a new SAFI to convey information about nexthops, it seems natural
> > to tranposrt the capability information in that place?
> 
> That's a valid comment.
> 
> 1)  cost/benefit 
> Avertising the next-hop-capability on a per update basis has indeed a cost but also a benefit.
> In term of cost, the simplest next-hop-capability is 5 octets. Compared to an update in the range of 100-1000 octets, that's 5% to 0,5%.
> In term of benefit, this allow customizing the capability on a per update/routes granularity if required, which may be a useful possibility for some capabilities.

Sure, the attribute is smaller.  But how many neighbors are there?  How
many routes are there?  What's the semantic / complexity impact of tying
this to update processing?  I assume the attribute is sent only once, on
a randomly picked update that has the "right" nexthop - what happens if
that route is withdrawn?  What if the last route with nexthop X gets
withdrawn?

> Engineering is about trade-off. IMO, the benefit, especially long term, out weight the fixe cost, which is small and will become smaller, in relative term, in the future (thanks to Moore's law).
> 
> 2) deployability 
> In addition, in term of deployability, a new attribute has no impact.  On the other hand draft-idr-bgp-nh-cost use a new AFI/SAIF which requires reconfiguration and reboot of all BGP sessions. This is a much higher cost for IBGP alone. For EBGP, this is simply not an option IMO.

I don't think we should design "around" limitations.
Fix the limitation?

> So, I agree that this is a valid option to consider, however I don't think that it's a better one.
> 
> > (That would also remove the question of what behaviour should be when you
> > get different advertisements with the same nexthop, but with a different
> > nexthop capability attribute.)
> 
> For a given route/NLRI, you use the next-hop capability attached to this route.
> To rephrase, you do not consider next-hop capability that may have been advertised in another update.
> I agree that this may not be crystal clear in the text, I will clarify in the next revision.

Er - I'd go as far as change the name then.  It's not "next-hop
capability", it's "route's (including next-hop) capability".  Most
significantly, it won't be useful in any context that is really nexthop.
The way you describe it, I can't feed information from this attribute
into the nexthop table.

If there's a need to signal route 'flag bit' capabilities more
efficiently than adding an empty attribute - sure.  But that's not
"next-hop capabilities".


-David