Subject: Re: [GROW] I-D Action: draft-ietf-grow-bgp-reject-02.txt

From: Greg Hankins <[email-masked]>
Date: Thu, 2 Feb 2017 18:54:54 -0500

I'd like to restart the discussion so that we can move forward on this I-D.

This draft IMHO is about EBGP only, so 3. does not make sense, as IBGP
policies are inherently different than EBGP policies.

We worded the draft specifically to apply to IPv4/IPv6 unicast AFI/SAFI
for EBGP, as most implementations (or at least the ones I'm familiar with),
already restrict other families.

However, rewording the text to cover all AFI/SAFI for EBGP would cover
all cases and clarify if certain implementations did allow other families.
If I were running EBGP between my own ASs, then I would want the strictest
defaults possible.

Greg

-- 
Greg Hankins <[email-masked]>

-----Original Message-----
Date: Tue, 15 Nov 2016 21:42:19 -0500
From: Jon Mitchell <[email-masked]>
To: [email-masked]
Subject: Re: [GROW] I-D Action: draft-ietf-grow-bgp-reject-02.txt

On 31/10/16 02:24 -0700, [email-masked] wrote:
>         Title           : Default IPv4 and IPv6 Unicast EBGP Route Propagation Behavior Without Policies

To hopefully increase the speed to allow operators to ask for this
behavior from their vendors, starting the thread on one of the points
still open from the presentation today:

1.  Current draft - IPv4/IPv6 unicast AFI/SAFI EBGP only
2.  All AFI/SAFI - EBGP only
3.  All AFI/SAFI - IBGP/EBGP

I think #1 makes sense as it's limited to global Internet table
protection.  I also think it would be useful to protect our internal
networks from errors with #3.  However since internal networks often use
eBGP (see large-scale DC, seamless MPLS, inter-as Option-C), I think it
would be a bit odd to cover all AFI/SAFI for EBGP only as it now covers
some internal network applications as well (widening the requirements of
what the draft is trying to achieve) w/o fulfilling protecting them
fully by covering IBGP.

-Jon

_______________________________________________
GROW mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/grow

---

From: Job Snijders <[email-masked]>
Date: Mon, 13 Feb 2017 19:08:56 +0100

Hi Greg, working group,

I agree with your analysis. I'm in support of a "By default, reject ALL
AFI/SAFI on EBGP sessions"-style (option 2 in your overview).

>From a deployment perspective I see most value in protecting the EBGP
boundaries with sensible default (reject), and can see advantages to
having a more promiscuous IBGP default (which I'd be happy to consider
out of scope for this document).

This draft came into existence because of concerns with regard to the
BGP Default-free Zone, which implicitly means that the default for EBGP
sessions was what we intended to improve upon.

Kind regards,

Job