[GROW]Re: well known large communities

[Susan Hares]

Sriram:

I agree with Jeff.  Let the proposal stay dead.

The Large Communities do not have structure.  If you want to carve off space, 
go to a structured Community Path attribute. The road of carving off space 
leads to many problems.

Sue

From: Jeffrey Haas 
Sent: Saturday, June 8, 2024 12:41 PM
To: Sriram, Kotikalapudi (Fed) 
Cc: Susan Hares ; grow@ietf.org; Jakob Heitz (jheitz) 
; draft-heitz-idr-w...@ietf.org
Subject: Re: [GROW]Re: well known large communities

> On Jun 8, 2024, at 11:54 AM, Sriram, Kotikalapudi (Fed) wrote: > > Some of us 
> may remember this (including Sue and Jeff). Jakob Heitz, I, and others have 
> proposed/pres
External (jh...@pfrc.org<mailto:jh...@pfrc.org>)
  Report This 
Email<https://protection.inkyphishfence.com/report?id=bmV0b3JnMTA1ODY5MTIvc2hhcmVzQG5kemguY29tL2I3MTM0Mzk1YTIzYzc5YjAzYzQxMGRhYjFlOTZkZmQxLzE3MTc4NjQ4MzcuMDE=#key=d616d67a926b62096f22631d319393e6>
  
FAQ<https://www.godaddy.com/help/report-email-with-advanced-email-security-40813>
  GoDaddy Advanced Email Security, Powered by 
INKY<https://www.inky.com/protection-by-inky>






> On Jun 8, 2024, at 11:54 AM, Sriram, Kotikalapudi (Fed) 
> mailto:kotikalapudi.sri...@nist.gov>> wrote:

>

> Some of us may remember this (including Sue and Jeff).  Jakob Heitz, I, and 
> others have proposed/presented (in the IDR WG) the idea of a range of 
> IANA-registered 4-octet ASN values for the Global Admin field to classify BGP 
> Well Known Large Communities (WKLC).

> See: 
> https://datatracker.ietf.org/doc/draft-heitz-idr-wklc/<https://shared.outlook.inky.com/link?domain=datatracker.ietf.org=h.eJw9jsEOgyAQBX_FcK7Aiop48ldWFoq1VQM0TWz67y2XXifzJu_NnvHOxoqFnI80CkGYMUe0q4t8cdnzPV4F7VZQRJ_r4JZ81gvF-rXerWCXiq1lvrn8E0F2Q2-gESlgdGna6Azc7g8xa1CtMh02ymozS2VbkIQzONOTJxCgQQ99OyjNJZSqK9VbQEzT4aMtNwqmgv_g8wUJaTp6.MEYCIQCh1JZoahFCs_nIkGK9F2b8E2bRiRKmZkRRj1yUlckbGQIhAJ5w0c5bQ8O6gorXKVpnBhYxCbhFzoOaXzxkvOGb6Jl_>
>   [1]

>

> The above draft was motivated in part by the following GROW WG draft's 
> request plus possible other use cases for WKLC:

> https://datatracker.ietf.org/doc/draft-ietf-grow-route-leak-detection-mitigation/<https://shared.outlook.inky.com/link?domain=datatracker.ietf.org=h.eJw9zssOgjAQheFXMV1bylCg4MpXGTrDRZSaYYyJxnfXbtydfIs_520ecjWng5lV7_vJOUJFFYwrS7GwjkWSyVGKjgRHtZnsJOlpJT2U7ZVxtcTKUZe02duiy4R5OnM8mDWXN9ZfA8qma3uo3D6j8H7e6DUXMd3cEMDXvm-w8jH0Q-ljDSXhANy3NBI4CBC6tu58KErIVc7Vy4y4n--jxPwwM2X-w-cLT0tFFA.MEQCIC2ACAHSoFEhWkEOytmUhaKqfrSbtNLAPZ5b3rW2x_-hAiAvnlTp7BccHX7u5WpON4oFYUkqvlb34WhXUdUQKE5Cow>
>   [2]

>

> Our idea was critiqued for requesting 64M 4-octet ASN values to be set aside 
> by IANA for WKLC. That is only 64 million out of the 4 Billion (a fraction 
> 0.015) 4-octet ASNs. This can be reduced easily to 256K out of the 4 Billion 
> (a fraction 0.6) if that is acceptable. There would be 9 octets available 
> in the WKLC for the data part. The 256K number can be further reduced to 1K 
> if desired (with 8 octets available in the WKLC for the data part).

>

> Details can be found in the above cited draft [1].  We can discuss further 
> the possibilities if this approach gets some traction.  Thanks.



Please let the proposal stay dead.  Carving up the globally visible BGP AS 
space with too many "this is special" numbers is a bad idea.







-- Jeff


___
GROW mailing list -- grow@ietf.org
To unsubscribe send an email to grow-le...@ietf.org

[GROW]Re: I-D Action: draft-ietf-grow-ixp-ext-comms-00.txt

[Susan Hares]

And, this was because the Large community authors – wanted it as just a number.

Individuals even said, there would be no use for well-known large BGP 
communities.

Sue

From: Jeffrey Haas 
Sent: Friday, June 7, 2024 5:24 PM
To: Robert Raszuk 
Cc: Job Snijders ; David Farmer 
; grow@ietf.org
Subject: [GROW]Re: I-D Action: draft-ietf-grow-ixp-ext-comms-00.txt

There is no such thing as a well known large bgp community. Jeff  ‌  ‌  ‌  ‌  ‌ 
 ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  
‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌ 
 ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌
External (jh...@pfrc.org)
  Report This 
Email
  
FAQ
  GoDaddy Advanced Email Security, Powered by 
INKY

There is no such thing as a well known large bgp community.


Jeff


On Jun 7, 2024, at 15:51, Robert Raszuk 
mailto:rob...@raszuk.net>> wrote:

Hi Job/WG,

Reading the document I have a feeling/suggestion that perhaps this is a very 
good time now to define few IXP focused well known Large Communities such that 
most often signalled policies between RS and their clients are well defined and 
not random among IXPs.

That may also in fact encourage faster migration to LCs from Extended 
Commuities.

Thx a lot,
Robert


On Fri, Jun 7, 2024 at 9:39 PM Job Snijders 
mailto:40fastly@dmarc.ietf.org>> wrote:
Thanks David, we will incorporate this in the next revision

On Fri, 7 Jun 2024 at 21:15, David Farmer 
mailto:40umn@dmarc.ietf.org>> wrote:
I reviewed the draft;

The Abstract and Introduction says, "It includes guidance for both the Internet 
Service Provider side peering with Route Servers and IXPs operating Route 
Servers."

However, the document no longer calls for any direct actions by ISPs. 
Obviously, the actions recommended for IXPs will impact the ISPs using IXPs. 
However, the statements above imply direct actions by ISPs in addition to IXPs, 
not indirect impacts on ISPs from IXP actions.

You should probably rephrase the above statements to refer to indirect impacts 
on ISPs unless you expect ISPs to take other direct actions, and if you do, 
those other actions need to be more clearly stated.

Thanks.

On Wed, Jun 5, 2024 at 11:09 AM 
mailto:internet-dra...@ietf.org>> wrote:
Internet-Draft draft-ietf-grow-ixp-ext-comms-00.txt is now available. It is a
work item of the Global Routing Operations (GROW) WG of the IETF.

   Title:   Recommendation to avoid use of BGP Extended Communities at Internet 
Exchange Route Servers
   Authors: Job Snijders
Stavros Konstantaras
Mo Shivji
   Name:draft-ietf-grow-ixp-ext-comms-00.txt
   Pages:   5
   Dates:   2024-06-04

Abstract:

   This document outlines a recommendation to the Internet operational
   community to avoid the use of BGP Extended Communities at Internet
   Exchange Point (IXP) Route Servers.  It includes guidance for both
   the Internet Service Provider side peering with Route Servers and
   IXPs operating Route Servers.  This recommendation aims to help the
   global Internet routing system's performance and help protect Route
   Server participants against misconfigurations.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-grow-ixp-ext-comms/

There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-grow-ixp-ext-comms-00

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


___
GROW mailing list -- 

[GROW] Request for Grow WG feedback on adoption of draft-zzhang-idr-rt-derived-community-03.txt (1/20 to 2/3)

[Susan Hares]

Greetings:

The IDR WG did a call for draft-zzhang-idr-rt-derived-community-03.txt.
https://mailarchive.ietf.org/arch/msg/idr/uwY3Hdrk2ned2hqMimpB6alhd9U/

We have received a lite support and no objections.
The IDR chairs are inclined to adopt this draft, but we would like
feedback from the Grow WG.

You can comment on the IDR mail thread or respond to me individually.
I will summarize the Grow WG response on 2/3 in a follow-up email.

The extra days are to allow Chinese participants to respond after
Chinese New Year celebration (1/20 to 1/27)

Cheerily, Sue
(sha...@ndzh.com).

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

[GROW] Interest in CBOR Community Paths

[Susan Hares]

Thanks to Martin Pels on BGP community in JSON schema.

Interested in seeing BGP Communities in Yang and CBOR - to see if we can get 
compression.

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

[GROW] FW: IDR Interim on 10/13/2022

[Susan Hares]

IDR will hold an interim on 10/13/2022 - 10:00-12:30 ET

Topics:

1. CAR CT (60 minutes)

1.1 CAR-CT interoperability
a) draft-haas-idr-bgp-diffract (Jeff Haas)
b) CAR-CT interoperability (Keyur Patel)

1.2 Updates on color proposals
CAR, CT, and draft-wang-idr-cpr-00

1.3) update on requirements from Spring

2. BGP Next Hops  (60-90 minutes)

Due to the discussion on draft-scudder-idr-entropy-label-01,  IDR will host a 
session on BGP Next Hop (current and future directions).

The chairs would like presentations from:
1) draft-ietf-idr-next-hop-capability-08,
2) draft-scudder-idr-entropy-label-01
3) draft-ietf-idr-bgp-attribute-announcement-
4) draft-kaliraj-idr-multinexthop-attribute-02
5) Any BESS draft proposing BGP Next hop changes
6) any LSVR draft proposing BGP next-hop changes

If you would like to present a short review of your BGP Next hop proposal, 
please send a note to IDR Secretary 
(jie.d...@huawei.com) and the 
idr-cha...@ietf.org.

Cheerily, Sue

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

Re: [GROW] [Idr] [Lsr] IGP Monitoring Protocol

[Susan Hares]

Jeff:

An interim sounds like a good plan.

[IDR-chair hat]
Alvaro has indicated that since all of the proposal received on the IDR list 
are new protocol proposals,

  *   Capturing IDR’s input on BGP-LS problems and potential solutions is 
appropriate for IDR as BGP-LS home.
  *   Refining any potential non-BGP solutions is outside of the scope of IDR.

[IDR-chair hat off]
[rtgwg WG member]
I’d love to attend an interim on this topic.

Sue Hares


From: Jeff Tantsura 
Sent: Saturday, July 9, 2022 3:40 PM
To: Robert Raszuk 
Cc: Acee Lindem (acee) ; lsr ; i...@ietf.org; 
Susan Hares ; grow@ietf.org grow@ietf.org 
Subject: Re: [Idr] [Lsr] IGP Monitoring Protocol

Speaking as RTGWG chair: Robert - I don’t think we’d have enough time to 
accommodate a good discussion during IETF114 (we got only 1 slot), however 
would be happy to provide a platform for an interim.
External (jefftant.i...@gmail.com<mailto:jefftant.i...@gmail.com>)
  Report This 
Email<https://protection.inkyphishfence.com/report?id=bmV0b3JnMTA1ODY5MTIvc2hhcmVzQG5kemguY29tLzBiOTRhNmZkOTYwNWI0MTE2NjdlMjdlZTRjODg2OTdlLzE2NTczOTU1NzcuNTc=#key=0e76c9fcd3ec8312944aa911e0941e13>
  FAQ<https://www.inky.com/banner-faq>  GoDaddy Advanced Email Security, 
