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

[Enke Chen <[e-mail]>]

Hi, Brian:

I think that the backward compatibility concern is more about existing
deployment. For example, say an existing router does not have an inbound
policy and just accepts whatever routes from its provider, but it does 
have an outbound policy.  Let us further assume that the default behavior
in the software is to accept updates from a neighbor without an inbound
policy. 

Assume in the new code the default behavior is changed to drop updates from
a neighbor without an inbound policy.  Then as soon as the new software
is deployed on that router, the updates from the provider would be dropped
without any config changes.

Thanks.  -- Enke

On 4/19/17 7:01 PM, Brian Dickson wrote:
> Hi, everyone,
> 
> I think the distinction is between "default" and "default", i.e. clearly communicating what is meant by "default" in this document.
> 
> I think it would be perfectly fine for implementers to provide copious "release notes" detailing what has changed, AND to apply whatever policy gunk is necessary, on performing a software upgrade, to ensure no adverse effects.
> 
> In other words, "default" here would mean the out-of-the-box behavior of an otherwise unconfigured device, when BGP is enabled (regardless of AFI/SAFI combinations).
> 
> By definition, a new deployment of a router can't cut off connectivity, since it cannot come into existence with said connectivity.
> 
> Would making that distinction suffice, for everyone?
> 
> Brian
> 
> P.S. While I do applaud the vendor(s) for finally deciding not to break things when code gets upgraded, separating upgrade from new deploy is all that is required.
> 
> On Wed, Apr 19, 2017 at 4:34 PM, Enke Chen <[e-mail] <mailto:[e-mail]>> wrote:
> 
>     John,
> 
>     I had "in this case" with the statement "the default can not be changed".
>     The reason is that the behavior change may completely cutoff connectivity
>     in this case.
> 
>     Thanks.  -- Enke
> 
>     On 4/19/17 4:25 PM, John Scudder wrote:
>     > (As an individual contributor)
>     >
>     > On Apr 19, 2017, at 7:18 PM, Acee Lindem (acee) <[e-mail] <mailto:[e-mail]>> wrote:
>     >> the draft is conspicuously missing a “Backwards Compatibility” section.
>     >
>     > Seriously? "Backwards compatibility" in this case is "configure your router to do what it used to", right? We need a section to say that?
>     >
>     > I must be missing something.
>     >
>     > Also, to Enke's "we can't ever change our defaults" point -- there are many RFCs. Some you probably comply with. Some you probably don't. How would this be different, assuming you elect not to change your implementation to comply?
>     >
>     > Thanks,
>     >
>     > --John
>     >
> 
>     _______________________________________________
>     Idr mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/idr <https://www.ietf.org/mailman/listinfo/idr>
> 
>