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 leaks and experience problems until this is default.

Fully support this default behavior.

Theodore Baschak - AS395089 - Hextet Systems
https://bgp.guru/ - https://hextet.net/
http://mbix.ca/ - http://mbnog.ca/

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

[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
Group.

The IESG contact persons are Benoit Claise and Joel Jaeggli.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-grow-mrt-add-paths/





Technical Summary

The MRT (RFC6396) record format is used to for archive routing
 information as it changes over time.  BGP is one of the routing 
protocols supported and MRT needs updates when BGP gets certain
 new capabilities.  The capability for BGP to advisertise multiple 
paths has been added with RFC7911.  This document adds the 
required functionality to MRT enabling the format to store the new
 information.

Working Group Summary

There has been good consensus within the working group.  The 
draft overall is straight forward, and simple.  The document is 
required to ensure that MRT can continue to store BGP routing 
information that vendors are implementing and end users are 
deploying.

The last call was quiet, but it was clear from the interested parties
 that the document was ready for publication.

Document Quality

The feature has been implemented in bird (http://bird.network.cz/) 
and is waiting to be pulled into an official release.  There are two 
software packages for procesing the MRT data, RIPE NCC's bgpdump, 
and java-mrt (https://github.com/tking/java-mrt).  The document 
focuses on extending the existing MRT standard, by adding new 
message subtypes.

Personnel

Document Shepherd: Peter Schoenmaker
Responsible Area Director: Joel Jaeggli

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

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:   +27 (0) 82 415 5545
> Email:  b...@workonline.co.za
> SIP:  b...@workonline.co.za
> 
> 
> 
> 
> -Original Message-
> From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Dickinson, Ian
> Sent: Wednesday, March 15, 2017 1:06 PM
> To: grow@ietf.org
> Subject: Re: [GROW] WG Adoption call: draft-iops-grow-bgp-session-culling 
> ENDS - 03/28/2017
> 
> I support WG adoption of draft-iops-grow-bgp-session-culling
> 
> Ian
> 
> From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Christopher Morrow
> Sent: 14 March 2017 20:15
> To: grow@ietf.org grow@ietf.org ; grow-cha...@ietf.org; 
> grow-...@tools.ietf.org
> Subject: [GROW] WG Adoption call: draft-iops-grow-bgp-session-culling ENDS - 
> 03/28/2017
> 
> howdy WG folk:
> Noting the large amount of discussion on this draft already on-list, I'd like 
> to open a call for WG Adoption of this draft.
> 
> The abstract:
>   "This document outlines an approach to mitigate negative impact on
>networks resulting from maintenance activities.  It includes guidance
>for both IP networks and Internet Exchange Points (IXPs).  The
>approach is to ensure BGP-4 sessions affected by the maintenance are
>forcefully torn down before the actual maintenance activities
>commence."
> 
> And the draft link:
>   https://tools.ietf.org/html/draft-iops-grow-bgp-session-culling-00
> 
> I believe the following WG members have already spoken up in favor:
>   Job Snijders
>   Gert Doering
>   Nick Hilliard
> 
> Please have a read and join the already brisk conversation on the list, and 
> let us know if this is something the WG would like to discuss further.
> 
> thanks!
> -chris
> co-chair
> 
> Information in this email including any attachments may be privileged, 
> confidential and is intended exclusively for the addressee. The views 
> expressed may not be official policy, but the personal views of the 
> originator. If you have received it in error, please notify the sender by 
> return e-mail and delete it from your system. You should not reproduce, 
> distribute, store, retransmit, use or disclose its contents to anyone. Please 
> note we reserve the right to monitor all e-mail communication through our 
> internal and external networks. SKY and the SKY marks are trademarks of Sky 
> plc and Sky International AG and are used under licence.
> Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited 
> (Registration No. 2067075) and Sky Subscribers Services Limited (Registration 
> No. 2340150) are direct or indirect subsidiaries of Sky plc (Registration No. 
> 2247735). All of the companies mentioned in this paragraph are incorporated 
> in England and Wales and share the same registered office at Grant Way, 
> Isleworth, Middlesex TW7 5QD.
> ___
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow
> ___
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow
> 


___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

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 
> draft-ietf-idr-as4octet-extcomm-generic-subtype seemed reasonable (at the 
> cost of waiting for years, but this was not expected as we though vendors 
> would implement it to accommodate 4-octects AS deployments). It's not 
> anymore, so I guess we'll update the draft to follow this proposed path.

I have no issues with a well known RFC 1997 community.

The generic as4-octet could be used as well.  It's just an extended
community code point.

End of the day, it's whatever gets the feature shipped.[1]

-- Jeff

[1] You've been able to do arbitrary extended communities in Junos for a
while.  They don't necessarily display right in show commands, but the
transitivity flag is respected.

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

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 "draining" behavior is pretty common when you can do it.  And
it's worth noting that most of what gshut needed was just a community people
were willing to use for such a depref.

> > Since the title of the draft is "session-culling" it feels somewhat
> > out of scope to go more into detail on gshut, but a reference might be
> > useful.
> 
> Perhaps if the gshut draft is revived, a reference indeed is appropiate.
> I may have been too soon in my dismissal. Ben Maddison aptly pointed out
> that gshut is part of Ben's Current Practices. :-)

Informational references say "go look at this time" not "you require this"
(normative).  You can refer to pretty much anything you want in
informational without impacting publication.

-- Jeff

___
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 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 
+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] WGLC draft-ietf-grow-bgp-reject - ends 3/19/2017 (mar
19)

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 not yet supported.
> 
> A small nit on the clarity of the applicability to al address families 
> - the way how it is worded now seems to assume global and VPN address 
> families only. What about explicitly requiring all address families 
> active on the session to be affected by this?
> 
> OLD:
>This specification intends to improve this situation by requiring the
>explicit configuration of a BGP import and export policy for any
>External BGP (EBGP) session such as customers, peers, or
>confederation boundaries in a base router or VPN instances.
> 
> NEW:
>This specification intends to improve this situation by requiring the
>explicit configuration of a BGP import and export policy for any
>External BGP (EBGP) session such as customers, peers, or
>confederation boundaries for all enabled address families.

I'd like to incorporate your suggestion, I agree it adds clarity.

Kind regards,

Job

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

___
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 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 not yet supported.
> 
> A small nit on the clarity of the applicability to al address families - the
> way how it is worded now seems to assume global and VPN address families
> only. What about explicitly requiring all address families active on the
> session to be affected by this?
> 
> OLD:
>This specification intends to improve this situation by requiring the
>explicit configuration of a BGP import and export policy for any
>External BGP (EBGP) session such as customers, peers, or
>confederation boundaries in a base router or VPN instances.
> 
> NEW:
>This specification intends to improve this situation by requiring the
>explicit configuration of a BGP import and export policy for any
>External BGP (EBGP) session such as customers, peers, or
>confederation boundaries for all enabled address families.

I'd like to incorporate your suggestion, I agree it adds clarity.

Kind regards,

Job

___
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 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 to al address families - 
the way how it is worded now seems to assume global and VPN address 
families only. What about explicitly requiring all address families 
active on the session to be affected by this?


OLD:
   This specification intends to improve this situation by requiring the
   explicit configuration of a BGP import and export policy for any
   External BGP (EBGP) session such as customers, peers, or
   confederation boundaries in a base router or VPN instances.

NEW:
   This specification intends to improve this situation by requiring the
   explicit configuration of a BGP import and export policy for any
   External BGP (EBGP) session such as customers, peers, or
   confederation boundaries for all enabled address families.

Ignas


On 20/03/2017 01:47, 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)... read and respond 
pls :)