Powered by INKY<https://www.inky.com/protection-by-inky>

Speaking as RTGWG chair:

Robert - I don’t think we’d have enough time to accommodate a good discussion 
during IETF114 (we got only 1 slot), however would be happy to provide a 
platform for an interim.
The topic is important and personally (being a very large BGP-LS user) I’d like 
to see it progressing.
Cheers,
Jeff


On Jul 8, 2022, at 14:44, Robert Raszuk 
mailto:rob...@raszuk.net>> wrote:

Hi Acee,

Yes, by all means input from the operator's community is needed. It can be 
collected through LSR WG, IDR WG or GROW WG. RTGWG could also contribute. We 
have already seen input from some operators and their opinion on adding and 
distributing more and more link state protocol and topology data in BGP. More 
such input is very welcome.

And to your point about RFC9086 - I see nothing wrong in keeping BGP 
information in BGP. So IGP Monitoring Protocol does not target to shut down 
BGP-LS. It only aims to remove 100% of non BGP sourced information from it.

Controllers which today listen to BGP-LS need a number of information sources 
and that spread will only keep increasing as more inputs are becoming necessary 
for its computations.

Regards,
Robert.


On Fri, Jul 8, 2022 at 11:32 PM Acee Lindem (acee) 
mailto:a...@cisco.com>> wrote:
Hi Robert,

From: Robert Raszuk mailto:rob...@raszuk.net>>
Date: Friday, July 8, 2022 at 4:36 PM
To: Acee Lindem mailto:a...@cisco.com>>
Cc: lsr mailto:l...@ietf.org>>, IDR List 
mailto:i...@ietf.org>>, Susan Hares 
mailto:sha...@ndzh.com>>
Subject: Re: [Lsr] IGP Monitoring Protocol

Hi Acee,

Thank you. I was not planning to present it in the upcoming IETF.

> Let’s see how many stakeholders actually want to this protocol - then we can 
> talk about a WG home.

An alternative approach could be to see how many stakeholders do not want to 
further (for no good reason) to trash BGP. That to me would be in this specific 
case a much better gauge.

In that case, it seems to me that this discussion should be relegated to IDR. 
Note that there is already non-IGP information transported in BGP-LS, e.g., 
Egress Peer Engineering 
(https://datatracker.ietf.org/doc/rfc9086/<https://shared.outlook.inky.com/link?domain=datatracker.ietf.org=h.eJxFjUESgyAQBL9icU6xYATEk19ZYVGj0RRuLknl75Fccp2u7nmLZ15FV4mJ-XF0ABEZOWNYKMuZOMk9jxD3ADkFr1oL4lKJpRgb8cm0Mq31uoZjwkxHv8XXJMN-BzX4Bm2K3iozNFpb66h2RE1oT8ERaGvc1RvjnDSuVKlUb5QS48a_836847yWXOGx8P_y-QJgjDiB.MEYCIQDM6a0IOMWEXn6_ra1IUbYdb6F_1qasOPtoUIKNO9acUgIhAK18nnvOVlb_6HIEZaqORgTvLo0EowqQxZEXvck3wI3m>).
 I implemented this on our data center routers (NXOS) years and it is solely 
BGP specific.

Thanks,
Acee

Kind regards,
Robert


On Fri, Jul 8, 2022 at 9:54 PM Acee Lindem (acee) 
mailto:a...@cisco.com>> wrote:
Speaking as WG chair:

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of 
Robert Raszuk mailto:rob...@raszuk.net>>
Date: Friday, July 8, 2022 at 3:21 PM
To: lsr mailto:l...@ietf.org>>
Cc: IDR List mailto:i...@ietf.org>>, Susan Hares 
mailto:sha...@ndzh.com>>
Subject: [Lsr] IGP Monitoring Protocol

Dear LSR WG,

Based on ongoing discussion in respect to the future of BGP-LS I committed 
myself to put together an alternate proposal.

The main goal is not to just publish a -00 version of the draft using different 
encapsulation. The goal is to make a useful tool which can help to export link 
state information from network elements as well as assist in network 
observability.

The IGP Monitoring Protocol (IMP) draft has been posted and should be available 
at:

https://datatracker.ietf.org/doc/draft-

[GROW] Adoption call for CAR/CT drafts (7/6 to 7/20) - Please give us your feedback

[Susan Hares]

Grow WG:



Today we started the WG adoption call for the

the CAR/CT drafts.  This adoption call has

the following two parts:



Part-1: Questions on technology direction

https://mailarchive.ietf.org/arch/msg/idr/FhoK04HsSy9tR7ioV7AD0Vv6Ir4/



Part-2: Adoption of the drafts

https://mailarchive.ietf.org/arch/msg/idr/AP_ClbZgpkX6CNy7TaZiU8SMD5w/



The IDR Chairs need to hear from Grow WG members

on the technology direction and the adoption.



It is important to know what you think of the technology direction

as well as the adoption.   Please consider giving us your feedback

on the technology direction as the first part of your feedback.



We'll be chatting with Grow chairs on this adoption call.

You can also express your opinion to them.


Cheers, Sue Hares
(IDR co-chair and shepherd for this adoption call)

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

[GROW] IDR adoptions of BGP auto-configuration (5/2 to 5/23)

[Susan Hares]

IDR is in the process of adopting BGP auto-configuration drafts.
We will adopt 1-4 of the BGP-auto-configuration proposals
that support BGP auto-configuration for data centers.

Please consider sending your comments to the IDR list.
The mail thread is at:

https://mailarchive.ietf.org/arch/msg/idr/ZuPiqp4YzZ3LVrfQPmAIsut6s9A/

Thank you,
Sue , Jeff, and Keyur
(IDR chairs)

===


IDR Working Group,



BGP auto-configuration has four proposals for consideration for adoption by

the IDR Working Group:



- draft-acee-idr-lldp-peer-discovery

https://datatracker.ietf.org/doc/draft-acee-idr-lldp-peer-discovery/



- draft-ietf-lsvr-l3dl + draft-ietf-lsvr-l3dl-ulpc

https://datatracker.ietf.org/doc/draft-ietf-lsvr-l3dl/

https://datatracker.ietf.org/doc/draft-ietf-lsvr-l3dl-ulpc/

https://datatracker.ietf.org/doc/draft-ietf-lsvr-l3dl-signing/



- draft-minto-idr-bgp-auto-discovery

https://datatracker.ietf.org/doc/draft-minto-idr-bgp-autodiscovery/



- draft-ymbk-idr-l3dn + draft-ymbk-idr-l3dn-ulpc

https://datatracker.ietf.org/doc/draft-ymbk-idr-l3nd/

https://datatracker.ietf.org/doc/draft-ymbk-idr-l3nd-ulpc/





These proposals address the core issue of BGP auto-configuration in

different ways:

- What security model should we require?

- What OSI layer? (Layer 2, Layer 3)

- Does it provide a session layer?



A brief summary of these properties for each proposal under consideration

for adoption:



draft-acee-idr-lldp-peer-discovery:

- Operates at Layer 2 as an extension to the LLDP protocol.

- Security optional, provided by MACSEC.

- Does not provide (or require) a session layer.



draft-ietf-lsvr-l3dl + draft-ietf-lsvr-l3dl-ulpc:

- Operates at Layer 2.

- Security varies from optional to certificate based.

- Provides its own session layer as part of the protocol.



draft-minto-idr-bgp-auto-discovery

- Operates at Layer 3 link-local multicast.

- Shared key authentication.

- Does not provide (or require) a session layer.



draft-ymbk-idr-l3dn + draft-ymbk-idr-l3dn-ulpc

- Operates at Layer 3 with a link-local multicast component, and a unicast

 component.

- Security varies from optional to using certificate based with TLS.

- Uses TCP for session layer for its unicast component.



What protocol or protocols should be adopted by the Working Group for

BGP auto-configuration?



-

FYI - Jeff Tantsura will be judging the consensus for this adoption call.


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

Re: [GROW] IETF 113 GROW meeting agenda (draft)

[Susan Hares]

Job and Chris: 
[WG chair hat on] 
Did you receive my request on behalf of IDR WG on 
VPN Prefix limits on the grow email list? 
Will you be asking this question at IETF 113? 
[WG chair hat off]

[WG participant hat on] 
I'm personally pleased to see an inbound prefix limit 
Proposal at IDR.

Thank you, Sue  

-Original Message-
From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Job Snijders
Sent: Thursday, March 10, 2022 4:41 AM
To: grow@ietf.org
Subject: [GROW] IETF 113 GROW meeting agenda (draft)

Hi all,

Here is the current draft GROW @ IETF 113 agenda:


https://datatracker.ietf.org/meeting/113/materials/agenda-113-grow-00.txt

Please let the chairs know if you'd also like to contribute agenda items.

Kind regards,

Job & Chris 

___
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] Request for input on Prefix Limits by IETF 113 IDR session (3/4 to 3/25)

[Susan Hares]

Grow: 

 

In the past you requested the IDR WG to consider drafts on prefix limits. 

 

Two drafts proposed included discussions on prefix limits 

(draft-wang-idr-vpn-prefix-orf-02.txt, 

draft-sas-idr-maxprefix-inbound-04.txt) 

 

Would you query the grow working group regarding: 

 

a) hard prefix limits per BGP peer 

   a) (protocol enforced) maximum prefix (inbound) 

   b) (software enforced) maximum prefix (inbound) 

   c) (software enforced) maximum prefix (outbound)

 

b) thresholds prior to hard limits per BGP peer 

 

c) What limits should be placed on VPNs? 

What granularity   

 

Do you think you could get an answer for IDR by 

the end of IETF 113? 

 

If you wish, I can also present the request at Grow at IETF 113. 

5 minutes (what I need + why) 

10 discussion (when I listen to operations experts)  

 

Sue Hares

(idr co-chair) 

 



 

Drafts mentioned 

 

Draft 1: draft-wang-idr-vpn-prefix-orf-02.txt 

https://datatracker.ietf.org/doc/draft-wang-idr-vpn-prefix-orf/

 

Note: ORF mechanism not approved, but prefix limits discussion is useful: 

https://mailarchive.ietf.org/arch/msg/idr/Lt5IQVUNPxhEh8-xvRTDIJZ24Kk/

 

New definitions:  Weak-PE, rogue-PE 

 

Draft 2: draft-sas-idr-maxprefix-inbound-04.txt  

https://datatracker.ietf.org/doc/draft-sas-idr-maxprefix-inbound/

(in IPR call prior to adoption) 

 

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

[GROW] IDR interims - 8/23, 9/13, 9/27, 10/11

[Susan Hares]

The IDR WG will be holding the following interims: 

Each interim is being held from 10-12:30) EDT

(22:00- 0:30 Beijing; 4-6:30pm CET, 7-9:30 PDT)

 

8/23: WG draft review 

9/13: Flow Specification v2 

9/27: Embedded NLRI and improved Error handling 

   (CAR and DT-Transport)

10/11: Auto-configuration protocols 

 

The first interim on 8/23 will provide an opportunity for longer
presentations on drafts which have requested WG Adoption in IDR, but are not
part of larger efforts (flow-spec v2, embedded NLRI (CAR, DT-Transport), bgp
autoconfiguration)). 

 

Authors of the following drafts are invited to present: 

1) draft-ietf-wang-idr-rd-orf   

2) draft-hb-idr-sr-p2mp-policy 

3) draft-xie-idr-bghp-ls-sr-vtn-mt 

4) draft-chen-bgp-redist-03.txt (only when -03 adjusts) 

5) draft-zzhang-idr-rt-derived-community [informational draft] 

6) draft-zzhang-idr-tunnel-encapsulation-label-stack

 

Each draft will be allotted 15-20 minutes for a longer discussion. Authors
of drafts may request a time slot to present. 

 

If bess chairs or WG has concerns regarding overlap on these drafts. 

 

Cheerily, Susan Hares 

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

Re: [GROW] route leak solution and IANA large community register

[Susan Hares]

Sriram:

