Subject: [GROW] WGLC - draft-ietf-grow-large-communities-usage - ENDS 04/06/2017 (Apr 6th)

From: Christopher Morrow <[email-masked]>
Date: Wed, 15 Mar 2017 11:16:12 -0400

Howdy wg folk,

Please consider this the start of a WGLC for the subject draft
(draft-ietf-grow-large-communities-usage), who's abstract is:

  "Examples and inspiration for operators to use BGP Large Communities."

Please review the last update:
  <https://tools.ietf.org/html/draft-ietf-grow-large-communities-usage-04>

and send comments/complaints/etc to the list for the authors to address.

Thanks!
-chris
co-chair

---

From: Job Snijders <[email-masked]>
Date: Mon, 20 Mar 2017 18:26:05 +0100

Hi Working group,

Like RFC 1998 was a companion document for RFC 1997 "what can you do
with this communities thing", draft-ietf-grow-large-communities-usage
was written to offer a companion document for RFC 8092. 

This informational document will come in handy in the second half of
this year, when RFC 8092 functionality is expected to become available
on a number of commonly deployed platforms.

draft-ietf-grow-large-communities-usage is _not_ intended to be a full
enumeration of everything that is possible (otherwise we'd never be
finished :-). But rather, to provide a concise set of examples which
highlight various angles on what network management with Large
Communities might look like.

Feedback on this WGLC would be appreciated!

Kind regards,

Job

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

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 20 Mar 2017 21:08:36 +0100 (CET)

> Feedback on this WGLC would be appreciated!

I have read this draft. Seems useful, I support publication.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: "Dickinson, Ian" <[email-masked]>
Date: Tue, 21 Mar 2017 10:48:43 +0000

I support publication of draft-ietf-grow-large-communities-usage

Ian

From: GROW [mailto:[email-masked]] On Behalf Of Christopher Morrow
Sent: 15 March 2017 15:16
To: [email-masked] [email-masked] <[email-masked]>; [email-masked]; [email-masked]
Subject: [GROW] WGLC - draft-ietf-grow-large-communities-usage - ENDS 04/06/2017 (Apr 6th)

Howdy wg folk,

Please consider this the start of a WGLC for the subject draft (draft-ietf-grow-large-communities-usage), who's abstract is:

Thanks!
-chris
co-chair

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

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 21 Mar 2017 16:55:16 -0400

> and send comments/complaints/etc to the list for the authors to address.

I read it.  Well written.  Useful examples.  I like the ISO-country code in
numeric form hack. (I had looked for something similar years ago and wasn't
aware of that standard.)

Ship it.

-- Jeff

---

From: Måns Nilsson <[email-masked]>
Date: Wed, 22 Mar 2017 06:17:18 +0100

> (draft-ietf-grow-large-communities-usage), who's abstract is:

I have read the document and I support its publication as RFC. 

-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
FUN is never having to say you're SUSHI!!

---

From: Adam Chappell <[email-masked]>
Date: Thu, 23 Mar 2017 15:41:03 +0100

I think the focus on RFC1998 Sec. 4 and the desire to be a practical
example, rather than an exhaustive list of possibilities is important.
With that in mind, I wonder if section 4.3 should really encourage
*location-based* manipulation of LOCAL_PREF?

(I must humbly acknowledge that the original text of the idea here was part
of a contribution I made).

Location-based AS_PATH prepend, and general manipulation of LOCAL_PREF all
fine and good, but would large-scale operators today really advise their
customers to make use of features to signal degree of preference
on sub-AS scale? The warning about preference -> selection -> advertisement
seems definitely appropriate.

There's a suggestion, for example, that I can put 2914:12:528 on my NTT
port in Amsterdam to ensure that I only receive traffic from outside the
Netherlands. I think we know that's not going to fly.

The idea is probably interesting to a customer, but the harsh reality is
that today's implementations don't cut it: the customer's BGP route is
tightly coupled to the part of the SP's network to which he connects, and
the route announcement is thus subject to the whims of the SP's BGP
topology - which he likely reserves the right to change - from that point
on.

Realistically what I generally see are advertisement suppression knobs to
influence inter-region (rather than country) propagation of a route.

So, with those practical considerations in mind, does this specific
technique really belong in a document that we'd like to be a best practice
or good example guide to be read by those setting their policies for what
Large Community attributes they will receive, process and act on?

-- Adam.

-- 

-- Adam.

---

From: Job Snijders <[email-masked]>
Date: Thu, 23 Mar 2017 10:16:19 -0500

> Large Community attributes they will receive, process and act on?

You are right, the technique somewhat relies on specific network
designs. 

What do you propose? Remove 4.3 in its entirety? If we only remove
section 4.3.2, the remainder of the section is essentially RFC 1998 in a
nutshell, so perhaps from a RFC stream continuity perspective, it is
redundant.

Alternatively, the text can be rewritten to refer to regions rather then
countries.

Kind regards,

Job

---

From: Adam Chappell <[email-masked]>
Date: Thu, 23 Mar 2017 16:57:56 +0100

Yes, agreed - 4.3.2 using the UN M.49 region codes might well be a better
idea.  At least allows us to demonstrate the technique in the document and
it not necessarily be unfeasible in production networks if someone decides
to use the example verbatim. And the change isn't huge either - will send
diff to you direct, Job.

-- Adam.

-- 

-- Adam.

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 23 Mar 2017 21:26:21 -0400

I presume that the authors will come to closure on the additional/changed
wording in 4.3.2, I'll start the publication request at this time noting
consensus was reached.

thanks!

---

From: Job Snijders <[email-masked]>
Date: Fri, 24 Mar 2017 08:38:43 -0500

> wording in 4.3.2, I'll start the publication request at this time noting

Adam contributed a patch, we'll post the new version on monday when the
draft submission tool opens up again:

    https://github.com/large-bgp-communities/usage/commit/28cc40d68d90f5915597720334e9773b3f131ea5

Kind regards,

Job

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 24 Mar 2017 12:04:46 -0400

thanks much! this was what I expected to happen.... I'm also positive that
people will turn knobs in the iesg review and the ietf last-call... :)

---

From: Christopher Morrow <[email-masked]>
Date: Sat, 25 Mar 2017 21:28:55 -0400

Oh Hai!

err... I prematurely sent this along to the IESG :( Joel held it up until
4/6 when we can see if the decision is 'needs more work' or 'go to iesg!'.

thanks joel!