Subject: Re: [Idr] RS BFD draft

From: Jeffrey Haas <[email-masked]>
Date: Tue, 18 Apr 2017 16:38:23 -0400

On Fri, Mar 31, 2017 at 09:34:08AM -0500, Robert Raszuk wrote:
> To your point of assymetry ...
> 
> If the assymetry happens between clients placed in different rib groups of
> the given RS to corellate it is really ugly and breaks all today's code
> running as BGP route servers in the field.
> 
> Besides for say UDP streaming unidirectional connectivity is not that bad
> to withdraw reachability just because symmetry is not there.
> 
> Last most IX clients may have other connectivty outside of IX fabric in one
> or both directions so even TCP would work.

For posterity for the mailing list, Robert and I had this discussion
off-list.

In particular, this refers to the point covered in section 4.2 of the RS-BFD
draft.  This is where the route server may tell one peer about routes with a
given nexthop but not tell the other peer about *any* routes with the
nexthop for that first peer.  Since BFD requires a pair of endpoints over
which to provision a session, it is necessary for the route server to make
sure both sides are informed about both sides/nexthops even if routing only
advertises them one way.

> Bottom line I agree on the need to document as BCP NH tracking part of the
> draft between IX clients, but new SAFI seems to me not to be a best idea.
> 
> Best,
> R.
> 
> PS. If client does not support add-path it can use different sessions as
> described by RFC6774.

The RS-BFD proposal doesn't preclude other mechanisms for advertising
alternate paths.  I'd be interested in hearing about RS operators that have
any intentions of deploying BGP add-paths[1] or diverse paths.

-- Jeff

[1] It should be noted that add-paths is considered problematic in the
traditional eBGP route distribution scenario.
draft-pmohapat-idr-fast-conn-restore was originally drafted to address that
case for traditional service provider networks.  

> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 19 Apr 2017 12:12:31 +0300

> any intentions of deploying BGP add-paths[1] or diverse paths.

with RS operator hat on, add-paths is interesting; diverse paths less
so.  I'd deploy add-paths on the RS side if there were more client
support out there for it.  Right now, this is thin on the ground.

Nick

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 19 Apr 2017 16:16:25 +0200

Nick,

There could be not so many clients negotiating it with RS as they do not
know that RS supports it :) So why not enable it on RS side and let BGP
capabilities negotiation do the job ?

At least BIRD claims to support it for eBGP in add-paths implementation
report:

CZ.NIC         (iBGP) route reflector / RR client, *(eBGP) route
                server / RS client,* use cases where paths are
                distributed for other purposes than filling FIBs (like
                topology-aware CDNs).

I guess those clients who care to get all eligible paths will take
some actions to enable it on their side sooner then those which do not
care.

Cheers,
R.

---

From: Gert Doering <[email-masked]>
Date: Wed, 19 Apr 2017 16:31:29 +0200

Hi,

> support out there for it.  Right now, this is thin on the ground.

In the context of "unreachable next-hops" (blackhole in the fabric, or
issues with the remote router) add-paths alone isn't helping much, until
router implementations actually do liveliness detection for the next-hop,
falling back to the next path if the peer is not reachable.

Now, how can we get router vendors interested in providing that...?

(I'll happily settle for "if ARP or ND fails, consider the next-hop
unreachable", which is far superior to "just black-hole", and also
superior to "we have a very fancy mechanism that only works if both
sides implement the protocol")

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 20 Apr 2017 12:07:59 +0100

> capabilities negotiation do the job ?

We'll get to this at some stage and set up some proper testing.  At the
moment, we can see that no-one has enabled this client-side, which is at
least a safe default.

Nick