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

[Robert Raszuk <[e-mail]>]

Hi Jared,

So let's talk examples ... for my own education.

If you are provider and have 1000 multihomed customers with v4/v6 PI space.

Imagine you want to apply granular policy better then permit all on your
inbound.

How practically (considering that your customers get address block all the
time) you wilk track and adjust policy o  a daily basis ?

You need offline machinery when unless they log in and inform you their
routes will be denied. Moreover your backend must be able to check if
prefix does not belong to someone else .... Oh wait what if someone else
just sold it to them ?

With PA blocks policy works well ... with PI I think not so.

And if you are customer and have 4 prefixes in BGP table thing are fine. If
you by accident become transit and advertise fulm table around I think we
can do better in BGP to protect from it then mandate policy.

Cheers
R.

On Apr 26, 2017 7:39 AM, "Jared Mauch" <[e-mail]> wrote:

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