If IDR adopts the draft, you can ask for early allocation on the registry.
Before that point,  let me chat with the IDR co-chairs and ADs to what other
options you have. 

Cheers,  Sue 

-Original Message-
From: Sriram, Kotikalapudi (Fed) [mailto:kotikalapudi.sri...@nist.gov] 
Sent: Sunday, March 7, 2021 6:26 PM
To: Christopher Morrow; Job Snijders
Cc: grow-cha...@ietf.org; GROW WG; idr-cha...@ietf.org; Susan Hares;
a.e.azi...@gmail.com
Subject: route leak solution and IANA large community register

I have a question for the GROW Chairs and anyone who can help.

There are these two drafts:
Methods for Detection and Mitigation of BGP Route Leaks
https://tools.ietf.org/html/draft-ietf-grow-route-leak-detection-mitigation-
04

BGP Well Known Large Community
https://tools.ietf.org/html/draft-heitz-idr-wklc-01

The first is in a mature state in GROW and the second is in a
pre-adoption-call state in IDR. The first draft requests IANA for an
allocation in well-known Large Community (WKLC) registry but no such IANA
registry exists yet. The second draft (in IDR) is making an effort to
specify and request the creation of an IANA WKLC registry. This work seems
to be going slow in IDR -- partly the authors are responsible (including
me).  

Question: Is the creation of an IANA Large Community registry a prerequisite
for a WGLC on the first one (in GROW)? Or, it is possible to have WGLC
requested/completed on the first one and then wait for the creation of the
IANA LC registry?

Thanks.

Sriram  



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

[GROW] draft-sa-grow-maxprefix - Problems with -02.txt text

[Susan Hares]

Grow WG: 

 

I applaud the effort to further specify Maximum prefix 

(inbound, outbound) based on operator input.  

Operators know the appropriate limit sizes or 

operational mechanisms.   

 

However, this draft specifies not limits but 

BGP mechanisms. I suggested to the authors at IETF 105  

that they review appropriate  BGP Specifications (RFC4271 

and the associated revisions) and BGP Yang model, and 

Then align the drafts with IDR specifications. 

 

However, I have not seen a revision of the draft that either:

1)   aligns this text with the  RFC4271, RFC4486, and RFC6608, or  

2)  Denotes this as input to the IDR WG for a draft.  

 

Therefore,  I can only assume this document intends to be a standard

that modifies RFC4271.  Based on that assumption, this 

strongly urges a rewrite of all sections of this draft to 

align with the BGP base specifications  prior to adoption. 

 

While I strongly believe in this effort to clarify and enhancement 

Maximum Prefix limits, the draft is not specific enough 

to be an appropriate standard for BGP.  

If this draft is to be an operational handbook, 

More comments on limits might be useful. 

 

Should the authors wish to collaborate, I will provide an

alternate set of text based on my comments below 

for the BGP mechanisms. 

 

 

Susan Hares 

 



 

Here are the problems: 

 

Problem 1: The draft does not indicate that it updates RFC4271 or RFC4486. 

 

However, it directly changes the way the "MAY" works in section 6.7 Cease. 

It provides standard language without a context of the RFC4271 section 6.7
or 

the associated FSM (section 8) or the update error handling.  



   The draft cannot change BGP Standards without being specific. 

   If you are going to recommend changes to RFC4271, be specific. 

   If you are going to recommend requirements so that IDR can change
RFC4271, be specific. 

  This draft does neither one.  Please adjust the draft.   

 

Problem 2: Section 2 - tries to replace the second paragraph of RFC4271
without being 

 as specific or stating that it replaces the paragraph. 

 
Section 6.7 of RFC4271 
   In the absence of any fatal errors (that are indicated in this
   section), a BGP peer MAY choose, at any given time, to close its BGP
   connection by sending the NOTIFICATION message with the Error Code
   Cease.  However, the Cease NOTIFICATION message MUST NOT be used when
   a fatal error indicated by this section does exist.
 
   A BGP speaker MAY support the ability to impose a locally-configured,
   upper bound on the number of address prefixes the speaker is willing
   to accept from a neighbor.  When the upper bound is reached, the
   speaker, under control of local configuration, either (a)discards
   new address prefixes from the neighbor (while maintaining the BGP
   connection with the neighbor), or (b) terminates the BGP connection
   with the neighbor.  If the BGP speaker decides to terminate its BGP
   connection with a neighbor because the number of address prefixes
   received from the neighbor exceeds the locally-configured, upper
   bound, then the speaker MUST send the neighbor a NOTIFICATION message
   with the Error Code Cease.  The speaker MAY also log this locally.

 

Section 2.0 of draft-sa-grow-maxprefix states:  



   An operator MAY configure a BGP speaker to terminate its BGP session
   with a neighbor when the number of address prefixes received from
   that neighbor exceeds a locally configured upper limit.  The BGP
   speaker then MUST send the neighbor a NOTIFICATION message with the
   Error Code Cease and the Error Subcode "Threshold reached: Maximum
   Number of Prefixes Received", and MAY support other actions.
   Reporting when thresholds have been exceeded is an implementation
   specific consideration, but SHOULD include methods such as Syslog
   [RFC5424 <https://tools.ietf.org/html/rfc5424> ].  Inbound Maximum Prefix
Limits can be applied in two
   distinct places in the conceptual model: before or after the
   application of routing policy.
 
 Is this draft looking to change the words in RFC4271? 
 It seems as though the authors which to change RFC4271 want to change 
 RFC4271.  The text is only really suggesting a change on what happens
 during 3 types of upper bound are reached. 
 
 The rest of the restatement of RFC4271 is less specific and 
 seems to change words without allowing for case a) in RFC4271.
 In addition,  "and MAY support other actions" in draft-sa-grow-maxprefix 
 is not an acceptable addition to RFC4271.  The additions to 
 RFC4271 must contain enough specific information to provide a platform
 for correct information texting.  
 
 This text lacks the lacks the clarity of RFC4271 and makes 
 gratuitous changes.  
 
 It only really needs to augment the first sentence:  
 
   A BGP speaker MAY support the ability to impose a locally-conf

Re: [GROW] I-D Action: draft-ietf-grow-route-leak-detection-mitigation-01.txt

[Susan Hares]

Alex:

 

The request to get an Community class for a well-known transmit 4 byte ASes 
needs a draft.  

I’ve volunteered to write such a draft for this draft, and I have text started. 
  

I will send you a draft by August 27th. If you have something you wish to 
put in it, please let me.

 

Just a warning, during the next 2 weeks, I will be offline more than online.  

As a professor, I am taking this time to finish some of my own school work. 

 

Cheerily, Susan Hares 

 

From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Alexander Azimov
Sent: Friday, July 26, 2019 1:12 PM
To: grow@ietf.org
Cc: i-d-annou...@ietf.org
Subject: Re: [GROW] I-D Action: 
draft-ietf-grow-route-leak-detection-mitigation-01.txt

 

Dear WG,

 

This document of route leak detection using communities seems to address all 
unresolved issues from the previous versions.
We believe that the proposed solution can be easily adopted by the ISPs thus 
reducing the number of route leaks that become globally propagated.

There is one unresolved dependency - we need IANA to reserve a class for 
well-known transit communities.

As far as I remember that there was already some work in this field. I'm eager 
to assist if this can help to speed up the process.

 

пт, 26 июл. 2019 г. в 20:02, :


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Global Routing Operations WG of the IETF.

Title   : Methods for Detection and Mitigation of BGP Route 
Leaks
Authors : Kotikalapudi Sriram
  Alexander Azimov
Filename: draft-ietf-grow-route-leak-detection-mitigation-01.txt
Pages   : 9
Date: 2019-07-26

Abstract:
   Problem definition for route leaks and enumeration of types of route
   leaks are provided in [RFC7908].  This document describes a new well-
   known Large Community that provides a way for route leak prevention,
   detection, and mitigation.  The configuration process for this
   Community can be automated with the methodology for setting BGP roles
   that is described in ietf-idr-bgp-open-policy draft.


The IETF datatracker status page for this draft is:
https://datatracker..ietf.org/doc/draft-ietf-grow-route-leak-detection-mitigation/
 
<https://datatracker.ietf.org/doc/draft-ietf-grow-route-leak-detection-mitigation/>
 

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-grow-route-leak-detection-mitigation-01
https://datatracker.ietf.org/doc/html/draft-ietf-grow-route-leak-detection-mitigation-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-grow-route-leak-detection-mitigation-01


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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



-- 

Best regards,

Alexander Azimov

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

Re: [GROW] Deprecation of AS_SET and AS_CONFED_SET -- feedback requested

[Susan Hares]

Sriram: 

Are you asking for WG Adoption of this draft at this time or just feedback?


Sue 

-Original Message-
From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Sriram, Kotikalapudi
(Fed)
Sent: Wednesday, August 7, 2019 11:43 AM
To: IDR; GROW WG
Cc: idr-cha...@ietf.org; sidr...@ietf.org
Subject: [GROW] Deprecation of AS_SET and AS_CONFED_SET -- feedback
requested

There was significant interest expressed during a SIDROPS presentation in
Montreal and in the discussion that followed at the mike about advancing the
following individual draft:
https://tools.ietf.org/html/draft-kumari-deprecate-as-set-confed-set-14  
(standards track)   

The authors have revised and uploaded a new version (-14).
Your inputs/comments are welcome. In particular, please share any specific
operational considerations/concerns you may have regarding this topic.

(Note: A BCP was published on this topics in 2011 --
https://tools.ietf.org/html/rfc6472 )   

Thank you.

Sriram
___
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] [Idr] WG LC for Extended BGP Administrative Shutdown Communication (bs) - draft-ietf-idr-rfc8203bis-04.txt (7/9 to 7/23) - extended to 8/6/2019

[Susan Hares]

Greetings: 

 

The IDR WG had reached consensus on draft-ietf-idr-rfc8203bis-04.txt, and it
has past WG LC.  

 

The authors should post the following:  

1)  draft-ietf-idr-rfc8203bis-05.txt - with the proposed changes,

2)  make any updates to the IDR Wiki page with implementation
information 

https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-rfc8203bis

 

After these items are posted, the shepherd (Susan Hares) will write-up the
shepherd report and send it to the IESG for publications. 

 

Cheerily, Susan Hares 

 

 

From: Susan Hares [mailto:sha...@ndzh.com] 
Sent: Thursday, July 25, 2019 5:25 PM
To: grow@ietf.org
Subject: FW: [Idr] WG LC for Extended BGP Administrative Shutdown
Communication (bs) - draft-ietf-idr-rfc8203bis-04.txt (7/9 to 7/23) -
extended to 8/6/2019 

 

Greetings: 

 

IDR has extended its WG LC for draft-ietf-idr-rfc8203bis-04.txt  until
8/6/2019. 

 

Since this draft has operational impact, perhaps you'd like to consider
providing your opinion on this draft.   

 

Or if you are an IDR participant, you can go to the IDR list and comment
during this extended WG LC. 

 

Cheerily, Susan Hares 

 

From: Idr [mailto:idr-boun...@ietf.org] On Behalf Of Susan Hares
Sent: Tuesday, July 9, 2019 9:13 AM
To: 'idr wg'
Subject: [Idr] WG LC for Extended BGP Administrative Shutdown Communication
(bs) - draft-ietf-idr-rfc8203bis-04.txt (7/9 to 7/23)

 

This begins a 2 week WG last call for draft-ietf-idr-rfc8203bis-04.txt from
July 9, 2019 to July 23, 2019. . 

 

Please consider if you believe this revision of RFC8203 (Administrative
Shutdown)

a)  Will benefit operational networks,

b)  is technically complete, and 

c)   ready for publication. 

 

In your comments, please indicate whether you "support" or "do not support"
its publication. 

 

This draft contains IPR notice that causes "IPR warnings".   The authors
believe that this text is automatically generated by the IETF tools and the
warning is not appropriate.   

 

As the shepherd, I am  investigating this issue.   If you have specific
knowledge on this issue, you may send it to the list or to me directly. 

 

