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

Job,

Let's face it ... your proposal in spite of all claims you are making does
nothing to prevent outages or route leaks.

Your examples of "accept all" or "send all" are clear prove of it.

Forcing any policy != forcing correct policy.

If someone cares about Internet stability he will implement correct policy
today without being forced by a vendor. If someone care less he will send
all and accept all just line it is today.

So let's not try to sell/sneak someting here under completely wrong label.
All this draft is about it is forcefull education for those customers who
do not know that bgp policy exist.

Kind regards,
R.

On Apr 21, 2017 11:58, "Job Snijders" <[e-mail]> wrote:

> On Fri, Apr 21, 2017 at 09:18:24AM +0000, [e-mail] wrote:
> >  >
> >  > So, going forward, any IDR proposal that requires a change to any
> >  > provision system is a no-go?
> >
> > It's not about a no-go. It's about understanding and considering the
> > tradeoffs.
>
> Bruno, through this thread I have learned:
>
>     - Release notes are not read, and it is unreasonable to expect
>       people to read them.
>     - Software will not be tested prior to deployment, not even to see
>       whether it boots.
>     - We cannot expected staggered software deployments, people will
>       upgrade all their BGP speakers at the same time (again, without
>       testing the software).
>     - Any change to a provisioning system is an insurmountable
>       imposition.
>
> I'm sure you appreciate how these new insights will affect all future
> IDR work. I assure you that if such weak rethoric continues to be
> admitted as valid justifications for lethargy, this will affect IDR's
> productivty the coming years.
>
> If you want to play the game of 'tradeoffs have to be made', I have not
> seen any appreciation in this thread for the cost on the Internet as a
> whole resulting from insecure defaults. Robert Raszuk even went as far
> to argue that we'd be doing the "little guys" (surely that was not meant
> in a belligerent way) a favor by allowing insecure defaults to persist.
>
> I theorize that for instance this outage was the result of a 'fail open'
> rather then 'fail closed' (as proposed in bgp-reject) implmentation
> choice. See https://www.theregister.co.uk/2015/06/12/level_3_down_after_
> routing_through_malaysia_like_idiots/
> or https://bgpmon.net/massive-route-leak-cause-internet-slowdown/
>
> Outages like these affect everyone, whether they were a directly
> involved party or indirectly involved. Did you notice this event in your
> own network? Or perhaps you did notice it because payment terminals in
> some countries stopped working?
>
> The BGP Default-Free Zone is composed of roughly 55,000 autonomous
> systems operated by as many organisations, who are densily
> interconnected with each other through milions of EBGP sessions. When DC
> equipment is connected to Internet, or when a CLI-style makes accidents
> easy, or when a lack of education results in a common misconfiguration,
> there should be checks and balances in place to dampen the negative
> effects on the Internet as a whole. The Internet Engineering Task Force
> (notice the 'Internet' in IETF) has a responsiblity to promote and
> define safe and secure default behaviours.
>
> Kind regards,
>
> Job
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>