Subject: 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

From: Job Snijders <[email-masked]>
Date: Mon, 1 May 2017 15:23:44 +0200

On Sat, Apr 29, 2017 at 01:30:26PM +0900, Randy Bush wrote:
> but ignoring broken analogies and to the point, in the case of this
> draft, the operator is in definite danger of a major oops (that's a
> technical term) when field upgrading the software in a router.
> 
> despite this exposure, i am mostly of the opinion that the benefits
> outweigh the risks with this draft.  but vendors should do their best to
> ameliorate the risks with loud warnings.

In addition to warnings, perhaps some inspiration can be drawn from the
deprecation of SSHv1 in OpenSSH. This too required a process that
spanned several years (and isn't finished yet, since distributions
haven't yet incorporated the latest upstream version of OpenSSH, but
alas). If OpenSSH can do it, so can others! :-)

First: http://undeadly.org/cgi?action=article&sid=20150324200217
Then: http://undeadly.org/cgi?action=article&sid=20170501005206

Considerations of others regarding SSHv1:

    PuTTY: http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/no-ssh1-fallback.html
    Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=807107

Kind regards,

Job

---

From: Job Snijders <[email-masked]>
Date: Mon, 1 May 2017 20:37:27 +0200

On Sat, Apr 29, 2017 at 05:20:25AM -0400, Robert Raszuk wrote:
> > but vendors should do their best to ameliorate the risks with loud
> > warnings.
> 
> Indeed ...
> 
> There is also proposed option to significantly reduce the risk by
> changing this default only to protect from becomig an accidental
> transit I suggested in this thread already.
> 
> It is simple to implement by vendors, does not require any protocol
> change and does not affect in any way stub guys which today advertise
> their PI prefix out and get default in.

draft-ietf-grow-bgp-reject is just as simple (or as hard) to implement. 

More to this point of allowing ^$ and nothing else, it does not help
against origin-washing (EBGP->IGP->EBGP), and it does not provide for a
consistent experience like the current proposals do. I would also like
to note that while some people may have just their supernets in BGP,
others might have hundreds of thousands of /32s for VMs. There is no
justification as to why it is more desirable to make it easy for someone
to spill their internal guts rather then project them. The very same
arguments apply for both the 'dont accidentally become transit' as 'dont
accidentally announce things you didnt explicitly want to announce'.
There is no new argument here.

You can keep mangling the bgp-reject idea, but in the end we do not know
what all use-cases are, so we cannot accomodate one and not the other,
therefore the only logical outcome is that you ensure that in all cases
there is consistent and safe behavior.

> Which btw they must already explicitely enumerate either in "network"
> statement or "route/prefix-map" during redistribution. Why to enforce
> same thing to be configured multiple times in your config ? That is
> always error prone.

Yes, the platform you are referring to has more then one pitfall. Please
talk to your vendor's account manager to help build a case for this
enhancement request.

Kind regards,

Job

---

From: "John G. Scudder" <[email-masked]>
Date: Thu, 4 May 2017 18:41:07 -0400

Hi All,

Below is my summary of this mail thread, FYI.

As I understand it the next steps will be for the GROW AD (Warren) in consultation with the GROW chairs (Pete and Chris) to decide.

Thanks to all for your participation.

--John

The thread "[Idr] IETF LC for IDR-ish document <draft-ietf-grow-bgp-reject-05.txt> (Default EBGP Route Propagation Behavior Without Policies) to Proposed Standard" started on April 19 and by May 1 had accumulated well over a hundred messages from 27 or so contributors.

The thread defies a simple declaration of "there was consensus". However, and somewhat to my surprise, after reading back through the history and trying to give special attention to issues opened but subsequently rebutted, I think we do have consensus supporting advancement. 

There was quite a bit of discussion about the intended status of the document -- Standards Track vs. Informational vs. BCP, Updates 4271 or not. In the end, I think the best we can really say is that there was no consensus to choose something other than what the doc currently says. I've counted those who had document status objections under "con".

If it were up to me to call consensus (which it is not) I would say there is rough consensus to advance the document on the Standards Track, updating 4271. I might consider offering a few extra days of LC for editorial comments *only*, with discussion of the document status and general outline and features of the solution being placed explicitly out of scope. This is because there were, interspersed among the many other comments, a few editorial ones, and I just don't have the energy to figure out if they were all taken in (although I think the authors have been fairly diligent about this). It's also because the most recent versions of the document have some fairly significant changes compared to -05. 