Cheerily, Susan Hares 

 

 

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

Re: [GROW] [Idr] WG LC for Extended BGP Administrative Shutdown Communication (bs) - draft-ietf-idr-rfc8203bis-04.txt (7/9 to 7/23) - Extended to 8/6/2019

[Susan Hares]

Greetings IDR: 

 

The IDR WG call for input on draft-ietf-idr-rfc8203bis-04.txt has received
only 2 comments.  Since this is a draft that updates an operationally needed
feature,  I am extending the WG LC until 8/6/2019.  

 

If you believe this draft is ready for publication, please respond to this
WG LC. 

 

Sue Hares 

 

From: Idr [mailto:idr-boun...@ietf.org] On Behalf Of Susan Hares
Sent: Tuesday, July 9, 2019 9:13 AM
To: 'idr wg'
Subject: [Idr] WG LC for Extended BGP Administrative Shutdown Communication
(bs) - draft-ietf-idr-rfc8203bis-04.txt (7/9 to 7/23)

 

This begins a 2 week WG last call for draft-ietf-idr-rfc8203bis-04.txt from
July 9, 2019 to July 23, 2019. . 

 

Please consider if you believe this revision of RFC8203 (Administrative
Shutdown)

a)  Will benefit operational networks,

b)  is technically complete, and 

c)   ready for publication. 

 

In your comments, please indicate whether you "support" or "do not support"
its publication. 

 

This draft contains IPR notice that causes "IPR warnings".   The authors
believe that this text is automatically generated by the IETF tools and the
warning is not appropriate.   

 

As the shepherd, I am  investigating this issue.   If you have specific
knowledge on this issue, you may send it to the list or to me directly. 

 

Cheerily, Susan Hares 

 

 

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

[GROW] FW: [Idr] WG LC for Extended BGP Administrative Shutdown Communication (bs) - draft-ietf-idr-rfc8203bis-04.txt (7/9 to 7/23) - extended to 8/6/2019

[Susan Hares]

Greetings: 

 

IDR has extended its WG LC for draft-ietf-idr-rfc8203bis-04.txt  until
8/6/2019. 

 

Since this draft has operational impact, perhaps you'd like to consider
providing your opinion on this draft.   

 

Or if you are an IDR participant, you can go to the IDR list and comment
during this extended WG LC. 

 

Cheerily, Susan Hares 

 

From: Idr [mailto:idr-boun...@ietf.org] On Behalf Of Susan Hares
Sent: Tuesday, July 9, 2019 9:13 AM
To: 'idr wg'
Subject: [Idr] WG LC for Extended BGP Administrative Shutdown Communication
(bs) - draft-ietf-idr-rfc8203bis-04.txt (7/9 to 7/23)

 

This begins a 2 week WG last call for draft-ietf-idr-rfc8203bis-04.txt from
July 9, 2019 to July 23, 2019. . 

 

Please consider if you believe this revision of RFC8203 (Administrative
Shutdown)

a)  Will benefit operational networks,

b)  is technically complete, and 

c)   ready for publication. 

 

In your comments, please indicate whether you "support" or "do not support"
its publication. 

 

This draft contains IPR notice that causes "IPR warnings".   The authors
believe that this text is automatically generated by the IETF tools and the
warning is not appropriate.   

 

As the shepherd, I am  investigating this issue.   If you have specific
knowledge on this issue, you may send it to the list or to me directly. 

 

Cheerily, Susan Hares 

 

 

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

Re: [GROW] [Idr] draft-ietf-idr-capabilities-registry-change-05.txt - WG LC []6/9/2019 to 6/16/2019] - extending this for a 3rd week (7/8 to 7/15)

[Susan Hares]

IDR

 

The draft-ietf-idr-capabilities has reach a moderate working group consensus
and it will be sent to the IESG for publication. 

 

I want to thank the people who responded to my plea for additional response
from IDR (see below).  This an important registry change.For those who
would like to send additional comments (support/no support), please continue
to send these comments.  

 

Alvaro and the IESG read these lists to see how strong the consensus is on
documents. 

 

Sue Hares 

 

 

From: Idr [mailto:idr-boun...@ietf.org] On Behalf Of Susan Hares
Sent: Monday, July 8, 2019 1:00 PM
To: i...@ietf.org
Subject: Re: [Idr] draft-ietf-idr-capabilities-registry-change-05.txt - WG
LC []6/9/2019 to 6/16/2019] - extending this for a 3rd week (7/8 to 7/15)

 

Greetings: 

 

The email list support for this draft did not receive as many comments as I
expected.   Perhaps, this lack of comments was due to vacations or due to
this idea "just making sense".  

 

Since one of the WG chairs is an author, I do need a strong sense of
support.  Please send in comments or just a comment for "support" or "no
support" for this draft. 

 

Cheerily, Susan Hares

 

 

From: Idr [mailto:idr-boun...@ietf.org] On Behalf Of Susan Hares
Sent: Sunday, June 9, 2019 1:33 PM
To: i...@ietf.org
Subject: [Idr] draft-ietf-idr-capabilities-registry-change-05.txt - WG LC
[]6/9/2019 to 6/16/2019]

 

This begins a 2 week IDR  WG Last Call (LC) on
ft-ietf-idr-capabilities-registry-change-05.txt.  

 

The document is at: 

https://datatracker.ietf.org/doc/draft-ietf-idr-capabilities-registry-change
/

 

As registration document, there is no implementation report.  

 

Please indicate in comments to the IDR "support" or "no support" for WG LC. 

Consider:

 

1)  Does this change to registration procedures for BGP capability codes
help speed up processing? 

2)  Is there any technical or operational issue in making this change? 

3)  Do we need to pass this to the IESG at the same time as any GROW
document? 

 

John Scudder is an author so I am the shepherd/chair on this draft.  

 

Cheerily, Susan Hares 

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

[GROW] Request for 2 week review of draft-ietf-idr-bgp-extended-messages-33.txt - (7/9 to 7/22)

[Susan Hares]

Greetings: 

 

The BGP extended message support ( draft-ietf-idr-bgp-extended-messages-33)
has been sent to the IESG for publication.   Would grow please review the
draft and the operational considerations?   

 

During the long life of this draft IDR has mentioned this draft many times.
Would the grow participants, please review this draft and send any comments
regarding operational issues to both the IDR and grow list.  

 

draft-ietf-idr-bgp-extended-messages-33.txt  can be found at: 

 

https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-extended-messages/

 

Thank you, Susan Hares

IDR co-chair and shepherd 

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

[GROW] Please provide feedback on

[Susan Hares]

grow Wg: 

 

Would you please sponsor a 1 week call on the following to drafts to
inquire: 

a)  if theses drafts are useful in operational networks and 

b)  if the grow WG has any concerns regarding these drafts.

 

..
<https://datatracker.ietf.org/doc/draft-ietf-idr-bgpls-segment-routing-epe/>
draft-ietf-idr-bgpls-segment-routing-epe-17.txt

https://datatracker.ietf.org/doc/draft-ietf-idr-bgpls-segment-routing-epe/

.. Draft-ietf-idr-bgp-ls-segment-routing-ext-11.txt 

https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-segment-routing-ext/

 

 

Thank you Susan Hares 

Shepherd 

IDR co-chair 

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

[GROW] Meta-data on living documents

[Susan Hares]

 

I would suggest asking RFC editor on the potential ideas on a living
document.  She is connected to mechanism of this in the tools group and the 

 

I support investigating living documents. 

 

Sue Hares

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

[GROW] IDR Co-chair comment

[Susan Hares]

Greetings: 

 

The chairs did check with the IANA regarding the large community registry
for a specific number allocated per the route-leak. 

 

If the grow chairs wish the IDR chairs to write a short large community
registry draft, I  will take on that action item. 

 

Cheerily, Sue Hares  

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

[GROW] Operational review for 2 drafts

[Susan Hares]

Greetings: 

 

Would the Grow WG provide operational feedback 

on the following IDR drafts that provide support 

for segment routing: 

 

draft-ietf-idr-bgp-ls-segment-routing-ext-10.txt 

and 

draft-ietf-idr-bgpls-segment-routing-epe-17.txt 

 

These drafts utilize BGP to support the segment routing architecture found
in RFC8402. 

 

For ease of your reference the documents can be found at: 

 

https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-segment-routing-ext/

 

https://datatracker.ietf.org/doc/draft-ietf-idr-bgpls-segment-routing-epe/

 

It would be helpful to know: 

a) if the manageability and security sections 

in these drafts are sufficient to guide operators.  

b) if grow has any concerns regarding these drafts. 

 

Thank you, 

Susan Hares 

co-chair IDR 

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

[GROW] draft-scudder-idr-capabilities-registry-change-02 - has been adopted

[Susan Hares]

Greetings:

 

The WG has adopted draft-scudder-idr-capabilities-registry-change-02.txt.
The authors should submit this as
draft-ietf-idr-capabilities-registry-change-00.txt. 

 

Are the authors ready for WG last call on this document?   

 

In preparation for a WG LC, the authors should indicate if they know of any
IPR regarding the draft.   (My apologies for the repeated IPR call but I do
not want to miss a process step with this draft.  I would like this document
go as swiftly as the IDR/Grow WG desires). 

 

Susan Hares 

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

Re: [GROW] Opsdir last call review of draft-ietf-grow-bgp-gshut-13

[Susan Hares]

Jay: 

First of all - I'm fine with whatever you decide.   I do not want to delay
the publication process. This is an important specification for operators.  

On just logging, the question is whether GROW wants to suggest to
implementations that there should be implementation knobs for logging.
How/when/where - logging gets set is an implementation detail.

If Grow wants that, you can add in a 1 sentence during RFC editor process.
This is language is useful for specification to be clear on what knobs the
users expect.  If Grow does not care, then leave it out. 

Logging could eventually use the "push" yang modules - but that's for IDR 's
yang modules.   As to alarms,  agreed.  Not a good idea.

Thanks for the response.  I'm sorry my review was delayed. 
 
Sue Hares

-Original Message-
From: Jay Borkenhagen [mailto:j...@braeburn.org] 
Sent: Thursday, January 18, 2018 9:36 AM
To: bruno.decra...@orange.com
Cc: Susan Hares; grow@ietf.org
Subject: Re: [GROW] Opsdir last call review of draft-ietf-grow-bgp-gshut-13

Distro cut *way* down.

Regarding the suggestion for "logging knobs":

- if it's just logging that a gshut action was taken, that's a local
  implementation decision -- no need to mention it in the draft.

- if it's "Possibly raising alarms when something seems wrong", that
  would be a bad idea.  There *will* be instances when traffic remains
  on the link even after the graceful shutdown initiator has signaled
  an approaching shutdown.

To keep things simple and to allow the gshut draft to continue making
progress, I'd prefer to leave it as-is.

Thanks.

Jay B.


bruno.decra...@orange.com writes:
 > OK,
 > Thanks Susan.
 >
 > --Bruno
 >
 >  > -Original Message-
 >  > From: Susan Hares [mailto:sha...@ndzh.com]  >  > Sent: Thursday,
January 18, 2018 12:25 PM  >  > To: DECRAENE Bruno IMT/OLN  >  > Cc:
grow@ietf.org; draft-ietf-grow-bgp-gshut@ietf.org; i...@ietf.org;
ops-...@ietf.org  >  > Subject: RE: Opsdir last call review of
draft-ietf-grow-bgp-gshut-13  >  >  >  > Bruno:
 >  > 
 >  > I'm sorry I'm this late for the review.   On the editorial nit, if you
think it helps - send it to the RFC
 >  > editor.
 >  >
 >  > On the logging knobs,  you understood my point.  Logs should cover
what is section 4.2.  However,  >  > since the document is in the RFC
editor's queue - it is your choice.  If you get a chance to edit it in -  >
> fine.  If not, those people who implement the gshut will probably put it
in.
 >  >
 >  > Thanks for asking,  Susan Hares
 >  >
 >  > -----Original Message-
 >  > From: bruno.decra...@orange.com [mailto:bruno.decra...@orange.com]
 >  > Sent: Thursday, January 18, 2018 6:19 AM  >  > To: Susan Hares  >  >
