Subject: Re: [Idr] Comments on slides-99-idr-03-idr-rs-bfd_ietf99-00.pdf

From: Nick Hilliard <[email-masked]>
Date: Tue, 01 Aug 2017 11:30:25 +0100

Jeffrey Haas wrote:
> On Fri, Jul 21, 2017 at 02:20:44PM -0700, Enke Chen wrote:
>> I have several comments on slides-99-idr-03-idr-rs-bfd_ietf99-00.pdf,
>> Page 10 "Why not add-paths?":
>>
>> •Some IXPs do not want to use add-paths or their customers may not want to  use it.
>>
>>> Enke: Do we understand the reasons?  Please also note that the add-path can be
>>> Enke: deployed one a per-neighbor basis.
> 
> I'll have to leave this motivation to the coauthors, who also are associated
> with IXP.  Resource consumption has been offered as an example consideration
> by others.

There are still issues with lack of support for add-path/ebgp in
mainline router vendors, e.g.

> nick@testbox# commit
> [edit protocols]
>   'bgp'
>     Error in neighbor x.x.x.6 of group test-add-path:
> Add-path is not supported on external groups/peers
> error: configuration check-out failed
> 
> [edit]
> nick@testbox#

> Router(config)#router bgp 2128
> Router(config-router)#add ipv4
> Router(config-router-af)#neighbor x.x.x.6 additional-paths send
> % BGP: Add-Path *not* supported on EBGP peering
> Router(config-router-af)#

the junos box isn't running very up-to-date software, so maybe things
have improved on that front.  The IOS box is running a version of 15.7
released this week, i.e. hot off the shelf.

Nick

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 1 Aug 2017 10:29:35 -0400

Nick,

> > error: configuration check-out failed

As I noted earlier in the thread, add-paths for ebgp has known protocol
issues that required extension for correct route selection.  It's for this
reason that no vendor that I'm aware of supports ebgp add-paths.

The IXP case is somewhat unusual and might be okay for the majority of such
cases, although it'd still result in temporal determinism.

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 1 Aug 2017 12:38:59 -0400

On Tue, Aug 01, 2017 at 12:04:27AM +0200, Robert Raszuk wrote:
> ​So if resource of ADD-PATHS ALL is a major concern here how does new SAFI
> solves this as compared with just sending all eligible next hops from RS to
> clients in a new attribute ?

You would need to do so without necessarily sending routes.  

One of our internal discussion points was "could we simply send the nexthops
attached to something like a martian route so the prefix wouldn't get
installed for forwarding?".  I even had a rough draft of sending the full
set of nexthops using extended communities as a carrier on such martian
routes.

Such proposals get ugly.  It eventually simplified ot just the new safi.

> After all client must establish all BFD sessions (or other probing) to
> detect liveness of next hops, but client would not need to report back who
> is up or down and would not need to wait for RS computing and distributing
> new best path. He can simply switch locally forwarding to go to those next
> hops which are up.

As was mentioned on list and at mic at IETF-99: This proposal is compatible
with add-paths.  Whether the RS chooses to use the results of the client
reachability for local route selection is optional.

> Likewise RS would not need to become super powerful controller ...

As pointed out at the MIC, the RS already does route selection within a
view.  This is simply proxying the reachability requirement for the nexthop
per standard 4271 logic.  This isn't super magic.

Yes, it does work best when the client is in a view by itself.  But as noted
on-list, some IXPs deploy that way.

-- Jeff

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 01 Aug 2017 21:35:57 +0100

> on-list, some IXPs deploy that way.

you could probably upgrade that to from "some" to "most".  Per client
loc-rib is pretty standard these days.

Nick