Subject: Re: [GROW] [Idr] Request to adopt draft-heitz-idr-large-community - Working Group Adoption call (9/6 to 9/20)

From: Christopher Morrow <[email-masked]>
Date: Wed, 21 Sep 2016 11:53:28 -0400

+grow, they got lost somewhere on the way...
(grow folk interested might want to just go look at the archive:
  https://www.ietf.org/mail-archive/web/idr/current/msg16066.html
...which is this thread...

sadly this discussion is spread over at least:
  https://www.ietf.org/mail-archive/web/idr/current/msg16102.html
  https://www.ietf.org/mail-archive/web/idr/current/msg16066.html
  https://www.ietf.org/mail-archive/web/idr/current/msg16034.html
  https://www.ietf.org/mail-archive/web/idr/current/msg16009.html
)

On Wed, Sep 21, 2016 at 10:20 AM, Robert Raszuk <[email-masked]> wrote:

> I am sensing is that if they put -large on the 2016/2017/2018 BGP roadmaps
> next time their PMs will take a look at BGP communities topic will be at
> best 2025+.

I think ops folk understand that given enough thrust (money) vendors will
do all manner of things on-demand. I think it's not productive to really
talk about this here though, what's helpful is:

1) is -large still interesting?
    (seems like lots of 'yes pls' already)
2) is there room for improvement?
    (always, almost anyway)
3) should we try to improve/change -large or move that work to -wide or
-tlv or -other ?
    (seems like today we want -large to progress, and we should gather
requirements/options for -wide or -tlv or -other-thing)

Can we get some requirements discussions/writng going in grow and once
we're not spitballing come back to IDR with a useful set of requirements
and uss-cases?

-chris

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 21 Sep 2016 12:10:04 -0400

+grow

On Wed, Sep 21, 2016 at 12:02 PM, Robert Raszuk <[email-masked]> wrote:

> But it already there ... it is even WG document ..
>
> https://datatracker.ietf.org/doc/draft-ietf-idr-registered-
> wide-bgp-communities/
>
>
>
i'm unclear how this is helping this dicussion.

>
> On Wed, Sep 21, 2016 at 2:05 PM, Nick Hilliard <[email-masked]> wrote:
>
>> Robert Raszuk wrote:
>> > ​If something as you admit is critical to operators to run the network
>> > shouldn't it be maintained by IANA registry rather then sit on private
>> > web sites ?
>>
>> if you are seriously suggesting this, then we look forward to your
>> Internet Drafts.
>>
>
I think nick/jared/gert/jzp/mikael (all operators) have all said that
registering the usecases today isn't helpful, that some of these usecases
are not public (by design) and that they have evolved over time.

I'd like to see the generalized set of these captured in a
document/reference though, which is something grow can / should do ... and
then use that as the requirements set going forward (updated as Gert/etc
find new requirements of use to their networks). Getting focused on
byzantine corner cases isn't helpful, so generally useful requirements
should be a goal. This should make the IDR side of life simpler and it
should help vendors stop telling me, mikael, jared all: "Hey you're the
first to ever ask for this, wow!" (because actually we've had to configure
these things between us... so we know we're all asking for this 'feature' -
insert feature-du-jour-discussion)

-chris

---

From: Matthew Ringel <[email-masked]>
Date: Wed, 21 Sep 2016 12:51:30 -0400

Presuming that the existing BGP community space is all we have to work
with right now, and that we're operating networks right now, so we
need something that works right now, it might be better to look at
what we can do as a level of abstraction right now.

Thinking about the data to be communicated, we're looking at verb/noun
sequences.

e.g.
Prepend once  (verb: prepend, noun: 1)
Export to Chile (verb: export, noun: Chile)
Deny All (verb: deny, noun: all)
etc.

Collect enough nouns and verbs, and it follows that you can have a
language, where the specific communities might be in a common database
(e.g. PeeringDB*), and networks can say that they support a (yet to be
specified) standard 10-15 verbs with some set of nouns.   Most
networks will not have a need for (say) "Export to Chile", but being
able to construct it in a standard way is the important part.**

