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

[<[e-mail]>]

David, all

> From: David Lamparter [mailto:[e-mail]] > Sent: Wednesday, March 25, 2015 10:04 PM
> 
> 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? 

This is application specific.
The first capability is applicable to MPLS routes, typically inter AS MPLS routes, typically within an administrative domain. e.g. in the range of 1k to 10k
If your point is that BGP will not scale one additional attribute/ 10 bytes per update, you could comment many more IDR related documents. (I will refrain from picking names to avoid trolling IDR ML)
If your point is about the trade-off with regard to a different encoding (namely ID.bgp-nh-cost), I have already replied to that point.

> What's the semantic / complexity impact of tying this to update processing?

You mean, compared to other attribute? I'd say roughly the same as others (I would even say on the low end side). Do you see an issue?

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

The attribute defines NH capabilities for the NLRI advertised in the update. Hence, it's advertised in each UPDATE requiring the advertisement of a capability. e.g. for the Entropy Label Capability, typically in each UPDATE carrying labels routes to Entropy Label capable routers loopback
This may not be clear in -00. This will be clarified in -01. Thanks for the comment.
 
> > 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.

I think we should design based on reality, especially if deployment is the goal.

> Fix the limitation?

In the meantime, the argument holds.
 
> > 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". 

Changing the name is a possibility. However, the key behavior is that such capabilities are removed when the next-hop is changed. The current name reflects this behavior.

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

Meaning ietf-idr-bgp-nh-cost is not applicable?
 
> 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".

Using ID.next-hop-capability, one may define a capability carrying flags. This has been considered in -00 but rejected to favor simplicity and to focus first discussions. This may be added in a subsequent version.
Regarding the first capability (Entropy Label), following first discussion after IDR meeting, it seems likely that the value will be used to advertise the Readable Label Size Depth. Hence flag would not be applicable.

Thanks,
/Bruno
> 
> -David

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.