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: Mikael Abrahamsson [mailto:[e-mail]]  > Sent: Tuesday, April 25, 2017 11:42 AM
> 
 > On Tue, 25 Apr 2017, [e-mail] wrote:
 > 
 > > My reading would be "Implementations which by default advertise all
 > > their BGP routes over an EBGP session plus have a CLI not allowing the
 > > EBGP session and its associated policy to be configured atomically
 > > create frequent involuntary route leaks in the Internet, including in
 > > the absence of any configuration error. Possibly, this may be only one
 > > part of the problem, but here would be a good document to explicit those
 > > operational issues. (rather than complying that IDR do not listen to
 > > operational feedback)
 > 
 > https://tools.ietf.org/html/rfc7908 already documents the problem with
 > "route leaks". What you're asking for is as far as I can tell already
 > documented there.

If the problem is route leak (which is indeed a problem to solve):
- draft-ietf-grow-bgp-reject is unfortunately not a solution to route leak. There is nothing to check/unsure that the route advertised/received are the "right" ones.
-  IDR is already working on solutions which seem to have a better coverage. e.g. latest IDR meeting:

     2) Route Leak Prevention using Roles in Update and Open messages [Alexander Azimov/Randy Bush] (10) 
     https://datatracker.ietf.org/doc/draft-ymbk-idr-bgp-open-policy/
     
     3) Route Leak Detection and Mitigation [Sriram] (10)
     https://tools.ietf.org/html/draft-ietf-idr-route-leak-detection-mitigation-06   


So if the problem is route leak, draft-ymbk-idr-bgp-open-policy seems a better solution to me.
Eventually, it could include some idea from draft-ietf-grow-bgp-reject. .e.g.  by introducing a  "semi-strict mode" or "safe mode": if set, and if the "role" capability is not received from the peer, then EBGP speaker MUST behave has per bgp-reject (i.e. not advertising/receiving routes, unless a policy is explicitly configured)

Thanks,
Regards,
--Bruno

 
 > Perhaps not the *WHY* (as in operator error in configuring things
 > correctly), but that's exactly what draft-ietf-grow-bgp-reject is about.
 > 
 > --
 > Mikael Abrahamsson    email: [e-mail]

_________________________________________________________________________________________________________________________

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.