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

[Job Snijders <[e-mail]>]

On Sat, Apr 29, 2017 at 05:20:25AM -0400, Robert Raszuk wrote:
> > but vendors should do their best to ameliorate the risks with loud
> > warnings.
> 
> Indeed ...
> 
> There is also proposed option to significantly reduce the risk by
> changing this default only to protect from becomig an accidental
> transit I suggested in this thread already.
> 
> It is simple to implement by vendors, does not require any protocol
> change and does not affect in any way stub guys which today advertise
> their PI prefix out and get default in.

draft-ietf-grow-bgp-reject is just as simple (or as hard) to implement. 

More to this point of allowing ^$ and nothing else, it does not help
against origin-washing (EBGP->IGP->EBGP), and it does not provide for a
consistent experience like the current proposals do. I would also like
to note that while some people may have just their supernets in BGP,
others might have hundreds of thousands of /32s for VMs. There is no
justification as to why it is more desirable to make it easy for someone
to spill their internal guts rather then project them. The very same
arguments apply for both the 'dont accidentally become transit' as 'dont
accidentally announce things you didnt explicitly want to announce'.
There is no new argument here.

You can keep mangling the bgp-reject idea, but in the end we do not know
what all use-cases are, so we cannot accomodate one and not the other,
therefore the only logical outcome is that you ensure that in all cases
there is consistent and safe behavior.

> Which btw they must already explicitely enumerate either in "network"
> statement or "route/prefix-map" during redistribution. Why to enforce
> same thing to be configured multiple times in your config ? That is
> always error prone.

Yes, the platform you are referring to has more then one pitfall. Please
talk to your vendor's account manager to help build a case for this
enhancement request.

Kind regards,

Job