Cc: grow@ietf.org; draft-ietf-grow-bgp-gshut@ietf.org; i...@ietf.org;
ops-...@ietf.org  >  > Subject: RE: Opsdir last call review of
draft-ietf-grow-bgp-gshut-13  >  >  >  > Hi Susan,  >  >  >  > Thanks for
your time reviewing this document and you below comments.
 >  >
 >  > Please see my replies inline [Bruno]  >  >  >  > Note that however
fast I'm answering to your review, that document is now in RFC editor queue,
>  > and hence technical changes are much more difficult. (AFAIK, would
require specific approval  >  > from the responsible AD). Thanks for taking
this into account.
 >  >
 >  >
 >  >
 >  >  > -Original Message-
 >  >  > From: Susan Hares [mailto:sha...@ndzh.com]  > Sent: Thursday,
January 18, 2018 9:46 AM  >  >  > To: ops-...@ietf.org  > Cc: grow@ietf.org;
draft-ietf-grow-bgp-gshut@ietf.org; i...@ietf.org  >  >  > Subject:
Opsdir last call review of draft-ietf-grow-bgp-gshut-13  >  > Reviewer:
Susan Hares  >  >  > Review result: Has Nits  >  > Status: Nits  >  > The
operational procedures described in this  >  > process for the gshut comment
are  > accurately covered, and SHOULD work well.  The  >  > Appendices A-C
add to an  > operations document and should be retained for publication.
 >  >
 >  > [Bruno] ok, thanks.
 >  >
 >  >  > Technical nit:
 >  >  > location of technical nit: (section 4.3)  > The document indicats
that the "BGP implementers  >  > SHOULD provide configuration  > knobs that
utilize teh GRACEFUL_SHUTDOWN community."
 >  >  >
 >  >  > What the problem is:
 >  >  > The document does not say is that their should be error reporting
knobs to  > track the use of  >  > GRACEFUL_SHUTDOWN community.  This can go
in section 4.3 in  > one or two sentences.
 >  >
 >  > [Bruno]
 >  > Could you pleas

[GROW] Opsdir last call review of draft-ietf-grow-bgp-gshut-13

[Susan Hares]

Reviewer: Susan Hares
Review result: Has Nits

Status: Nits

The operational procedures described in this process for the gshut comment are
accurately covered, and SHOULD work well.  The Appendices A-C add to an
operations document and should be retained for publication.

Technical nit:
location of technical nit: (section 4.3)
The document indicats that the "BGP implementers SHOULD provide configuration
knobs that utilize teh GRACEFUL_SHUTDOWN community."

What the problem is:
The document does not say is that their should be error reporting knobs to
track the use of GRACEFUL_SHUTDOWN community.  This can go in section 4.3 in
one or two sentences.

Editorial nit:
section 3. paragraph 2, p. 3

/This is because alternate paths can be hidden by knodes of an AS./
commment:  The implied "this" is too vague for a specification.

Fix:/This lack of path occurs because alternate paths can be hidden by nodes of
an AS."/


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

Re: [GROW] [Idr] Are there IDR drafts the Grow WG needs completed quickly?

[Susan Hares]

Bruno:

Thank you for letting John and I know you found the best solution.  

Sue Hares 

-Original Message-
From: bruno.decra...@orange.com [mailto:bruno.decra...@orange.com] 
Sent: Thursday, July 20, 2017 8:37 AM
To: Susan Hares
Cc: i...@ietf.org; grow@ietf.org; 'Job Snijders'; 'Christopher Morrow'
Subject: RE: [Idr] Are there IDR drafts the Grow WG needs completed quickly?

Hi Susan, all

> From Susan Hares
 > Sent: Thursday, July 20, 2017 10:53 AM
 
 >
 > Job:
 >
 > If this solution was good was the best solution,  there is no further
work.
 
This is the case.
 
 > If this solution was due to the slow progress of IDR, I'd like to know.
 > We've been trying to fast track all operator needs.

As the author of the offending sentence/slide and co-author of the g-shut
document, I can assure you that I had zero (b) intention to put the
responsibility on IDR or on an IDR draft (a).
I'm sorry if it felt that way.

--Bruno

(a) Plus being an author of draft-ietf-idr-reserved-extended-communities, I
would have been the one to blame.
(b) zero as per https://en.wikipedia.org/wiki/0 not as per
https://en.wikipedia.org/wiki/Zero-point_energy

 >
 > Sue
 >
 > -Original Message-
 > From: Job Snijders [mailto:j...@ntt.net]  > Sent: Thursday, July 20, 2017
4:42 AM  > To: Christopher Morrow  > Cc: Susan Hares; i...@ietf.org List;
grow@ietf.org grow@ietf.org  > Subject: Re: [Idr] Are there IDR drafts the
Grow WG needs completed quickly?
 >
 > On Thu, Jul 20, 2017 at 10:33:04AM +0200, Christopher Morrow wrote:
 > > On Thu, Jul 20, 2017 at 9:57 AM, Susan Hares <sha...@ndzh.com> wrote:
 > > > As the IDR co-chairs sat in the grow meeting, we heard of an IDR  > >
> draft that was so long in becoming an RFC that the Grow authors took  > >
> another approach (which was less desired).
 > >
 > > I'm unsure what draft this is? this might be the gshut draft?
 >
 > GROW's draft-ietf-grow-bgp-gshut had a dependency on  >
draft-ietf-idr-reserved-extended-communities which related to  >
draft-ietf-idr-as4octet-extcomm-generic-subtype - eventually this was  >
resolved by just working with RFC 1997 well-known communities.
 >
 > Kind regards,
 >
 > Job
 >
 > ___
 > Idr mailing list
 > i...@ietf.org
 > https://www.ietf.org/mailman/listinfo/idr


_

Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
exploites ou copies sans autorisation. Si vous avez recu ce message par
erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les
pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.

This message and its attachments may contain confidential or privileged
information that may be protected by law; they should not be distributed,
used or copied without authorisation.
If you have received this email in error, please notify the sender and
delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.


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

Re: [GROW] [Idr] Are there IDR drafts the Grow WG needs completed quickly?

[Susan Hares]

Thank you for reference to Ericsson’s implementation.  Please send me offline a 
contact for this implementation. 

 

Sue 

 

From: Idr [mailto:idr-boun...@ietf.org] On Behalf Of Jeff Tantsura
Sent: Thursday, July 20, 2017 5:41 AM
To: Susan Hares; 'Peter Schoenmaker'; 'Christopher Morrow'
Cc: i...@ietf.org; grow@ietf.org
Subject: Re: [Idr] Are there IDR drafts the Grow WG needs completed quickly?

 

Sue/ draft-ietf-idr-best-external authors,

 

Don’t recall call for implementations, there’s an implementation in Ericsson’s 
SEOS/IPOS 

 

Cheers,

Jeff

From: Idr <idr-boun...@ietf.org> on behalf of Susan Hares <sha...@ndzh.com>
Date: Thursday, July 20, 2017 at 11:24
To: 'Peter Schoenmaker' <p...@lugs.com>, 'Christopher Morrow' 
<christopher.mor...@gmail.com>
Cc: <i...@ietf.org>, <grow@ietf.org>
Subject: Re: [Idr] Are there IDR drafts the Grow WG needs completed quickly?

 

Peter:

 

After discussion on the WG list, the draft-ietf-idr-best-external decided to 
revise their approach.  We are awaiting the authors to indicate: a) draft is 
now ready for WG LC, and b) there are implementations. 

 

Perhaps the authors could let you on by responding to this email. 

 

Sue 

 

From: Idr [mailto:idr-boun...@ietf.org] On Behalf Of Peter Schoenmaker
Sent: Thursday, July 20, 2017 5:14 AM
To: 'Christopher Morrow'; Susan Hares
Cc: i...@ietf.org; grow@ietf.org
Subject: Re: [Idr] Are there IDR drafts the Grow WG needs completed quickly?

 

Hi Sue,

 

I don’t believe that there are any more drafts dependant on work progressing 
through idr.

 

gshut had additional reasons for not progressing, which have been solved and 
last call will be issued.

 

The gshut draft has an informative reference to draft-ietf-idr-best-external.  
I see from the mailing list there was a last call, but no conclusion, and the 
draft subsequently expired.  Is there an expectation this draft will continue 
to progress?

 

thanks

 

peter

 

 

On 20 July 2017 at 10:41:22, Susan Hares (sha...@ndzh.com) wrote:

Chris: 

 

Yes – it is gshust. 

Please see slide 3 of the gshut presentation. 

  

Waiting for the dependency on a draft 

-  Draft-ietf-idr-reserved-extended-communities

-  Draft-ietf-idr-as4octet-exztcomm-generic-subtype 

 

We will do early allocation of code points for any draft adopted by IDR.   
Either the authors or another WG can asked us to do these early code point 
allocation. 

 

See 

 

From: Idr [mailto:idr-boun...@ietf.org] On Behalf Of Christopher Morrow
Sent: Thursday, July 20, 2017 4:33 AM
To: Susan Hares
Cc: i...@ietf.org List; grow@ietf.org grow@ietf.org
Subject: Re: [Idr] Are there IDR drafts the Grow WG needs completed quickly?

 

 

On Thu, Jul 20, 2017 at 9:57 AM, Susan Hares <sha...@ndzh.com> wrote:

Grow and IDR groups: 

 

As the IDR co-chairs sat in the grow meeting, we heard of an IDR draft that was 
so long in becoming an RFC that the Grow authors took another approach (which 
was less desired).  

 

I'm unsure what draft this is? this might be the gshut draft?

I don't believe we have other work waiting in a similar state, Peter, do any 
come to mind for you?

 

 

We would like to know what IDR drafts need to be moved forward quickly.  If you 
would send the name of these drafts to the chairs, it would help us push 
forward these critical drafts.  You can send these names in response to this 
email or send a private note to the IDR chairs. 

 

Sue Hares

 

___ 
Idr mailing list 
i...@ietf.org 
https://www.ietf.org/mailman/listinfo/idr 

___ Idr mailing list i...@ietf.org 
https://www.ietf.org/mailman/listinfo/idr 

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

Re: [GROW] [Idr] Are there IDR drafts the Grow WG needs completed quickly?

[Susan Hares]

Peter:

 

After discussion on the WG list, the draft-ietf-idr-best-external decided to 
revise their approach.  We are awaiting the authors to indicate: a) draft is 
now ready for WG LC, and b) there are implementations. 

 

Perhaps the authors could let you on by responding to this email. 

 

Sue 

 

From: Idr [mailto:idr-boun...@ietf.org] On Behalf Of Peter Schoenmaker
Sent: Thursday, July 20, 2017 5:14 AM
To: 'Christopher Morrow'; Susan Hares
Cc: i...@ietf.org; grow@ietf.org
Subject: Re: [Idr] Are there IDR drafts the Grow WG needs completed quickly?

 

Hi Sue,

 

I don’t believe that there are any more drafts dependant on work progressing 
through idr.

 

gshut had additional reasons for not progressing, which have been solved and 
last call will be issued.

 

The gshut draft has an informative reference to draft-ietf-idr-best-external.  
I see from the mailing list there was a last call, but no conclusion, and the 
draft subsequently expired.  Is there an expectation this draft will continue 
to progress?

 

thanks

 

peter

 

 

On 20 July 2017 at 10:41:22, Susan Hares (sha...@ndzh.com) wrote:

Chris: 

 

Yes – it is gshust. 

Please see slide 3 of the gshut presentation. 

  

Waiting for the dependency on a draft 

-  Draft-ietf-idr-reserved-extended-communities

-  Draft-ietf-idr-as4octet-exztcomm-generic-subtype 

 

We will do early allocation of code points for any draft adopted by IDR.   
Either the authors or another WG can asked us to do these early code point 
allocation. 

 

See 

 