-chris

On Sun, Mar 5, 2017 at 4:30 PM, Christopher Morrow 
> 
wrote:


Howdy WG folks,
This request starts the WGLC for:
  >

with abstract:
  "This document defines the default behavior of a BGP speaker when
   there is no import or export policy associated with an External BGP
   session."

please have a read-through, decide if this needs more work and
then speak up on list.
thanks!
-chris
co-chair-personage.




___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow


___
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 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

From: GROW [grow-boun...@ietf.org] on behalf of Susan Hares [sha...@ndzh.com]
Sent: Monday, March 20, 2017 5:36 AM
To: 'Christopher Morrow'; grow@ietf.org; grow-...@tools.ietf.org; 
grow-cha...@ietf.org
Subject: Re: [GROW] WGLC draft-ietf-grow-bgp-reject - ends 3/19/2017 (mar 19)

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

From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Christopher Morrow
Sent: Sunday, March 19, 2017 9:48 PM
To: grow@ietf.org grow@ietf.org; grow-...@tools.ietf.org; grow-cha...@ietf.org
Subject: Re: [GROW] WGLC draft-ietf-grow-bgp-reject - ends 3/19/2017 (mar 19)

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)... read and respond pls :)
-chris

On Sun, Mar 5, 2017 at 4:30 PM, Christopher Morrow 
> wrote:
Howdy WG folks,
This request starts the WGLC for:
  