Several issues were raised and discussed as part of the thread, including (but not limited to, I'm under no illusions that I've captured or even fairly represented every single point):

1. A number of people, largely from router vendors, expressed concern that changing defaults is difficult. These ranged from saying it was impossible, to merely difficult and not worth it. In response to this, others (including but not limited to other vendor folk) provided examples for how a default could be changed without invoking a flag day. Greg Hankins, in particular, provided a detailed explanation of his company's process. The proponents of "it's hard to change defaults" didn't follow up to the various rebuttals, so on the balance I would have to say they're "in the rough". It's a bit dicey to make this call since failure to follow up can also reflect simple fatigue, but in this case the conversation doesn't just tail off, it ends with concrete arguments on the "this can be done" side.

2. Related, there is the position that "yes of course anything can be done in software but the cost/benefit ratio isn't right". This is clearly a matter of personal taste so can't be dismissed (or supported) solely on the basis of logic. 

3. Should the behavior be per-AFI/SAFI instead of global? Perhaps to apply only to Internet routing and not other applications?
Pro: the motivation section of the document calls out the Internet use case
Con: there's no clear, unambiguous way to actually specify this (AFI/SAFI 1/1 can be used in a VPN context, e.g.). different defaults for different AFI/SAFI is confusing for the user and the extra complexity not required.

4. How about "default no-propagate" rather than "default no-advertise"?
Pro: Keeps CE configurations more compact, less surprising behavior.
Con: Behavior is actually more surprising (since harder to explain, less consistent). Doesn't cover all plausible use cases.

5. These defaults will hurt some deployments that want to rely on the old defaults. Examples, data centers, CEs.
Pro: as stated.
Con: it seems unlikely anyone is actually relying on default behavior in their data center, since defaults vary between vendors, can any examples be brought forward? None offered, instead a couple DC operators stated support for the draft as written. For CEs, discussion around upgrade strategies without breaking existing deployments, see #1.

6. This should not update 4271, not be Standards Track, it should be a BCP, should be Informational, etc.
Pro: It's not protocol, but just defaults, doesn't affect state machine, wire encoding.
Con: Plenty of Standards Track documents specify defaults when considered important to operation of protocol, and even more ephemeral things such as textual encodings.
Pro: It should be a BCP and/or shouldn't update 4271 because it's bad to make existing implementations nonconformant.
Con: Formally, it doesn't work that way. Also, the point is to ask implementations to change.

7. There are various other proposals to mitigate route leaks and provide BGP security features.
Pro: implied, "we've already got one"
Con: some of these are still in flight, not even WG docs. None address exactly the same issues. Some don't even overlap.

8. Why not just do perfect filtering at the service provider border? It's an education problem!
Pro: perfect filtering prevents harm from route leaks.
Con: decades of experience indicate strategies that require perfection are not successful.

Taking a rough head count, here's here I understand people's positions to have ended up:

Commented, no discernible position on advancing the doc -- 2

chris morrow
alvaro retana

Pro -- 16

john scudder
randy bush
brian dickson
joe provo
warren kumari
jared mauch
job snijders
gert doering
mik abrahamson
jeff haas -- support, though would prefer BCP
greg hankins
nick hilliard
jay borkenhagen
ian dickinson
martijn schmidt
keyur patel

Con -- On procedural grounds (should be a BCP, or should be Informational) -- 3

eric rosen -- would be OK as Informational, opposes other statuses
tony przygienda -- it should be a BCP
enke chen -- fine if it's a BCP. changing defaults is infeasible ("in the rough")

Con -- In the rough -- 2

acee lindem -- contrary to auto-discovery (rebutted, in the rough), should have a 'backwards compatibility' section
jeff tantsura -- changing defaults "can not be changed". -- in the rough

Con -- Other objections, in most cases not explicitly stated as opposing advancement but that's my reading of their mood -- 4