From: Idr [mailto:idr-boun...@ietf.org] On Behalf Of Christopher Morrow
Sent: Thursday, July 20, 2017 4:33 AM
To: Susan Hares
Cc: i...@ietf.org List; grow@ietf.org grow@ietf.org
Subject: Re: [Idr] Are there IDR drafts the Grow WG needs completed quickly?

 

 

On Thu, Jul 20, 2017 at 9:57 AM, Susan Hares <sha...@ndzh.com> wrote:

Grow and IDR groups: 

 

As the IDR co-chairs sat in the grow meeting, we heard of an IDR draft that was 
so long in becoming an RFC that the Grow authors took another approach (which 
was less desired).  

 

I'm unsure what draft this is? this might be the gshut draft?

I don't believe we have other work waiting in a similar state, Peter, do any 
come to mind for you?

 

 

We would like to know what IDR drafts need to be moved forward quickly.  If you 
would send the name of these drafts to the chairs, it would help us push 
forward these critical drafts.  You can send these names in response to this 
email or send a private note to the IDR chairs. 

 

Sue Hares

 

___ 
Idr mailing list 
i...@ietf.org 
https://www.ietf.org/mailman/listinfo/idr 

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

Re: [GROW] [Idr] Are there IDR drafts the Grow WG needs completed quickly?

[Susan Hares]

Job: 

If this solution was good was the best solution,  there is no further work. 

If this solution was due to the slow progress of IDR, I'd like to know.
We've been trying to fast track all operator needs. 

Sue 

-Original Message-
From: Job Snijders [mailto:j...@ntt.net] 
Sent: Thursday, July 20, 2017 4:42 AM
To: Christopher Morrow
Cc: Susan Hares; i...@ietf.org List; grow@ietf.org grow@ietf.org
Subject: Re: [Idr] Are there IDR drafts the Grow WG needs completed quickly?

On Thu, Jul 20, 2017 at 10:33:04AM +0200, Christopher Morrow wrote:
> On Thu, Jul 20, 2017 at 9:57 AM, Susan Hares <sha...@ndzh.com> wrote:
> > As the IDR co-chairs sat in the grow meeting, we heard of an IDR 
> > draft that was so long in becoming an RFC that the Grow authors took 
> > another approach (which was less desired).
> 
> I'm unsure what draft this is? this might be the gshut draft?  

GROW's draft-ietf-grow-bgp-gshut had a dependency on
draft-ietf-idr-reserved-extended-communities which related to
draft-ietf-idr-as4octet-extcomm-generic-subtype - eventually this was
resolved by just working with RFC 1997 well-known communities.

Kind regards,

Job

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

Re: [GROW] [Idr] Are there IDR drafts the Grow WG needs completed quickly?

[Susan Hares]

Chris: 

 

Yes – it is gshust. 

Please see slide 3 of the gshut presentation. 

  

Waiting for the dependency on a draft 

-  Draft-ietf-idr-reserved-extended-communities

-  Draft-ietf-idr-as4octet-exztcomm-generic-subtype 

 

We will do early allocation of code points for any draft adopted by IDR.   
Either the authors or another WG can asked us to do these early code point 
allocation. 

 

See 

 

From: Idr [mailto:idr-boun...@ietf.org] On Behalf Of Christopher Morrow
Sent: Thursday, July 20, 2017 4:33 AM
To: Susan Hares
Cc: i...@ietf.org List; grow@ietf.org grow@ietf.org
Subject: Re: [Idr] Are there IDR drafts the Grow WG needs completed quickly?

 

 

On Thu, Jul 20, 2017 at 9:57 AM, Susan Hares <sha...@ndzh.com> wrote:

Grow and IDR groups: 

 

As the IDR co-chairs sat in the grow meeting, we heard of an IDR draft that was 
so long in becoming an RFC that the Grow authors took another approach (which 
was less desired).  

 

I'm unsure what draft this is? this might be the gshut draft?

I don't believe we have other work waiting in a similar state, Peter, do any 
come to mind for you?

 

 

We would like to know what IDR drafts need to be moved forward quickly.  If you 
would send the name of these drafts to the chairs, it would help us push 
forward these critical drafts.  You can send these names in response to this 
email or send a private note to the IDR chairs. 

 

Sue Hares

 

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

[GROW] Are there IDR drafts the Grow WG needs completed quickly?

[Susan Hares]

Grow and IDR groups: 

 

As the IDR co-chairs sat in the grow meeting, we heard of an IDR draft that
was so long in becoming an RFC that the Grow authors took another approach
(which was less desired).  

 

We would like to know what IDR drafts need to be moved forward quickly.  If
you would send the name of these drafts to the chairs, it would help us push
forward these critical drafts.  You can send these names in response to this
email or send a private note to the IDR chairs. 

 

Sue Hares

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

Re: [GROW] [Sidrops] operator inputs -- route leak solution

[Susan Hares]

Brian, Sriram and Randy: 

 

 

Let me suggest we take the rest of this discussion on these IDR two drafts 
offline from IDR.  The IDR Chairs noted  when the 
draft-ietf-idr-route-leak-detection mitigation was adopted  that there was 
overlap between you two documents.  We also noted interests in both technical 
approaches.  We asked to you provide a combined document that the chairs could 
present to the IDR WG.  This IETF is a wonderful time to work on this project.  
 Chicago has many fine establishments in which to discuss this combined 
document.   

 

I suggest we focused on the technical issues on the IDR mail lists.  For 
discussions of IDR on the grow list, I suggest that we listen to the valuable 
input from the operators on what their needs and ask clarifying questions.  

 

 

Thank you, 

 

Sue Hares 

 

From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Brian Dickson
Sent: Wednesday, March 22, 2017 9:10 PM
To: Randy Bush
Cc: i...@ietf.org; 
draft-ietf-idr-route-leak-detection-mitigation.auth...@ietf.org; grow@ietf.org; 
sidr wg list (s...@ietf.org); sidr...@ietf.org
Subject: Re: [GROW] [Sidrops] operator inputs -- route leak solution

 

On Wed, Mar 22, 2017 at 4:50 PM, Randy Bush  wrote:

> SIDR/GROW/IDR and well documented in IDR (see Section 4)
> ( 
> https://tools.ietf.org/html/draft-ietf-idr-route-leak-detection-mitigation-06 
>  ).
> The solution involves AS-A setting a field (in an optional transitive
> attribute)

glad you liked the attribute approach well enough to plagarize it from
our draft.  now you just need to change from misconfigurable statements
of relationships to plagarize the bgp open part of our draft and your
golden.

 

Randy,

 

With all due respect, your draft fails to acknowledge the earlier work by me 
(from 2012), outside of the recent drafts of which I am a co-author.

 

Specifically:

draft-dickson-sidr-route-leak-def (which became the basis for RFC 7908)

draft-dickson-sidr-route-leak-reqts

draft-dickson-sidr-route-leak-solns

 

So, perhaps it would be best to avoid claims of plagiarizing, when (a) there is 
clear evidence that the source of the material predates your work, and (b) when 
your work does not credit the original work by me.

 

Pot calling the kettle black, throwing stones in glass houses, and all that.

 

You might want to also read those (expired) I-Ds, to get clarity on preserving 
leak prevention across "special" peering sessions

They also cover the ability to prevent leaks, without requiring the disclosure 
of customer relationships -- something for which you have expressed a strong 
desire.

 

FWIW, I will be working with my co-authors on the relationship-disclosure 
detail.

 

Maybe we can schedule some white-board time in Chicago.

 

Brian

 

P.S.  It is "you're golden".

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

[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)

[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] Do you want BGP to extend the message size for all BGP messages or just UPDATES.

[Susan Hares]

Thomas:

 

I am simply commenting on RFC4271 and where this addition would be insert.  

 

This check for open length no greater than 4096 augment would be inserted in 
section 6.2 (Open Message Error), and the resulting error would be “open 
message error” (Event 22 in the FSM).   Please query the FSM for Event 22 , and 
you will see it causes the same results as Open Header length error.   

 

Sue 

 

From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Thomas Mangin
Sent: Sunday, March 12, 2017 6:13 AM
To: grow-boun...@ietf.org
Cc: grow@ietf.org
Subject: Re: [GROW] Do you want BGP to extend the message size for all BGP 
messages or just UPDATES.

 

Hello,

I would propose a draft wording change among the lines of what is here. I have 
not defined a name for the "extra capability buffer size", it may be advisable. 
So the wording is mostly to clarify the intend and not intended verbatim.

Thomas

--

Before

The BGP Extended Message Capability is a new BGP Capability [RFC5492]
defined with Capability code 6 and Capability length 0.

After

The BGP Extended Message Capability is a new BGP Capability [RFC5492]
defined with Capability code 6 and Capability length 2.

The capability value will be called "capability extra length" (encoded as 2 
octets).

The value of the "capability extra length" MUST be added to the OPEN
"Optional Parameters Length", and the "Optional Parameters" buffer extended
accordingly.

For backward compatibility with speakers not aware of this capability,
the data processed when only reading "Optional Parameters Length" of
"Optional Parameters" MUST provide a valid capability boundary.

Further drafts and RFC MUST explicitly indicate if any defined capability 
must be stored within the non-extended Optional Parameters buffer or
SHALL be added within the extended size.


Before

An implementation that advertises support for BGP Extended Messages
MUST be capable of receiving an UPDATE message with a length up to
and including 65535 octets.


After

An implementation that advertises support for BGP Extended Messages
MUST be capable of receiving messages with a length up to
and including 65535 octets, however the OPEN message length MUST still be
no greater than 4096.

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

Re: [GROW] Do you want BGP to extend the message size for all BGP messages or just UPDATES.

[Susan Hares]

Thomas: 

 

Real world testing is really, really important. 

 

If Quagga, Bird, or GoBGP have been run against test devices (IXIA, etc), the 
testers used to test against these cases.   Most of these took their initial 
code from open-source GateD which had this feature.  The open-source GateD was 
distributed into many different commercial code bases – there may be some hope. 

 

Cheerily, Sue Hares 

 

From: Thomas Mangin [mailto:thomas.man...@exa-networks.co.uk] 
Sent: Thursday, March 9, 2017 9:27 AM
To: n...@foobar.org
Cc: Susan Hares; 'Thomas Mangin'; grow@ietf.org
Subject: Re: [GROW] Do you want BGP to extend the message size for all BGP 
messages or just UPDATES.

 

Hi Nick,

Looking at Quagga, Bird, GoBGP (I took a few minutes to read their code and I 
am not overly familiar with any of them), they all seems  to perform the 4096 
bytes check and send NOTIFICATION, so I would only expect badly home brewed 
solution to suffer from the issue (not to say we should not care).

That said, I would also assume the code path for this scenario has never been 
run in production (and perhaps ever) in the life of any BGP implementation so 
while it may look good, it may not do what is expected. I believe some "real" 
world testing is in order 

Thomas

On 2017-03-09 12:20, Nick Hilliard wrote:

Sue: I'd be cautious with your approach.  First, it's not guaranteed
that some badly coded bgp stack wouldn't crash with a 4097 byte OPEN
message, and secondly, you're not guaranteed that just because the stack
supports 4097 bytes on open due to e.g. unintentional coding reasons,
that it actually supports 4097 bytes by design and that it actually
works properly.

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

Re: [GROW] Do you want BGP to extend the message size for all BGP messages or just UPDATES.

[Susan Hares]

Thomas: 

It is possible to create an option that requires implementation support
extended messages upon receiving a notification.  If the sequence is: 
Open-(4097 bytes) --> 
 <-notification (with indication message length is too long)


(sequence allowed RFC4271 current FSM) 
The extended messages would know to back down to 4096 and negotiate forward.
This would not let your BGP speaker get stuck.  It seems reasonable to make
the code take care of this problem rather than have a crisis in an
operator's day. 

Open (< 4096) bytes) ---> 

Just let us know what you want. 

Sue 


