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: Thursday, April 20, 2017 11:51 AM
> 
 > On Thu, Apr 20, 2017 at 09:40:50AM +0000, [e-mail] wrote:
 > > > From: Idr [mailto:[e-mail]] On Behalf Of Job Snijders  > Sent: Thursday,
 > April 20, 2017 11:10 AM
 > > >
 > >  > On Wed, Apr 19, 2017 at 04:34:10PM -0700, Enke Chen wrote:
 > >  > > 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.
 > >  >
 > >  > And very soon after the cutoff a customer may elect to roll back the
 > >  > change and read the release notes!
 > >  >
 > >  > The 'complete cutoff' only occurs after a specific sequence of events
 > >  > which together would represent a cascading failure in due diligence.
 > >
 > > The document is asking network operators which have correctly
 > > configured their network to retrofit the configuration of 1000s of
 > > EBGP configurations, in order to accommodate some operators which are
 > > not capable of correctly configuring their EBGP session.
 > 
 > No, the beneficiaries of this draft are the users of Internet at large,
 > not just 'incapable operators'.
 
My text was not discussing about beneficiaries, so I don't think that "No" applies.
 
 > It is ludicrous to argue that an operator has 1000s of EBGP
 > configurations but would not be able to accomodate any changes in the
 > software's behaviour.

That's your opinion, but you can't speak for others.
e.g. managing a few high bandwidth Internet connection, on a very few locations, is very different than managing 1000s of customers CE in 1000s of locations. Especially as breaking the connectivity would requiring sending a tech person on customer's site.

> A parallel can be drawn with the 'IOS
 > small-servers' which over time were disabled by default, rather then
 > enabled. I don't recall any outcry over that either.
 
It's not the same thing to disable a feature that is not used, than disabling a feature that is used and critical for the connectivity hence the business.
 
 > > Plus the solution is asking those later operators to do a
 > > configuration, while the assumption is that they can't be trusted to
 > > correctly configured their EBGP session. Why do you think that they
 > > won't just copy/past 1 additional line of configuration in order
 > > automatically distribute all the routes for each new EBGP session?
 > 
 > Ah, there may lay our misunderstaanding. We do not blame operators or
 > make any judgement on whether they can be trusted or not.

The point is not about blaming. The point if that if you don't trust X, you don't ask X to perform the check/policy insurance.
 
 > The problem is that there are some platforms which _immediately_
 > activate a line of configuration after you press enter

Here we comes.
If that is the problem, then may be this is the problem which needs to be solved.
Nothing related to BGP or even the IETF.

>, and a BGP
 > session may already come up before you get to the configuration line
 > which restricts what should be announced or accepted. This draft
 > rectifies that behaviour to 'start closed' (i guess this is a variant of
 > the "fail closed" concept) rather then 'start open', or differently
 > phrase: one should not start insecure.
 
If this is the problem, may be the CLI should first mandate for the BGP policy to be applied, and then allow the configuration of the peer (e.g. its IP address)
Again, not a protocol or IETF issue. (although netconf may help as I think it provide support for transaction)

Thanks for engaging the discussion and the useful chat.

Kind regards,
Bruno 
 > 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.