Having sorted through more than a few BGP community documents from
large networks, constructing a set of operators that covers most cases
probably involves 5-10 networks.

Cheers
=Matt

* No affiliation beyond satisfied user.

**It necessarily follows that standard nouns and verbs need standard
definitions.  Not everyone means the same thing when they say
"Export."  That would likely be the subject of a different draft.

On Wed, Sep 21, 2016 at 12:10 PM, Christopher Morrow
<[email-masked]> wrote:
>> https://datatracker.ietf.org/doc/draft-ietf-idr-registered-wide-bgp-communities/
>>
>>
>
>>> > If something as you admit is critical to operators to run the network
> _______________________________________________
> GROW mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/grow
>

---

From: Gert Doering <[email-masked]>
Date: Wed, 21 Sep 2016 19:24:13 +0200

Hi,

> able to construct it in a standard way is the important part.**

This is nice to have, and having a recommendation document that
shows operators "look, these are what people *typically* have been
doing with communities, and *that* is how to set the community
values to achieve things" would be a great help when building a new
policy framework.

Having this hard-coded in RFCs and code in routers is both far too 
complex to implement, and far too limited at the same time (what if
I only want "North Chile" but that isn't in the implementation?) - 
which is why I'm opting for the most simple approach: an opaque string
of bytes of a fixed length, displayed in 4:4:4 format, and all the
"what do I want to do with these?" flexibility and complexity goes
into the routing policy specified by the operator in their router
config.

We (AS5539) use about ~20 community values under 5539:<x> today, and
we do not see any need for much more complex policies (we're a fairly
leafish AS and only limited regional coverage) - so, I see no need to
ask my vendors for a wide list of automatic and all-encompassing features
in their automatic community / policy handling.  I want something they
can implement easily, and give me a if/match/set language to achieve
my policy, in a way that it works with 32bit ASes.

OTOH, my upstreams (2914) use a very complex and strongly regionalized 
framework ("blackhole outside the country that this route was 
received in"), and they seem to be happy with 4:4:4 as well and
not having "everything built-in and applied automatically", so the
-large draft seems to work for make small and large network operators
alike.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

---

From: Matthew Ringel <[email-masked]>
Date: Wed, 21 Sep 2016 13:54:26 -0400

> into the routing policy specified by the operator in their router

My thoughts were more along the standardization of verbs, for exactly
the reason you specify.  "Export" remains a verb (and very susceptible
to being standardized), and nouns like "Chile", "North Chile",
"Santiago", or the "Las Condes district of Santiago", are nouns that
can be specified, provider by provider, and don't need to be put in an
RFC, except as examples.

We (AS 20940) work with a large amount of networks.  Knowing that
"Export" means the same thing to everyone, and I just have to look up
the right noun, means a lot less operational hassle, and a lot less
shuffling through BGP community documents.  "Do they support
Blackholing?" is a yes/no "Do they support the verb, and what nouns?"
question, as opposed to having to shuffle through 20 pages to cobble
something together that might end up being Blackholing.

In short, looking at the problem as a set of verbs/nouns, and then
defining and standardizing a "minimum supported subset" of verbs, and
recommending ways to do a taxonomy of nouns (e.g. integers for
prepending, how to state a geo region) is entirely standard-worthy.

Cheers
=Matt

[Words are mine, not my employer's.]

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Wed, 21 Sep 2016 22:22:28 +0000

I thought about something like this with extended communities before I wrote my draft.
There is no order to communities. They can come in any order
and routers can change the order. Routers will remove duplicate communities.
So, you can only use any noun or verb once and, because there
is no order, you need another word type to bind the verbs and the nouns.
I quickly gave that up as way too hard.

Thanks,
Jakob.

> -----Original Message-----
> From: GROW [mailto:[email-masked]] On Behalf Of Matthew Ringel
> Sent: Wednesday, September 21, 2016 9:52 AM
> To: Christopher Morrow <[email-masked]>
> Cc: [email-masked]; [email-masked] [email-masked] <[email-masked]>
> Subject: Re: [GROW] [Idr] Request to adopt draft-heitz-idr-large-community - Working Group Adoption call (9/6 to
> 9/20)
>