robert raszuk -- not explicitly, but has raised numerous "but what about...", all or most replied to
alex azimov -- 'it'll just result in empty policy' and 'route leaks are rare anyway', both later rebutted and not replied (so, "in the rough")
tom petch -- not explicitly, but generally skeptical tone to comments. specifically requested an analysis of what harms the proposal might cause. (not done or replied to AFAIK)
bruno decraene -- would rather improve route-leak draft, numerous other points and suggestions, mostly replied to, too much to summarize

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 5 May 2017 05:34:51 -0400

Hi John,

If someone make a point of the discussion and stops arguing about it ib
next 100 emails does not mean that the rough consensus was reached on his
or her comment.

Honestly to me I do not see that rough consensus to adopt this change as
standard track document has been reached on IDRWG mailing list.

Moreover document does not define what policy is. Is accepting ORF a policy
or not ? No clarity will lead to very inconsistent implementations.

Cheers,
R.

PS I uderstand that forcing inbound policy is to push folks to apply BCP38.
But this at best is applicable only at the ISP inbound side ....

On May 5, 2017 12:41 AM, "John G. Scudder" <[email-masked]> wrote:

Hi All,

As I understand it the next steps will be for the GROW AD (Warren) in
consultation with the GROW chairs (Pete and Chris) to decide.

--John

The thread "[Idr] IETF LC for IDR-ish document
<draft-ietf-grow-bgp-reject-05.txt>
(Default EBGP Route Propagation Behavior Without Policies) to Proposed
Standard" started on April 19 and by May 1 had accumulated well over a
hundred messages from 27 or so contributors.

The thread defies a simple declaration of "there was consensus". However,
and somewhat to my surprise, after reading back through the history and
trying to give special attention to issues opened but subsequently
rebutted, I think we do have consensus supporting advancement.

There was quite a bit of discussion about the intended status of the
document -- Standards Track vs. Informational vs. BCP, Updates 4271 or not.
In the end, I think the best we can really say is that there was no
consensus to choose something other than what the doc currently says. I've
counted those who had document status objections under "con".

If it were up to me to call consensus (which it is not) I would say there
is rough consensus to advance the document on the Standards Track, updating
4271. I might consider offering a few extra days of LC for editorial
comments *only*, with discussion of the document status and general outline
and features of the solution being placed explicitly out of scope. This is
because there were, interspersed among the many other comments, a few
editorial ones, and I just don't have the energy to figure out if they were
all taken in (although I think the authors have been fairly diligent about
this). It's also because the most recent versions of the document have some
fairly significant changes compared to -05.

Several issues were raised and discussed as part of the thread, including
(but not limited to, I'm under no illusions that I've captured or even
fairly represented every single point):

1. A number of people, largely from router vendors, expressed concern that
changing defaults is difficult. These ranged from saying it was impossible,
to merely difficult and not worth it. In response to this, others
(including but not limited to other vendor folk) provided examples for how
a default could be changed without invoking a flag day. Greg Hankins, in
particular, provided a detailed explanation of his company's process. The
proponents of "it's hard to change defaults" didn't follow up to the
various rebuttals, so on the balance I would have to say they're "in the
rough". It's a bit dicey to make this call since failure to follow up can
also reflect simple fatigue, but in this case the conversation doesn't just
tail off, it ends with concrete arguments on the "this can be done" side.

2. Related, there is the position that "yes of course anything can be done
in software but the cost/benefit ratio isn't right". This is clearly a
matter of personal taste so can't be dismissed (or supported) solely on the
basis of logic.

3. Should the behavior be per-AFI/SAFI instead of global? Perhaps to apply
only to Internet routing and not other applications?
Pro: the motivation section of the document calls out the Internet use case
Con: there's no clear, unambiguous way to actually specify this (AFI/SAFI
1/1 can be used in a VPN context, e.g.). different defaults for different
AFI/SAFI is confusing for the user and the extra complexity not required.

4. How about "default no-propagate" rather than "default no-advertise"?
Pro: Keeps CE configurations more compact, less surprising behavior.
Con: Behavior is actually more surprising (since harder to explain, less
consistent). Doesn't cover all plausible use cases.

5. These defaults will hurt some deployments that want to rely on the old
defaults. Examples, data centers, CEs.
Pro: as stated.
Con: it seems unlikely anyone is actually relying on default behavior in
their data center, since defaults vary between vendors, can any examples be
brought forward? None offered, instead a couple DC operators stated support
for the draft as written. For CEs, discussion around upgrade strategies
without breaking existing deployments, see #1.

