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 On Thu, Feb 02, 2017 at 06:54:54PM -0500, Greg Hankins wrote: > 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 protected]> > > -----Original Message----- > Date: Tue, 15 Nov 2016 21:42:19 -0500 > From: Jon Mitchell <[email protected]> > To: [email protected] > Subject: Re: [GROW] I-D Action: draft-ietf-grow-bgp-reject-02.txt > > On 31/10/16 02:24 -0700, [email protected] 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 protected] > https://www.ietf.org/mailman/listinfo/grow > > _______________________________________________ > GROW mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/grow _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