-Original Message-
From: Thomas Mangin [mailto:thomas.man...@exa.net.uk] 
Sent: Tuesday, March 7, 2017 4:39 PM
To: grow@ietf.org
Cc: Susan Hares
Subject: Re: [GROW] Do you want BGP to extend the message size for all BGP
messages or just UPDATES.

Hello Nick,

I can see one reason why it would become undesirable in the future: 

If a then recent speaker, with support with this draft/RFC, and with a
yet-to be defined large number of capabilities, happened to generate an OPEN
message of 4097 bytes (to match its configuration), this OPEN would most
likely be seen as invalid by current implementations not supporting the
extension.
The excessive/invalid length when checking the OPEN message size will surely
caused the session to be terminated.

It would therefore prevent any session to come up (even if otherwise
everything is fine). Therefore should this size extension be applied, it
should be applied to all message types BUT the OPEN message. I think we are
currently not near needing 4096 bytes for OPEN (but the day will/may come).

ExaBGP would suffer from this issue as the check is currently performed on
ALL messages as currently specified including the OPEN.

So I would suggest to just change the wording to include all message type
but OPEN, and leave it as an exercise to the reader to write another draft
allowing to break capabilities over multiple messages.

Sincerely,

Thomas

> On 7 Mar 2017, at 21:08, Nick Hilliard <n...@foobar.org> wrote:
> 
> Susan Hares wrote:
>> This email is to make you aware of the discussion on the Extended
>> Messages draft (draft-ietf-idr-bgp-extended-messages-21).   Do you
>> want the message size extended for all BGP messages or just UPDATE
>> messages?   This probably is more important if you want to have a
>> larger size OPEN, ROUTE-REFESH, and UPDATES.The IDR co-chairs
>> value the operational input from GROW WG.
> 
> I don't see any reason an extended message size should be limited to 
> just UPDATEs. Enke's suggestion for handling the single anomalous case
> (OPEN) looks reasonable.  I'd say, go for it!
> 
> Nick
> 
> ___
> 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] Do you want BGP to extend the message size for all BGP messages or just UPDATES.

[Susan Hares]

Grow WG: 

This email is to make you aware of the discussion on the Extended Messages 
draft (draft-ietf-idr-bgp-extended-messages-21).   Do you want the message size 
extended for all BGP messages or just UPDATE messages?   This probably is more 
important if you want to have a larger size OPEN, ROUTE-REFESH, and UPDATES.
The IDR co-chairs value the operational input from GROW WG.  

Sue Hares 

-Original Message-
From: Idr [mailto:idr-boun...@ietf.org] On Behalf Of Susan Hares
Sent: Monday, March 6, 2017 7:42 PM
To: 'Enke Chen'; 'Jeffrey Haas'; 'Alvaro Retana (aretana)'
Cc: idr-cha...@ietf.org; draft-ietf-idr-bgp-extended-messa...@ietf.org; 
i...@ietf.org
Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-extended-messages-20

Enke and IDR WG: 

If there is enough concern about the extended messages covering all messages 
versus UPDATE messages,  I will need to do  1 week call on this topic.  
 

Sue Hares 

-Original Message-
From: Enke Chen [mailto:enkec...@cisco.com]
Sent: Monday, March 6, 2017 3:22 PM
To: Jeffrey Haas; Alvaro Retana (aretana)
Cc: idr-cha...@ietf.org; draft-ietf-idr-bgp-extended-messa...@ietf.org; Susan 
Hares; i...@ietf.org; Enke Chen
Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-extended-messages-20

Hi, Folks:

I see benefits and no drawbacks for the "BGP-Extended Message Capability" to 
cover all the message types, that is, requiring a speaker that advertises the 
capability to be able to receiving large messages of any type.  While the 
requirement for the large message is driven by the UPDATE message, other 
messages (such as NOTIFICATION or OPEN) can potentially exceed the 4K message 
size as well. It is better to deal with this issue once.

Clearly a large UPDATE message may require a large NOTIFICATION message, e.g., 
for carrying a malformed attribute.

Regarding the OPEN message, as BGP capabilities are carried inside the OPEN 
message and a number of capabilities are AFI/SAFI specific and thus have the 
"multiplier"
effect on the message size, potentially the OPEN message may exceed the message 
size in the future. This "extended message capability" can be used in a couple 
of ways to deal with the large OPEN message if the capability is made to mean 
support for all message types:

   o A speaker can remember the capability from its previous OPEN, and infer 
that
 the large message is most likely supported over the current session, and 
send
 the large OPEN message if needed. (It can back off from sending the large 
OPEN
 based on NOTIFICATION message.)

   o A speaker can send a normal OPEN, and once it determines from the received
 OPEN message that the large message capability is supported by the remote
 speaker, the speaker can close the connection and start with a large OPEN.

Admittedly these mechanism are not as elegant as the one that bumps the BGP 
version.
They can be just as effective (especially the first one) in practice.

Thanks.  -- Enke

On 2/28/17 1:06 PM, Jeffrey Haas wrote:
> Alvaro,
> 
> I'm not speaking for the authors.  However, a few comments on your writeup:
> 
> On Thu, Feb 23, 2017 at 07:17:05PM +, Alvaro Retana (aretana) wrote:
>> M1. Section 4. (Operation): “An implementation that supports the BGP 
>> Extended Messages MUST be prepared to receive an UPDATE message that 
>> is larger than 4096 bytes.“  Only UPDATEs?  I know that the most 
>> likely case for exceeding the 4k size is an UPDATE, but why are the 
>> other messages not considered?
> 
> The fundamental issue is with regards to not only the basic behavior 
> of RFC 4271 and its earlier RFC 1771 but also to BGP Versioning.
> 
> Those RFCs set the expectation that version 4 of BGP will have at most 
> a 4k packet size.  Capability advertisement, an extension on top of 
> BGP, isn't a required feature - although it's certainly very common these 
> days.
> 
> Thus, for backward compatibility reasons, OPEN messages must be no 
> bigger than 4k if we're still BGP-4.
> 
> I don't think there's an argument for larger KEEPALIVE messages. :-)
> 
> Similarly, the NOTIFICATION with no restrictions for version 
> compatibility reasons.  *However*, once BGP has reached the 
> Established state, it is possible for it to send longer NOTIFICATION 
> messages, if we permitted it and the feature was duly negotiated.
> This is probably not the best idea because it will still be necessary 
> to be able to deal with an old speaker in such cases.
> 
> Also, most implementations don't dump that much information in the 
> NOTIFICATION Data section.  Putting sufficient semantics on the 
> content would start to get messy.  We don't want XML or backtrace over that 
> message.
> 
> The case for UPDATE is clear.
> 
> The remaining message with some potential motivation is ROUTE-REFRESH.  
> The basic re