6. This should not update 4271, not be Standards Track, it should be a BCP,
should be Informational, etc.
Pro: It's not protocol, but just defaults, doesn't affect state machine,
wire encoding.
Con: Plenty of Standards Track documents specify defaults when considered
important to operation of protocol, and even more ephemeral things such as
textual encodings.
Pro: It should be a BCP and/or shouldn't update 4271 because it's bad to
make existing implementations nonconformant.
Con: Formally, it doesn't work that way. Also, the point is to ask
implementations to change.

7. There are various other proposals to mitigate route leaks and provide
BGP security features.
Pro: implied, "we've already got one"
Con: some of these are still in flight, not even WG docs. None address
exactly the same issues. Some don't even overlap.

8. Why not just do perfect filtering at the service provider border? It's
an education problem!
Pro: perfect filtering prevents harm from route leaks.
Con: decades of experience indicate strategies that require perfection are
not successful.

Taking a rough head count, here's here I understand people's positions to
have ended up:

chris morrow
alvaro retana

Pro -- 16

john scudder
randy bush
brian dickson
joe provo
warren kumari
jared mauch
job snijders
gert doering
mik abrahamson

Con -- On procedural grounds (should be a BCP, or should be Informational)
-- 3

eric rosen -- would be OK as Informational, opposes other statuses
tony przygienda -- it should be a BCP
enke chen -- fine if it's a BCP. changing defaults is infeasible ("in the
rough")

Con -- In the rough -- 2

acee lindem -- contrary to auto-discovery (rebutted, in the rough), should
have a 'backwards compatibility' section
jeff tantsura -- changing defaults "can not be changed". -- in the rough

Con -- Other objections, in most cases not explicitly stated as opposing
advancement but that's my reading of their mood -- 4

robert raszuk -- not explicitly, but has raised numerous "but what
about...", all or most replied to
alex azimov -- 'it'll just result in empty policy' and 'route leaks are
rare anyway', both later rebutted and not replied (so, "in the rough")
tom petch -- not explicitly, but generally skeptical tone to comments.
specifically requested an analysis of what harms the proposal might cause.
(not done or replied to AFAIK)
bruno decraene -- would rather improve route-leak draft, numerous other
points and suggestions, mostly replied to, too much to summarize
_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

---

From: Jared Mauch <[email-masked]>
Date: Fri, 5 May 2017 11:50:43 -0400

> standard track document has been reached on IDRWG mailing list.

	(Not touching the above).

> or not ? No clarity will lead to very inconsistent implementations.

	We already have inconsistent implemencations.  Requring an
operator to do something is not a high bar to clear.  If vendors require
additional guidance here beyond the existing yang or openconfig models
I'm welcome to discuss offline with them, but this doesn't seem to be
related to the summary.

	- jared

-- 
Jared Mauch  | pgp key available via finger from [email-masked]
clue++;      | http://puck.nether.net/~jared/  My statements are only mine.

---

From: Warren Kumari <[email-masked]>
Date: Fri, 5 May 2017 13:00:26 -0400

[ + Alvaro, explicitly ]
The way that (rough) consensus is judged in the IETF is not when
everyone is happy, but when people have had a chance to raise their
issues, have them discussed and considered.

This LC generated a *significant* amount of discussion, and a large
amount of back and forth The issues were, IMO discussed and
considered, and some text added / changed to address the discussion.
John's judgement of consensus is not his alone; I (as the GROW AD)
viewed there as being **rough** consensus; I discussed this with
Alvaro (as IDR AD) who concurred. John provided a really helpful
summary which he shared with us - I used this to confirm my view, and
I asked him to provide to the list.

This is clearly not unanimous/ not everyone is happy, but (in my view)
there is *rough* consensus for this to progress.

The authors are still integrating final edits / word smithing and will
post a new version shortly.

W

