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 02:00:45PM +0200, Robert Raszuk wrote:
> 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 ?

	Proper machinery and automation.

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

	Sounds like a great market.  I've seen vendors attempt and
fail at this though.  They also assume vendor lock-in, provider lock-in
and other value additive things.  This is why people build their
own automation and abstraction layers.  This is what any provider with
many network elements to manage is doing today.

	There are still those people who do what I call cut+paste SDN
where they modify existing policy out of a device, from notepad.exe or
their vi buffer.  Emacs users have their own operating system to interact
with first.

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

	Works fine if you architect it correctly.

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

	Actually, providers mandate many things on their customers.
There's many other ways to address the broken behaviors, we have used
prefix-lists, as_path filters, max-prefix in an attempt to stop
the leakage.  It's still only mitigated most of the worst events and
covers up people who are behaving as an insecure BGP speaker.  It's some
mitigation, but the desire of operators is to do better.

	Like I said, at least one vendor has commented in private they
are working on fixing their behavior of their implementations.  This is a
good thing I am hoping will be visible in the measurements of routing leaks
in the coming years.

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

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