Subject: Re: [GROW] Working Group Adoption Call: draft-mauch-bgp-reject

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Tue, 1 Nov 2016 11:27:20 +0000

Thanks, Job, for the responses.

>I'd like to propose a different strategy and describe some background.
>Both of you mention per-peer flags or new per-route state flags, which
>in essence are updates to rfc4271, this feels like too heavy of a
>hammer.

The flags/markings are local to the router. Does not require any rfc4271 updates, IMO.
E.g. Origin validation (RFC 6811) marking is already implemented in commercial
routers and did not require rfc4271 update.

>NEW2:
>   "Software MUST discard any routes from an EBGP peer, if no import
>    policy was configured."

Sounds good to me.

Additionally, should there be an alert generated for the network operator.
The discard of routes happening quietly (while operator knows nothing about it) is not good.

Sriram

---

From: Job Snijders <[email-masked]>
Date: Tue, 1 Nov 2016 12:32:18 +0100

> >   "Software MUST discard any routes from an EBGP peer, if no import

I'll update the doc and incorporate this in -03. Thanks.

> Additionally, should there be an alert generated for the network
> operator.  The discard of routes happening quietly (while operator
> knows nothing about it) is not good.

An alert is overkill imho, can't have a system spew 600,000 alerts
because it rejected a full table feed.

I think this will be very hard to capture in a spec. Some
implementations remain silent (yeah not ideal), other implementations
show a default policy (example: "REJECT") applied on a neighbor in "show
neighbor xxx"-style commands if there is no policy configured.

Kind regards,

Job

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Tue, 1 Nov 2016 11:50:57 +0000

>because it rejected a full table feed.

I was thinking one single configuration error message for each neighbor 
for which ingress or egress policy has not been set. 

I think the draft can be adopted (now) and these details can be worked in later 
during WG deliberations on this draft.

Sriram

---

From: Job Snijders <[email-masked]>
Date: Tue, 1 Nov 2016 12:57:03 +0100

On Tue, Nov 01, 2016 at 11:50:57AM +0000, Sriram, Kotikalapudi (Fed) wrote:
> I was thinking one single configuration error message for each
> neighbor for which ingress or egress policy has not been set. 

What if it is intentional? Why consider it an error? 

I see no benefit, and it would make the draft non-compatible with
existing deployments aligned with the spirit of this draft. I don't see
how 'one sentence' will benefit the ultimate goal of this draft. Leave
that to the vendors.

> I think the draft can be adopted (now) and these details can be worked
> in later during WG deliberations on this draft.

The draft was adopted December 28th 2015. :)

Kind regards,

Job

---

From: "Hankins, Greg (Nokia - US)" <[email-masked]>
Date: Tue, 1 Nov 2016 08:43:19 -0400

>how 'one sentence' will benefit the ultimate goal of this draft. Leave

Agreed, speaking with my vendor hat on, let's please leave these kind of
implementation details to the implementer.  These are the kind of things
that I would define in an internal functional design specs.

Greg

--
Greg Hankins <[email-masked]>

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 1 Nov 2016 11:07:19 -0400

On Sun, Oct 30, 2016 at 05:10:01PM +0100, Job Snijders wrote:
> Brian, Sriram, others,
> I'd prefer to make the document compatible with existing deployments of
> software which is already compliant with the spirit of this document.
> 
> OLD:
>     Software MUST mark any routes from an EBGP peer as 'invalid' in the
>     Adj-RIB-In, if no import policy was configured.
> 
> NEW:
>     Software MUST consider any routes from an EBGP peer as invalid, if
>     no import policy was configured.
> 
> NEW2:

I rather object to NEW2 and, if included, withdraw any support of this
draft.

A fundamental issue with this behavior is that it dumps routes that would
have to be recovered via expensive refresh.

If any implementation wants to do this, I don't object, but it shouldn't be
mandatory.

FWIW, I still haven't evaluated our own software under the prior version of
the draft, but think it's a generally good idea.

-- Jeff

---

From: Job Snijders <[email-masked]>
Date: Tue, 1 Nov 2016 17:23:38 +0100