On Fri, May 5, 2017 at 5:34 AM, Robert Raszuk <[email-masked]> wrote:
> Hi John,
>
> If someone make a point of the discussion and stops arguing about it ib next
> 100 emails does not mean that the rough consensus was reached on his or her
> comment.
>
> <draft-ietf-grow-bgp-reject-05.txt> (Default EBGP Route Propagation Behavior
> Without Policies) to Proposed Standard" started on April 19 and by May 1 had
> accumulated well over a hundred messages from 27 or so contributors.
>
> trying to give special attention to issues opened but subsequently rebutted,
> I think we do have consensus supporting advancement.
>
> If it were up to me to call consensus (which it is not) I would say there is
> rough consensus to advance the document on the Standards Track, updating
> to merely difficult and not worth it. In response to this, others (including
> but not limited to other vendor folk) provided examples for how a default
> could be changed without invoking a flag day. Greg Hankins, in particular,
> provided a detailed explanation of his company's process. The proponents of
> "it's hard to change defaults" didn't follow up to the various rebuttals, so
> on the balance I would have to say they're "in the rough". It's a bit dicey
> to make this call since failure to follow up can also reflect simple
> fatigue, but in this case the conversation doesn't just tail off, it ends
> with concrete arguments on the "this can be done" side.
>
> alex azimov -- 'it'll just result in empty policy' and 'route leaks are rare
> anyway', both later rebutted and not replied (so, "in the rough")

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Enke Chen <[email-masked]>
Date: Fri, 5 May 2017 14:38:53 -0700

Hi, Folks:

I still believe that the draft is BCP material. In addition, I would like see several
points (raised by Robert R and others) addressed in the draft:

1) Inbound filter on the CE:

   Requiring inbound filtering makes sense for the providers, and I believe that
   is the common practice.  But it is not needed and has little to do with route
   leaking on the CE side.  Currently for the customers that receive full routes
   or partial routes from their providers, there is no need for inbound filters
   (and no rational way to generate such a filter in many cases) and they are not
   used in many cases.

   The draft should document these facts about the inbound filter.

2) ORF:

   Certainly it would be just as effective as "outbound filtering" if a customer
   registers its prefixes with IRR and then relies on receiving the ORF (from its
   provider) generated from the IRR.

   This should be noted in the draft.

3) Policy definition

   Again as pointed out many times, would "permit all" considered as an acceptable
   policy?  Such policy does nothing or very little to help route leaking reduction.

   This should also be noted in the draft.

Regards,  -- Enke

On 5/5/17 2:34 AM, Robert Raszuk wrote:
> Hi John,
> 
> If someone make a point of the discussion and stops arguing about it ib next 100 emails does
> not mean that the rough consensus was reached on his or her comment.
> 
> Honestly to me I do not see that rough consensus to adopt this change as standard track
> document has been reached on IDRWG mailing list.
> 
> Moreover document does not define what policy is. Is accepting ORF a policy or not ?
> No clarity will lead to very inconsistent implementations.
> 
> Cheers,
> R.
> 
> PS I uderstand that forcing inbound policy is to push folks to apply BCP38. But this at best is applicable only at the ISP inbound side ....
> 
> On May 5, 2017 12:41 AM, "John G. Scudder" <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Hi All,
> 
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/listinfo/idr <https://www.ietf.org/mailman/listinfo/idr>
> 
> 
> 
>

---

From: Brian Dickson <[email-masked]>
Date: Fri, 5 May 2017 15:07:25 -0700

Top-reply, to make it easy to read the summary responses. I speak only for
myself, of course.

1) CE - either existing CE stuff can handle this during upgrades (qv
discussion about upgrade vs out-of-the-box), and/or suitable warnings.
Use of "permit all" policy achieves the desired effect on CE, and satisfies
the requirements of this standard.

2) ORF - there is no guarantee that ORF is configured or present, and
cannot be checked prior to bringing up BGP. Thus, "No." Just, no, ORF is
not adequate for this.

3) Yes, permit all would be sufficient. All that is needed is an *explicit*
policy, regardless of what it is.

This all can be expressed by the difference between two mathematical
comparisons:
X>=0
X>0

If X is the place-holder for "policy", and "0" means no policy is
configured, all that is required is ANY value of X which is not 0.

There is no minimum positive value for "X", in other words - just as long
as it is not 0.

There is no requirement that the same rules be used by any given
implementation. There is no interoperability requirement, as these are all
local (implementations and policies configured).

The "X>0" must be a forcing function, so BCP is not sufficient.

That is the intent and purpose of "-reject".

Respectfully,

Brian

On Fri, May 5, 2017 at 2:38 PM, Enke Chen <[email-masked]> wrote:

> next 100 emails does
> standard track
> > PS I uderstand that forcing inbound policy is to push folks to apply
> BCP38. But this at best is applicable only at the ISP inbound side ....
> >
> >     As I understand it the next steps will be for the GROW AD (Warren)
> in consultation with the GROW chairs (Pete and Chris) to decide.
> >
> <draft-ietf-grow-bgp-reject-05.txt> (Default EBGP Route Propagation
> Behavior Without Policies) to Proposed Standard" started on April 19 and by
> May 1 had accumulated well over a hundred messages from 27 or so
> contributors.
> >
> >     The thread defies a simple declaration of "there was consensus".
> However, and somewhat to my surprise, after reading back through the
> history and trying to give special attention to issues opened but
> subsequently rebutted, I think we do have consensus supporting advancement.
> >
> >     If it were up to me to call consensus (which it is not) I would say
> there is rough consensus to advance the document on the Standards Track,
> updating 4271. I might consider offering a few extra days of LC for
> editorial comments *only*, with discussion of the document status and
> general outline and features of the solution being placed explicitly out of
> scope. This is because there were, interspersed among the many other
> comments, a few editorial ones, and I just don't have the energy to figure
> out if they were all taken in (although I think the authors have been
> fairly diligent about this). It's also because the most recent versions of
> the document have some fairly significant changes compared to -05.
> >
> >     Several issues were raised and discussed as part of the thread,
> including (but not limited to, I'm under no illusions that I've captured or
> even fairly represented every single point):
> >
> >     1. A number of people, largely from router vendors, expressed
> concern that changing defaults is difficult. These ranged from saying it
> was impossible, to merely difficult and not worth it. In response to this,
> others (including but not limited to other vendor folk) provided examples
> for how a default could be changed without invoking a flag day. Greg
> Hankins, in particular, provided a detailed explanation of his company's
> process. The proponents of "it's hard to change defaults" didn't follow up
> to the various rebuttals, so on the balance I would have to say they're "in
> the rough". It's a bit dicey to make this call since failure to follow up
> can also reflect simple fatigue, but in this case the conversation doesn't
> just tail off, it ends with concrete arguments on the "this can be done"
> side.
> >
> >     2. Related, there is the position that "yes of course anything can
> be done in software but the cost/benefit ratio isn't right". This is
> clearly a matter of personal taste so can't be dismissed (or supported)
> solely on the basis of logic.
> >
> >     3. Should the behavior be per-AFI/SAFI instead of global? Perhaps to
> apply only to Internet routing and not other applications?
> >     Con: there's no clear, unambiguous way to actually specify this
> (AFI/SAFI 1/1 can be used in a VPN context, e.g.). different defaults for
> different AFI/SAFI is confusing for the user and the extra complexity not
> required.
> >
> >     Con: Behavior is actually more surprising (since harder to explain,
> less consistent). Doesn't cover all plausible use cases.
> >
> >     5. These defaults will hurt some deployments that want to rely on
> the old defaults. Examples, data centers, CEs.
> >     Pro: as stated.
> >     Con: it seems unlikely anyone is actually relying on default
> behavior in their data center, since defaults vary between vendors, can any
> examples be brought forward? None offered, instead a couple DC operators
> stated support for the draft as written. For CEs, discussion around upgrade
> strategies without breaking existing deployments, see #1.
> >
> >     Con: Plenty of Standards Track documents specify defaults when
> considered important to operation of protocol, and even more ephemeral
> things such as textual encodings.
> >     Pro: It should be a BCP and/or shouldn't update 4271 because it's
> bad to make existing implementations nonconformant.
> >     Con: some of these are still in flight, not even WG docs. None
> address exactly the same issues. Some don't even overlap.
> >
> >     acee lindem -- contrary to auto-discovery (rebutted, in the rough),
> should have a 'backwards compatibility' section
> >     Con -- Other objections, in most cases not explicitly stated as
> opposing advancement but that's my reading of their mood -- 4
> >
> >     alex azimov -- 'it'll just result in empty policy' and 'route leaks
> are rare anyway', both later rebutted and not replied (so, "in the rough")
> >     tom petch -- not explicitly, but generally skeptical tone to
> comments. specifically requested an analysis of what harms the proposal
> might cause. (not done or replied to AFAIK)
> >     bruno decraene -- would rather improve route-leak draft, numerous
> other points and suggestions, mostly replied to, too much to summarize
> >     https://www.ietf.org/mailman/listinfo/idr <
> https://www.ietf.org/mailman/listinfo/idr>
> >
> >
> >
> >

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Fri, 5 May 2017 22:09:20 +0000

