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:37 AM
> 
 > On Thu, Apr 20, 2017 at 09:32:44AM +0000, [e-mail] wrote:
 > > > From: Idr [mailto:[e-mail]] On Behalf Of Job Snijders  > Sent: Thursday,
 > April 20, 2017 11:06 AM
 > > >
 > >  > On Thu, Apr 20, 2017 at 01:30:13AM +0200, Robert Raszuk wrote:
 > >  > > ​John,
 > >  > >
 > >  > > ​>
 > >  > > How would this be different, assuming you elect not to change your
 > >  > > implementation to comply?
 > >  > >
 > >  > > ​Well if we are to standardize by rough consensus a RFC which we already
 > >  > > know is not going to be ​honored for the reasons clearly stated what are we
 > >  > > gaining ?
 > >  > >
 > >  > > BGP implementations which support inbound policy to accept any routes will
 > >  > > continue doing so .. and those which do not also will continue not to do
 > >  > > so.
 > >  > >
 > >  > > So what is the point ?
 > >  >
 > >  > Although I do not share your pessimistic view on what can and can't be
 > >  > done, at the very least it will provide guidance for new BGP
 > >  > implementations.
 > >
 > > This would work for me.
 > > Can the document be updated to reflect this?
 > 
 > Existing deployments are just that: existing deployments. It seems
 > superfluous to mention that compliance with the Internet-Draft might be
 > enforced only after a software upgrade. The same goes for many other
 > RFCs.

The question was whether this new default policy could be proposed (or imposed) as a BCP only for _new_ implementations.
And by new implementations, I mean new source code (e.g. RtBrick) not a software upgrade of an existing code.

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.