Re: [Idr] IETF LC for IDR-ish document <draft-ietf-grow-bgp-reject-05.txt> (Default EBGP Route Propagation Behavior Without Policies) to Proposed Standard

[Jared Mauch <[e-mail]>]

On Wed, Apr 26, 2017 at 01:28:49PM +0200, Robert Raszuk wrote:
> Hi Gert,
> 
> Unless the result is not lost of connectivity but lost of BGP path
> redundancy from your AS.
> 
> It is quite often and in fact good idea to have dual vendors as your ASBRs.
> 
> So unless proper cli is automagically added the problem may only  surface
> weeks and months after upgrade and in fact far from given ASBR when
> external link from still operational ASBR breaks.
> 
> Document should discuss that as well and recommend such auto cli.

	I've only cited CLI as an example of how others have addressed
the concerns raised in the thread.  For the purpose of IDR I don't
wish to mandate that part of a solution, but cite other viable
operational alternatives.

	Saying that a BGP operator needs some "auto-cli" to know how
to do BGP stuff tells me these people should not be trusted with BGP
outside their own labs.

	The pollution here is real, when I was at NTT we worked to
mitigate it via a variety of methods.

	We also had executive escalations that reached my desk where people
didn't do their simple homework of "we had two links, redundancy
didn't work, you took us down big bad $ISP".  

	Once I said "Hi, you are only sending 2/3 of your routes on
your backup session, do you want to fix that now while I observe" they
quickly settled down on their escalation issues.

	Things break, people need to learn how to debug the technologies
they are using.  We should be working to make it simple, yes but not
by foregoing an operator developing their own skills to identify problems
and using their supported vendor paths to triage it.

	Putting text in the draft that it must take the form of
"show bgp neighbor 2001:db8::1 " would favor one vendor over another
and perhaps open the draft up to IPR claims.  I do not welcome these
suggestions.

	The reality is many of the operational leaks we see today are
because of one or multiple failures in the routing ecosystem, be it
a network link, NLRI filter, AS_PATH filter or otherwise.

	- Jared

-- 
Jared Mauch  | pgp key available via finger from [e-mail]
clue++;      | http://puck.nether.net/~jared/  My statements are only mine.