Even if violating router-os's are updated, leaks will continue for a long time.
I hope I can help on the filtering side. No RFC or vendor code change required.

I wrote an app in C that takes the output of "show bgp" and creates
a set of route-policies that will prevent the leaks.
It looks at the as-paths, finds your neighbors and then all their upstreams.
Then it writes as-path policies to allow only those upstreams for your neighbors.
You then use the policy in your neighbor inbound policies to either drop
or set a low localpref. There is a way to show the routes that are disallowed.
Sorry, it only works with Cisco.
The source is free for anyone to do whatever they want.
Other vendors can adapt it at will.

Compile it at a Linux command line; "cc showbgp2policy.c".
Sorry about the C, but python is not my mother tongue.
Start with num_policies of 30 and see how it looks.

Thanks,
Jakob.

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Fri, 5 May 2017 22:17:19 +0000

A router cannot tell the difference between upgrade and out-of-the-box in general.
Turn on an unconfigured router and then paste in an existing configuration.
That is an upgrade that looks like out-of-the-box.

Thanks,
Jakob.

From: Idr [mailto:[email-masked]] On Behalf Of Brian Dickson
Sent: Friday, May 05, 2017 3:07 PM
To: Enke Chen (enkechen) <[email-masked]>
Cc: idr wg <[email-masked]>; Robert Raszuk <[email-masked]>
Subject: 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

1) CE - either existing CE stuff can handle this during upgrades (qv discussion about upgrade vs out-of-the-box), and/or suitable warnings.
Use of "permit all" policy achieves the desired effect on CE, and satisfies the requirements of this standard.

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 6 May 2017 00:24:10 +0200

Hi Brian,

> Use of "permit all" policy achieves the desired effect on CE, and
> satisfies the requirements of this standard.
>

​And accomplishes nothing useful for BGP.

There is so many default we can change in all protocols which will
accomplish nothing other then getting new RFC then I see a lot of
opportunities for 100s of new drafts. ​

​Conclusion:​

​However I have reconsidered and changed my mind on this draft today. I
fully support ​it's publication as MUST DO IMMEDIATELY and to be proposed
standard and to update RFC4271.

What I have been missing till today is that this draft makes BGP harder to
configure and harder to use by vast majority of non transit ISP users.

And perhaps this is the real hidden beauty of it which is to discourage
users from using BGP as common application transport. Great doc !

Kind regards,
Robert.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sat, 6 May 2017 07:43:39 +0200 (CEST)

> That is an upgrade that looks like out-of-the-box.

Pasting in an existing configuration is out-of-the-box.

Booting an existing configuration that includes operating version that 
created it, means change of defaults can be managed by version migration 
code.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Alexander Azimov <[email-masked]>
Date: Mon, 8 May 2017 14:46:09 +0300

Hi John,

> rare anyway', both later rebutted and not replied (so, "in the rough")
Just in case: I meant to say that full table leaks are rare.

I do not oppose this draft - while I'm still not sure it will solve problem
of full table leaks, I like the concept, and I can see this proposal as
part of solution of general route leak problem.

But this brings next question: I hope that the meaning of "Import/Export
Policy was configured" is just *configured*, no matter by user or
automatically, am I right? (I'm trying to understand how it can stack with
BGP roles).

-- 
| Alexander Azimov  | HLL l QRATOR
| tel.: +7 499 241 81 92 <+7%20499%20241-81-92>
| mob.: +7 915 360 08 86 <+7%20915%20360-08-86>
| skype: mitradir
| mailto: [email-masked]
| visit: www.qrator.net

---

From: "John G. Scudder" <[email-masked]>
Date: Mon, 8 May 2017 08:11:07 -0400

#individual_contributor

> On May 8, 2017, at 7:46 AM, Alexander Azimov <[email-masked]> wrote:
> 
> I hope that the meaning of "Import/Export Policy was configured" is just configured, no matter by user or automatically, am I right? (I'm trying to understand how it can stack with BGP roles).

That's how I read it.

--John