with abstract:
  "This document defines the default behavior of a BGP speaker when
   there is no import or export policy associated with an External BGP
   session."

please have a read-through, decide if this needs more work and then speak up on 
list.
thanks!
-chris
co-chair-personage.

This communication is the property of CenturyLink and may contain confidential 
or privileged information. Unauthorized use of this communication is strictly 
prohibited and may be unlawful. If you have received this communication in 
error, please immediately notify the sender by reply e-mail and destroy all 
copies of the communication and any attachments.
___
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 

 

From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Christopher Morrow
Sent: Sunday, March 19, 2017 9:48 PM
To: grow@ietf.org grow@ietf.org; grow-...@tools.ietf.org; grow-cha...@ietf.org
Subject: Re: [GROW] WGLC draft-ietf-grow-bgp-reject - ends 3/19/2017 (mar 19)

 

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)... read and respond pls :)

-chris

 

On Sun, Mar 5, 2017 at 4:30 PM, Christopher Morrow 
 wrote:

Howdy WG folks,

This request starts the WGLC for:
  

 

with abstract:
  "This document defines the default behavior of a BGP speaker when

   there is no import or export policy associated with an External BGP

   session."

 

please have a read-through, decide if this needs more work and then speak up on 
list.

thanks!

-chris

co-chair-personage.

 

___
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 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: grow-cha...@ietf.org; grow@ietf.org grow@ietf.org ; 
grow-...@tools.ietf.org
Subject: Re: [GROW] WGLC draft-ietf-grow-bgp-reject - ends 3/19/2017 (mar 19)

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
omission has caused and continues to cause a tremendous amount of damage
on the internet.

Nick

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Information in this email including any attachments may be privileged, 
confidential and is intended exclusively for the addressee. The views expressed 
may not be official policy, but the personal views of the originator. If you 
have received it in error, please notify the sender by return e-mail and delete 
it from your system. You should not reproduce, distribute, store, retransmit, 
use or disclose its contents to anyone. Please note we reserve the right to 
monitor all e-mail communication through our internal and external networks. 
SKY and the SKY marks are trademarks of Sky plc and Sky International AG and 
are used under licence.
Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited 
(Registration No. 2067075) and Sky Subscribers Services Limited (Registration 
No. 2340150) are direct or indirect subsidiaries of Sky plc (Registration No. 
2247735). All of the companies mentioned in this paragraph are incorporated in 
England and Wales and share the same registered office at Grant Way, Isleworth, 
Middlesex TW7 5QD.

___
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 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
omission has caused and continues to cause a tremendous amount of damage
on the internet.

Nick

___
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 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)... read and respond pls :)

I have read this and support it :-)

- Jared

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

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow