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 10:06 AM
> 
 > On Tue, 25 Apr 2017, [e-mail] wrote:
 > 
 > > > From: Mikael Abrahamsson [mailto:[e-mail]]  > Sent: Tuesday, April 25,
 > 2017 9:33 AM
 > >> On Tue, 25 Apr 2017, [e-mail] wrote:
 > > >
 > > > > If this is indeed the goal to make no protocol change, including no
 > > > > default behavior change in the protocol, could the document be updated
 > > > > to state this. In which case, Standard Track may be required.
 > > >
 > > > I re-read https://tools.ietf.org/html/draft-ietf-grow-bgp-reject-05
 > > >
 > > > As far as I can see, it doesn't do any protocol change. It changes the
 > > > default behaviour a router comes with when it comes to treating routes
 > > > sent/received when there is no policy map applied on the neighbor.
 > > >
 > > > So it suggest a behavioural change, not a protocol change.
 > >
 > > So we now have 3 readings:
 > > - protocol change updating RFC 4271 (base BGP spec)
 > 
 > Change? As far as I can see, 4271 has nothing on route-policy (just
 > reading the TOC). So it seems to me that this would be an addition, not a
 > change. Or am I mistaken? So this doesn't seem correct.
 > 
 > > - a behavioural change, not a protocol change
 > 
 > I agree with this.
 > 
 > > - no default behavior change in the protocol
 > 
 > Protocol, no. For me protocol is what goes on-wire, what goes into the
 > statemachine, route selection etc.
 > 
 > This is a change in what is the default policy when none is explicitly
 > configured. I can't find anything in 4271 that talks about this. So it's
 > not a change per se, it's an addition and it's more operational than
 > protocol change of behaviour.
 > 
 > So really, this is GROW stuff. It's not necessarily touching core BGP
 > protocol documents, unless we absolutely want to.
 > 
 > https://datatracker.ietf.org/wg/grow/about/
 > 
 > "(v). Document the operational aspects of securing the Internet routing
 > system, and provide recommendations to other WGs."

Looks good.
But this seems that this would call for an Informational document (vs STD track currently), providing _recommendations_ (i.e. not directly any protocol change) to IDR, and/or vendors, and/or operational community. 

e.g.
1) documenting the operational issues.
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)

2) propose recommendations
(e.g. 
- Implementations should support a mode where BGP routes are not advertised unless explicitly required by a route policy.
- As some configurations tasks may require multiple lines, Implementations should support a mode where multiple configurations items are configured atomically
- network operator operating on the Internet routing system should use/enable those 2 features.

 > So this is exactly what's happening as far as I can tell.
 > 
 > --
 > 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.