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

[<[e-mail]>]

> From: Job Snijders [mailto:[e-mail]]  > Sent: Friday, April 21, 2017 10:47 AM
> 
 > On Fri, Apr 21, 2017 at 07:32:29AM +0000, [e-mail] wrote:
 > > > From: John Scudder  Sent: Thursday, April 20, 2017 11:13 PM
 > > >
 > >  > (as an individual contributor)
 > >  >
 > >  > On Apr 20, 2017, at 5:03 PM, Enke Chen <[e-mail]> wrote:
 > >  > > It's not like the issues with software update are new :-)
 > >  >
 > >  > Yes, exactly. That's why I'm so surprised by this discussion.
 > >  >
 > >  > What I still see here is
 > >  >
 > >  > - on one hand, a worked example showing how an implementor could
 > >  > roll out the functionality without causing heartburn for users. (My
 > >  > paraphrase: expose the default in the configuration. When upgrading
 > >  > old->new, automatically create the corresponding configuration
 > >  > line(s) to configure for legacy behavior.)
 > >  >
 > >  > - on the other hand, general statements about how this is a hard problem.
 > >  >
 > >  > I find the specific worked example more convincing.
 > >
 > > Good point. Thanks for the useful contribution to the debate.
 > >
 > > a) Regarding this specific point, could the draft refer to this point.
 > > e.g. add this requirement (if this is a requirement draft, which it
 > > looks like it when reading the first sentence of section 2) or add the
 > > solution (space) (if the draft define a solution).
 > > e.g. "When the BGP speaker is upgraded to those new default behavior,
 > > existing BGP sessions, configured using the old default, must be
 > > unaffected". Or whatever text.
 > 
 > You are adding complexity and increasing inconsistency rather then
 > reducing it.

:s/adding/dealing with the

I guess that this means a "No" to my request.

 > > That is indeed the most significant deployment impact, so it's good
 > > that it can be addressed/included, rather than silently ignored.
 > >
 > > b) Still, this draft introduce new deployment impact to all network
 > > operators using EBGP, including the ones not concerned with this
 > > problem space, as provisioning tools need to be updated prior to this
 > > deployment, otherwise provisioning would fails. Plus silently fails as
 > > the session is kept up, silently ignoring the route with no feedback
 > > to the EBGP peer). Plus for each plateform, they need to selectively
 > > handle both configurations depending on the software version of this
 > > plateform.
 > 
 > 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.

 
 > For the record: NTT has many conditional clauses in their configuration
 > generation system to deal with configuration differences between
 > different versions of the software on the same platforms. This is
 > common. I do not believe you or anyone else operate your networks
 > without the accepting that different versions may have for example
 > different syntax.

I'm not saying that this is not possible. I'm saying that there is an impact, with associated cost and delay.
If possible, I'd prefer a solution which preserve the benefits while reducing the impacts. This requires that we all agree on the problems that we want to solve and the consequences of a proposed solution.

At the very minimum, 
"  o  A BGP speaker MAY provide a configuration option to disable the preceding behaviors, but it MUST implement them by default."
:s/MAY/MUST

But IMHO, we could discuss the "MUST implement them by default". As basically, the document is saying that the people facing the issue with their CLI, cannot even be asked to enable a one line knob in their configuration, while the document cannot even acknowledge and take into account the cost added on all other EBGP users.

Kind regards,
--Bruno
 
 > I've already stated how the failure scenario can only occur after a
 > missteps in the process, and that outages are likely to be remedied
 > swiftly and permanently. I've also contributed a case where bgp-reject
 > actually reduces the duration of outages that would otherwise be
 > caused and prolonged if an insecure mode of operation is used.
 > 
 > Kind regards,
 > 
 > Job

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.