On Tue, Nov 01, 2016 at 11:07:19AM -0400, Jeffrey Haas wrote:
> A fundamental issue with this behavior is that it dumps routes that
> would have to be recovered via expensive refresh.

Am I correct to understand that the word 'discard' has very specific
meaning in this context? Does "discard" mean "forbidden to store in
memory"?

Sriram, I believe you were the first to raise a concern about the "OLD"
text, do you have a preference for "NEW2" or strongly object to "NEW"?
If the latter, can you help bridge the gap between intended meaning
implementation consequences?

Or perhaps: NEW3: "Software MUST ignore any routes from an EBGP peer, if
no import policy was configured." ?

> FWIW, I still haven't evaluated our own software under the prior
> version of the draft, but think it's a generally good idea.

I look forward to your evaluation!

Kind regards,

Job

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 1 Nov 2016 12:30:47 -0400

> meaning in this context? Does "discard" mean "forbidden to store in

Discard traditionally means "to throw away".  To put into familiar context,
"keep none" with policy reject. 

If you're just looking for "you can't use this without import policy
specified", you want something along the lines of:

In the absence of configured import policy, BGP routes are ineligible for
route selection. (RFC 4271, section 9.1.1.)

-- Jeff

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Tue, 1 Nov 2016 20:12:20 +0000

>If the latter, can you help bridge the gap between intended meaning implementation consequences?

No, I do not strongly object to "NEW".
I think myself and Brian were concerned if the same bit (or bits) would
be used for marking updates no-policy-invalid as for origin-validation-invalid.
May be that is why you dropped 'invalid' and used 'discard' instead (in NEW2).

I am OK with what Jeff is suggesting now:

>>If you're just looking for "you can't use this without import policy specified", you want something along the lines of:

>>In the absence of configured import policy, BGP routes are ineligible for route selection. (RFC 4271, section 9.1.1.)

>>-- Jeff

Seems OK to leave the details to the implementers about how to tag/notate/mark the updates. 

Sriram

-----Original Message-----
From: Job Snijders [mailto:[email-masked]] 
Sent: Tuesday, November 01, 2016 12:24 PM
To: Jeffrey Haas <[email-masked]>
Cc: Sriram, Kotikalapudi (Fed) <[email-masked]>; [email-masked]
Subject: Re: [GROW] Working Group Adoption Call: draft-mauch-bgp-reject

On Tue, Nov 01, 2016 at 11:07:19AM -0400, Jeffrey Haas wrote:
> > Both of you mention per-peer flags or new per-route state flags, 
> > which in essence are updates to rfc4271, this feels like too heavy 
> > of a hammer.
> > 
> > I'd prefer to make the document compatible with existing deployments 
> > of software which is already compliant with the spirit of this document.
> > 
> > OLD:

Am I correct to understand that the word 'discard' has very specific meaning in this context? Does "discard" mean "forbidden to store in memory"?

Sriram, I believe you were the first to raise a concern about the "OLD"
text, do you have a preference for "NEW2" or strongly object to "NEW"?
If the latter, can you help bridge the gap between intended meaning implementation consequences?

Or perhaps: NEW3: "Software MUST ignore any routes from an EBGP peer, if no import policy was configured." ?

Kind regards,

Job

---

From: Brian Dickson <[email-masked]>
Date: Tue, 1 Nov 2016 18:29:22 -0700

> route selection. (RFC 4271, section 9.1.1.)

This wording is consistent with what I want to have happen.

(Fixing language in other IDs/RFCs is work for another day.)

I cannot think of a better way of wording it, so my opinion is, "adopt this
language".

Support, BTW.

BRian

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 1 Nov 2016 22:39:50 -0400

it occurs to me that while this discussion is awesome, perhaps having it in
a thread not about the adoption of an already adopted draft would be good :)

(sadly gmail won't let me change the subject :( )

On Tue, Nov 1, 2016 at 9:29 PM, Brian Dickson <[email-masked]
> wrote:

> I cannot think of a better way of wording it, so my opinion is, "adopt
> this language".
>
> Support, BTW.
>
> BRian
>
> _______________________________________________
> GROW mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/grow
>
>