Re: [Idr] comments on draft-ietf-idr-rs-bfd

[Gert Doering <[e-mail]>]

Hi,

On Tue, Aug 01, 2017 at 02:07:42PM +0100, Nick Hilliard wrote:
> -  the proposal allows rsclient A to influence reachability for their
> competitor, rsclient B.  This is a show-stopper in my books but other
> people may have different opinions.

How so?  A can communicate "*I* can not reach Z" (or "B").  

How's that interfering with B's reachability towards and from X, Y, Z?

[..]
> - the draft makes an implicit assumption that reachability between each
> rsclient is a ternary state, which it is not.  E.g. one of the most
> common ixp commutativity failure situations is where you have an
> ecmp/lag bundle between rsclient A and B, and a single member link dies,
> leading to partial failure between A and B.  If BFD and BGP work fine,
> then the IXP has just made a pronouncement that NH reachability is good,
> which it is not.  Awkward.

This situation is neither made better nor worse by this draft.

[..]
> - route server connectivity brokerage is generally considered to be the
> poor first cousin of bilateral connectivity over an IXP and the poor
> second cousin of a private network interconnection.  If an rsclient
> cares enough about its data flows that reachability is sufficiently
> important to justify being protected by BFD, then I'd argue that they
> should just do this rather than outsourcing the problem to someone else.
>  There are plenty of automation tools out there and it's not that hard
> to do.

Speaking as an operator and user of an IXP RS,  I value the service that
these RS bring to us.  "Plenty of automation tools" do not replace "not
having to deal with 100s of other IXP participants that cannot even get
e-mail right".

Right now, indirect reachability issues are an issue - not frequently,
but if they are, annoying and hard to see nonetheless.  Sending information
about these in an automated fashion to the IXP operator is a good thing
in my book.


> Please let's keep rs bfd brokerage as simple as possible. I don't want
> front-line ixp support issues to have to be dealt with by 3rd line
> engineering.

If your IXP does not want to offer this feature, then don't.

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: [phone]           USt-IdNr.: DE813185279