Re: [GROW] [Idr] 2 week WG LC for draft-ietf-idr-shutdown-02 (1/17 to 1/31/2017) - extended 2 weeks (1/31 to 2/14/2017 - Last Day

[Susan Hares]

There have no additional comments on draf-ietf-idr-shutdown-06.txt.  The IDR
WG has consensus on this draft that it is ready to publish.  It has 6
implementations.  It has been sent to the IESG.

 

Sue Hares 

 

From: Idr [mailto:idr-boun...@ietf.org] On Behalf Of Susan Hares
Sent: Monday, February 13, 2017 2:17 PM
To: i...@ietf.org
Cc: grow@ietf.org
Subject: [Idr] 2 week WG LC for draft-ietf-idr-shutdown-02 (1/17 to
1/31/2017) - extended 2 weeks (1/31 to 2/14/2017 - Last Day

 

The time period for comments on draft-ietf-idr-shutdown was extended for 2
weeks, but in that last 2 weeks there has been no mail regarding this draft.
If you were going to comment on this draft, please send it to the
i...@ietf.org list within 24 hours.  

 

At this point, the result of the 4 week WG LC is that the IDR Working group
has reached consensus to publish this draft.  The authors have resolved the
early review by the routing directorate and there are 6 implementations.
Unless something is earth shattering this draft will be sent to the IESG for
publication on 2/14/2017. 

 

Sue Hares 

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

[GROW] [Idr] 2 week WG LC for draft-ietf-idr-shutdown-02 (1/17 to 1/31/2017) - extended 2 weeks (1/31 to 2/14/2017 - Last Day

[Susan Hares]

The time period for comments on draft-ietf-idr-shutdown was extended for 2
weeks, but in that last 2 weeks there has been no mail regarding this draft.
If you were going to comment on this draft, please send it to the
i...@ietf.org list within 24 hours.  

 

At this point, the result of the 4 week WG LC is that the IDR Working group
has reached consensus to publish this draft.  The authors have resolved the
early review by the routing directorate and there are 6 implementations.
Unless something is earth shattering this draft will be sent to the IESG for
publication on 2/14/2017. 

 

Sue Hares 

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

Re: [GROW] ietf 97 agenda

[Susan Hares]

Thanks!  

 

Sue 

 

From: Christopher Morrow [mailto:christopher.mor...@gmail.com] 
Sent: Saturday, November 12, 2016 8:05 PM
To: Susan Hares
Cc: joel jaeggli; Peter Schoenmaker; grow@ietf.org grow@ietf.org
Subject: Re: [GROW] ietf 97 agenda

 

Also, draft agenda updated.

 

On Sat, Nov 12, 2016 at 5:04 PM, Christopher Morrow 
<christopher.mor...@gmail.com> wrote:

 

 

On Sat, Nov 12, 2016 at 4:14 PM, Susan Hares <sha...@ndzh.com> wrote:

Chris and Joel:

Would it be possible to move the Large communities (#3) and Why IDR does not
know about OPS requirements (#5) together?  I will be leaving my other WG
meeting (TRILL) to attend this portion of GROW.  I am very interested to
listen to feedback on large communities and IDR process.

 

sure, what if we move those to the end of the talk time?

 

Thank you
Sue Hares
(IDR Co-chair)

> 1 - Admin data / Draft Status10 min
> 2 - Grow-Bgp-reject - job 5 min
> 3 - Large-Communities - job  15 min
> 4 - opsec-urpf-improvements - sriram 15 min
> 5 - Why doesn't IDR know about Ops Requirements? 10 min

-Original Message-
From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of joel jaeggli
Sent: Friday, November 11, 2016 9:56 PM
To: Christopher Morrow; Peter Schoenmaker
Cc: grow@ietf.org
Subject: Re: [GROW] ietf 97 agenda

On 11/12/16 11:53 AM, Christopher Morrow wrote:
> howdy grow folks, I uploaded a draft agenda, things will likely
> change... here's the data so far:
>
> 1 - Admin data / Draft Status10 min
> 2 - Grow-Bgp-reject - job 5 min
> 3 - Large-Communities - job  15 min
> 4 - opsec-urpf-improvements - sriram 15 min
> 5 - Why doesn't IDR know about Ops Requirements? 10 min

interested in this one. especially what we can take away that's actionable
from the discussion.

> happy to accept changes/updates/etc. we have a 1hr slot... my math
> says there's 5 min left, though we can re-adjust some as required.
>
> -chris
>
>
> On Thu, Sep 29, 2016 at 7:15 AM, Peter Schoenmaker <p...@lugs.com
> <mailto:p...@lugs.com>> wrote:
>
> Hello,
>
> __ __
>
> IETF 97 is fast approaching.  At IETF 96 in Berlin we did not meet.
> GROW is planning to meet in Seoul if we have agenda items.  People
> who would like time on the agenda please send a request so that a
> time slot and agenda can be prepared.
>
> __ __
>
> thanks
>
> __ __
>
> peter & chris
>
> __ __
>
> __ __
>
>
> ___
> GROW mailing list
> GROW@ietf.org <mailto:GROW@ietf.org>
> https://www.ietf.org/mailman/listinfo/grow
> <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] ietf 97 agenda

[Susan Hares]

Chris and Joel: 

Would it be possible to move the Large communities (#3) and Why IDR does not
know about OPS requirements (#5) together?  I will be leaving my other WG
meeting (TRILL) to attend this portion of GROW.  I am very interested to
listen to feedback on large communities and IDR process.  

Thank you 
Sue Hares 
(IDR Co-chair) 

> 1 - Admin data / Draft Status10 min
> 2 - Grow-Bgp-reject - job 5 min
> 3 - Large-Communities - job  15 min
> 4 - opsec-urpf-improvements - sriram 15 min
> 5 - Why doesn't IDR know about Ops Requirements? 10 min

-Original Message-
From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of joel jaeggli
Sent: Friday, November 11, 2016 9:56 PM
To: Christopher Morrow; Peter Schoenmaker
Cc: grow@ietf.org
Subject: Re: [GROW] ietf 97 agenda

On 11/12/16 11:53 AM, Christopher Morrow wrote:
> howdy grow folks, I uploaded a draft agenda, things will likely 
> change... here's the data so far:
> 
> 1 - Admin data / Draft Status10 min
> 2 - Grow-Bgp-reject - job 5 min
> 3 - Large-Communities - job  15 min
> 4 - opsec-urpf-improvements - sriram 15 min
> 5 - Why doesn't IDR know about Ops Requirements? 10 min

interested in this one. especially what we can take away that's actionable
from the discussion.

> happy to accept changes/updates/etc. we have a 1hr slot... my math 
> says there's 5 min left, though we can re-adjust some as required.
> 
> -chris
> 
> 
> On Thu, Sep 29, 2016 at 7:15 AM, Peter Schoenmaker  > wrote:
> 
> Hello,
> 
> __ __
> 
> IETF 97 is fast approaching.  At IETF 96 in Berlin we did not meet. 
> GROW is planning to meet in Seoul if we have agenda items.  People
> who would like time on the agenda please send a request so that a
> time slot and agenda can be prepared.
> 
> __ __
> 
> thanks
> 
> __ __
> 
> peter & chris
> 
> __ __
> 
> __ __
> 
> 
> ___
> 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] Working Group Adoption Call: draft-mauch-bgp-reject

[Susan Hares]

Support.  Warren – I agree with your comment.

 

Sue 

 

From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Warren Kumari
Sent: Monday, November 02, 2015 2:19 AM
To: Christopher Morrow
Cc: grow-cha...@ietf.org; grow@ietf.org grow@ietf.org; grow-...@tools.ietf.org
Subject: Re: [GROW] Working Group Adoption Call: draft-mauch-bgp-reject

 



On Monday, November 2, 2015, Christopher Morrow  
wrote:

Howdy Grow folk (again),
Please consider this as the start of a 3wk working group adoption call
for the subject draft who's abstract is:

  "This document defines the default behaviour of a BGP speaker when no
   explicit policy is associated with a BGP peering session."

Please read/comment/advise before 11/23/2015 - Nov 23, 2015.

 

 

Yah.

 

This shouldn't be needed... but is. 

Support adoption, willing to edit / contribute / review / whatever is needed.

 

W

 

 

Thanks!
-chris
grow-co-chair

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



-- 
I don't think the execution is relevant when it was obviously a bad idea in the 
first place.
This is like putting rabid weasels in your pants, and later expressing regret 
at having chosen those particular rabid weasels and that pair of pants.
   ---maf

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

Re: [GROW] Working Group Adoption Call: draft-petrie-grow-mrt-add-paths

[Susan Hares]

Multiple paths are a fact of life in many BGP deployments.  Please accept
and publish soon. 

Sue Hares

-Original Message-
From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of heasley
Sent: Monday, November 02, 2015 11:25 AM
To: Jeffrey Haas
Cc: grow-cha...@ietf.org; grow@ietf.org grow@ietf.org;
grow-...@tools.ietf.org
Subject: Re: [GROW] Working Group Adoption Call:
draft-petrie-grow-mrt-add-paths

Mon, Nov 02, 2015 at 05:27:15PM +0900, Jeffrey Haas:
> > Please consider this the start of a 3 week Adoption call for the 
> > noted draft who's abstract is:
> >   "This document updates the Multi-threaded Routing Toolkit (MRT) export
> >   format for Border Gateway Protocol (BGP) routing information by
> >   extending it to support the Advertisement of Multiple Paths in BGP
> >   extensions."
> 
> IMO, this one is a no-brainer.  I encourage adoption, swift editing and
then ship as an RFC.

Agree with Jeff.

___
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] Grow has WG LC draft-ietf-grow-route-lead-problem Defintion

[Susan Hares]

IDR WG: 

 

Grow has complemented a WG last call on
draft-ietf-grow-route-leak-problem-definition  

(
http://datatracker.ietf.org/doc/draft-ietf-grow-route-leak-problem-definitio
n/). 

 

This draft is related to IDR mechanisms found in: 

 
http://datatracker.ietf.org/doc/draft-ietf-idr-route-leak-detection-mitigat
ion/ draft-ietf-idr-route-leak-detection-mitigation-00

 

If you would like to make comments on the grow draft, please respond to this
message. 

 

Sue Hares 

 

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

Re: [GROW] WGLC: draft-ietf-grow-route-leak-problem-definition (ends: 8/24/2015 - Aug 24)

[Susan Hares]

Siram: 

Do you want me to post this for a cross-review in IDR? 

Sue Hares 

-Original Message-
From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Sriram, Kotikalapudi
Sent: Tuesday, August 18, 2015 8:18 AM
To: George, Wes; Christopher Morrow; grow-cha...@ietf.org;
grow-...@tools.ietf.org; grow@ietf.org grow@ietf.org
Subject: Re: [GROW] WGLC: draft-ietf-grow-route-leak-problem-definition
(ends: 8/24/2015 - Aug 24)

Thank you, Wes.
The comments you've offered are greatly helpful for improving accuracy as
well as clarity in what is being said. 
I plan to incorporate them in the next revision (v. -03) soon.

Sriram   

From: GROW grow-boun...@ietf.org on behalf of George, Wes
wesley.geo...@twcable.com
Sent: Monday, August 17, 2015 2:45 PM
To: Christopher Morrow; grow-cha...@ietf.org; grow-...@tools.ietf.org;
grow@ietf.org grow@ietf.org
Subject: Re: [GROW] WGLC: draft-ietf-grow-route-leak-problem-definition
(ends: 8/24/2015 - Aug 24)

I've reviewed the latest version, and generally think that it is ready to
proceed once the below comments are addressed. A cross-review from IDR might
also be useful before it goes to IETF LC.

There are several areas in Section 3 where you use attack and leak
interchangeably in a way that adds a bit of confusion. I think it'd be
better to pick one and stick with it, probably leak rather than attack, and
only use attack if you are describing something that is almost always
malicious rather than accidental.
I.e.
attack type 1 - The update basically makes a
  U-turn at the attacker's multi-homed AS.  The attack (accidental
  or deliberate) often succeeds
Previously, you say that you refer to the leaking AS as the offending AS.
I'd suggest using that here instead of the attacker's. Similarly, you've
already said that most leaks are unintentional, so it might be better to
simplify that next sentence by saying the leak often succeeds
and eliminate the parenthetical. It is also unclear from the text exactly
what you mean by U-Turn (it's not going back the way it came, so actually
hairpin might be a better term), so a few words to clarify might be useful.
Type 2 - Update is crafted by the attacker...success of the attack - same
comment here about attack vs leak vs offending AS

Type 4 - While often the increase in prefixes causes its own problems
(dramatically increased routing table size, exceeded max prefix limit,
etc) you may want to add some text to the effect of these more specifics
may cause the routes to be preferred over other aggregate announcements,
thus redirecting traffic from its normal best path as that makes it clearer
what the impact of the leak is in this case.

Type 5 - I'm not sure that the terms lateral or non-hierarchically
peering really add a lot to the explanation. The rest of your text sounds
more like you're describing a non-transit relationship (typically only
announce their customer routes to each other), which I think would be an
easier term to define and more likely to be something readers would be
familiar with. Either way, the explanation in this section could benefit
from a good editing pass for clarity.

Type 6/7- its provider - do you mean its transit provider? Otherwise it's
unclear what distinguishes this from type 5, and again would be useful to
use transit/non-transit to clarify.

Also, an editorial nit/personal preference: since there are so few sections
to this document, it might be useful to take each of the subtypes and make
it a subsection of section 3 (e.g. 3.1 3.2, 3.3...), so that it's easier to
refer to it in text and reviews - subsections can have HTML anchors so that
you can link right to them, and they show up in the table of contents as
well.

Thanks,

Wes

___
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-bmp - ENDS: 8/7/2015 (aug 7 2015)

[Susan Hares]

Support publication 

Sue Hares 

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

Re: [GROW] [WGAC] Working group adoption call: draft-sriram-route-leak-problem-definition

[Susan Hares]

Support.  This is important work to address a key systemic issue with BGP.

Sue Hares 

-Original Message-
From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Christopher Morrow
Sent: Wednesday, November 12, 2014 9:24 PM
To: grow@ietf.org grow@ietf.org; grow-cha...@ietf.org
Subject: [GROW] [WGAC] Working group adoption call:
draft-sriram-route-leak-problem-definition

Howdy grow folks,
During the meeting on Monday Sriram brought up the topic of asking for
working-group adoption for this draft:

  draft-sriram-route-leak-problem-definition

The abstract is:
   A systemic vulnerability of the Border Gateway Protocol routing
   system, known as 'route leaks', has received significant attention in
   recent years.  Frequent incidents that result in significant
   disruptions to Internet routing are labeled route leaks, but to
   date we have lacked a common definition of the term.  In this
   document, we provide a working definition of route leaks, keeping in
   mind the real occurrences that have received significant attention.
   Further, we attempt to enumerate (though not exhaustively) different
   types of route leaks based on observed events on the Internet.  We
   aim to provide a taxonomy that covers several forms of route leaks
   that have been observed and are of concern to Internet user community
   as well as the network operator community.

Could we have a 2.5wk (so we don't end mid-week losing half a week to the
meeting) adoption thought/vote/discussion for this draft in GROW, please?

At the mic when asked about this topic there were roughly 20 or so folk in
favor of adoption, and none opposed to that direction.

-chris

___
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] Requesting Grow's review of draft-ietf-idr-as-private-reservation-02.txt

[Susan Hares]

Peter and Chris: 

 

We request that the GROW WG review
draft-ietf-idr-as-private-reservation-02.txt?
(http://datatracker.ietf.org/doc/draft-ietf-idr-as-private-reservation/)

 

Since it modifies RFC 1930, a BCP, it is likely to be a BCP.  The draft
deals with the creation of Private USE ASN space in 4 byte octets. 

 

Two additional questions we'd love input on:  

 

1. Do they think the range is too big, too small, or just right  (We'll
call this the 3 bears question (smile))

2. Would they prefer to see the range reserved with some portion of the
range allocated? 

 

For example, reserve all the space but allocate only 50% of the space. 

 

This draft has had substantial IDR debate which is (of course) online, and
has been through IDR WG LC. 

 

We'd appreciate hearing about any operational issues GROW finds with this
draft. 

 

Thank you, 

 

John and Sue 

 

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

Re: [GROW] Requesting Grow's review of draft-ietf-idr-as-private-reservation-02.txt

[Susan Hares]

(Reposting with time of 2 weeks) 

 

Peter and Chris: 

 

We request that the GROW WG review
draft-ietf-idr-as-private-reservation-02.txt?
(http://datatracker.ietf.org/doc/draft-ietf-idr-as-private-reservation/)

 

Since it modifies RFC 1930, a BCP, it is likely to be a BCP.  The draft
deals with the creation of Private USE ASN space in 4 byte octets. 

 

Two additional questions we'd love input on:  

 

1. Do they think the range is too big, too small, or just right  (We'll
call this the 3 bears question (smile))

2. Would they prefer to see the range reserved with some portion of the
range allocated? 

 

For example, reserve all the space but allocate only 50% of the space. 

 

This draft has had substantial IDR debate which is (of course) online, and
has been through IDR WG LC. 

 

We'd appreciate hearing about any operational issues GROW finds with this
draft by 1/4/2013.  (2 weeks) 

 

Thank you, 

 

John and Sue 

 

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