Re: [GROW] draft-iops-grow-bgp-session-culling-00

2017-03-20 Thread Jeffrey Haas
On Wed, Mar 15, 2017 at 04:37:00PM +0100, Job Snijders wrote: > I've come to understand that even if the remote party does not support > gshut, at least in one direction there will be benefit (downpreffing of > routes received from the BGP neighbor which is about to be shut down). This sort of

Re: [GROW] WGLC draft-ietf-grow-bgp-reject - ends 3/19/2017 (mar 19)

2017-03-20 Thread Theodore Baschak
> On Mar 20, 2017, at 12:29 PM, Tore Anderson wrote: > > * Ben Maddison > >> Fully support this. It adds a much needed sanity check to the >> behavior of BGP in the wild. > > Concur. > > Tore Many new/inexperienced operators who go from 1 to 2 upsteams will continue to cause

Re: [GROW] draft-ietf-grow-bgp-gshut status?

2017-03-20 Thread Jeffrey Haas
On Wed, Mar 15, 2017 at 03:21:18PM +, bruno.decra...@orange.com wrote: > > I'm somewhat inclined to proceed with the gshut concept as a well-known > > transitive rfc 1997 community. What do others think? > > I agree with you. > Until now, in order to capture all the options, waiting for >

Re: [GROW] WG Adoption call: draft-iops-grow-bgp-session-culling ENDS - 03/28/2017

2017-03-20 Thread Colin Petrie
I support adoption of this draft. Regards, Colin On 15/03/2017 12:25, Ben Maddison wrote: > Hi grow, > > As an network operator, I support adoption of this draft. > > Regards, > > Ben Maddison > > Director > Workonline Communications (Pty) Ltd > > Office: +27 (0) 21 200 9000 > Mobile:

[GROW] Protocol Action: 'Multi-Threaded Routing Toolkit (MRT) Routing Information Export Format with BGP Additional Paths Extensions' to Proposed Standard (draft-ietf-grow-mrt-add-paths-03.txt)

2017-03-20 Thread The IESG
The IESG has approved the following document: - 'Multi-Threaded Routing Toolkit (MRT) Routing Information Export Format with BGP Additional Paths Extensions' (draft-ietf-grow-mrt-add-paths-03.txt) as Proposed Standard This document is the product of the Global Routing Operations Working

Re: [GROW] WGLC draft-ietf-grow-bgp-reject - ends 3/19/2017 (mar 19)

2017-03-20 Thread Dickinson, Ian
Concur. This is a sane default that would have avoid many leaks over the years, so I support this. Ian -Original Message- From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Nick Hilliard Sent: 20 March 2017 11:24 To: Christopher Morrow Cc:

Re: [GROW] WGLC draft-ietf-grow-bgp-reject - ends 3/19/2017 (mar 19)

2017-03-20 Thread Nick Hilliard
Christopher Morrow wrote: > Howdy folks! > There were 3 people, 4 if you include me, that had something to say here... > > it'd be nice if a few more folk had read through and agreed/disagreed :) violent support for this. This is something that should have been in bgp on day one, and its

Re: [GROW] WGLC draft-ietf-grow-bgp-reject - ends 3/19/2017 (mar 19)

2017-03-20 Thread Jared Mauch
On Sun, Mar 19, 2017 at 09:47:30PM -0400, Christopher Morrow wrote: > Howdy folks! > There were 3 people, 4 if you include me, that had something to say here... > > it'd be nice if a few more folk had read through and agreed/disagreed :) > > I'll delay decision making until Tues (3/21/2017)...

Re: [GROW] WGLC draft-ietf-grow-bgp-reject - ends 3/19/2017 (mar 19)

2017-03-20 Thread Smith, Donald
Support, the basic concept that if I am not configured to speak to you, I don't listen, nor announce to you, is sound and should be the default behavior. if (initial_ttl!=255) then (rfc5082_compliant==0) donald.sm...@centurylink.com

Re: [GROW] WGLC draft-ietf-grow-bgp-reject - ends 3/19/2017 (mar 19)

2017-03-20 Thread Job Snijders
On Mon, Mar 20, 2017 at 02:06:13PM +, Ignas Bagdonas wrote: > Fully support. Speaking as an operator, this is the right thing to do, and > it has been deployed as a standard practice either natively if > implementations do support this now or as an initial policy preconfiguration > if it is

Re: [GROW] WGLC draft-ietf-grow-bgp-reject - ends 3/19/2017 (mar 19)

2017-03-20 Thread Ignas Bagdonas
Fully support. Speaking as an operator, this is the right thing to do, and it has been deployed as a standard practice either natively if implementations do support this now or as an initial policy preconfiguration if it is not yet supported. A small nit on the clarity of the applicability

Re: [GROW] WGLC draft-ietf-grow-bgp-reject - ends 3/19/2017 (mar 19)

2017-03-20 Thread Susan Hares
+1 to change - good catch by Ignas. Sue -Original Message- From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Job Snijders Sent: Monday, March 20, 2017 10:43 AM To: Ignas Bagdonas Cc: grow-cha...@ietf.org; grow@ietf.org grow@ietf.org; grow-...@tools.ietf.org Subject: Re: [GROW]

Re: [GROW] WGLC draft-ietf-grow-bgp-reject - ends 3/19/2017 (mar 19)

2017-03-20 Thread Tore Anderson
* Ben Maddison > Fully support this. It adds a much needed sanity check to the > behavior of BGP in the wild. Concur. Tore ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] WGLC draft-ietf-grow-bgp-reject - ends 3/19/2017 (mar 19)

2017-03-20 Thread Susan Hares
Grow folks: Section 2 aligns with the intent of RFC4271. I feel this concise draft address appropriate security considerations. I believe this drafts is ready from a technical viewpoint for publication. I am not an operator of a network, so I cannot comment on operator issues. Sue