Subject: [Idr] Request to adopt draft-heitz-idr-large-community

From: Job Snijders <[email-masked]>
Date: Tue, 6 Sep 2016 13:39:19 +0200

Dear IDR, fellow network operators,

I would like to request that the IDR Working Group adopts
draft-heitz-idr-large-community [1] as a working group document.

Background
----------
RFC1997 BGP communities are the most common method to signal
meta-information between autonomous systems. RFC1997 communities are a
32 bit entity. The convention is that the first 16 bits are the ASN in
which the last 16 bits have a meaning. RFC1997 is so popular because of
its elegant simplicity and ubiquitous support.

The operator community (no pun intended!) is suffering from a fatal
flaw. One in five ASNs in the Default-free zone are a 4-byte ASN (RFC
4893). One cannot fit a 32-bit value into a 16-bit field.

4-byte ASN Operators work around this issue by either resorting to
kludges such as using private 16-bit ASNs as in the "Global
Administrator" field, or by returning the ASN to their respective RIR
and requesting a 16-bit ASN. However, both the RIRs and the IANA have
depleted their supply of 16-bit ASNs.

Work to address the issue of BGP communities has been ongoing for years.
Notable examples are 'flexible communities' (12 years ago) and 'wide
communities' (6 years ago). The WG so far has been unable to produce an
internet standard which enjoys a status similar to RFC1997. Now that the
RIRs are running out, the issue has become a matter of extreme urgency.

The Large BGP Community specification gives every network operator
(regardless of whether they have a 2-byte ASN or a 4-byte ASN) 8 bytes
to signal meta-information in an opaque fashion. This will align with
current, well-established practices deployed by network operators.

The Large BGP Community has purposefully been specified to be narrow and
as simple as possible to meet the operator community immediate needs,
without dissuading from existing community extensions that are in the
standards process pipeline.

The Large Community, by design, is not extendable, because extensibility
comes at a cost. Knowing that the amount of noise generated by an idea
is inversely proportional to the complexity of the idea, I urge the WG
to consider the Large Community's simplicity not a disadvantage, but a
virtue.

We ask for your support in this narrow focus to re-imagine the RFC1997
communities in this way as it should have been done when RFC4893 was
published.

Kind regards,

Job Snijders
(co-author draft-heitz-idr-large-community)

[1]: https://tools.ietf.org/html/draft-heitz-idr-large-community

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 06 Sep 2016 13:07:33 +0100

> draft-heitz-idr-large-community [1] as a working group document.

Support.

Nick

---

From: Jared Mauch <[email-masked]>
Date: Tue, 6 Sep 2016 08:24:41 -0400

> On Sep 6, 2016, at 8:07 AM, Nick Hilliard <[email-masked]> wrote:
> 
> Job Snijders wrote:

Agree, Support!

- Jared

---

From: "Van De Velde, Gunter (Nokia - BE)" <[email-masked]>
Date: Tue, 6 Sep 2016 12:25:34 +0000

+1 
Support.

I like the simplicity this community support and feel this is the correct thig to do.

G/

On 06/09/16 14:07, "Idr on behalf of Nick Hilliard" <[email-masked] on behalf of [email-masked]> wrote:

    Support.
    
    Nick
    
    _______________________________________________
    Idr mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/idr

---

From: [email-masked]
Date: Tue, 06 Sep 2016 12:43:44 +0000

> draft-heitz-idr-large-community [1] as a working group document.

Support!

---

From: Eduardo Ascenço Reis <[email-masked]>
Date: Tue, 6 Sep 2016 09:50:26 -0300

> draft-heitz-idr-large-community [1] as a working group document.

I support the WG adoption.

Eduardo Ascenço Reis

---

From: Mark Schouten <[email-masked]>
Date: Tue, 06 Sep 2016 15:08:39 +0200

Hi,

> draft-heitz-idr-large-community [1] as a working group document.

As an operator struggling with the lack of communities for 4-byte ASNs
on a regular basis, I strongly support this request.

Mark Schouten
Tuxis Internet Engineering
nl.tuxis, AS197731

-- 
Kerio Operator in de Cloud? https://www.kerioindecloud.nl/
Mark Schouten  | Tuxis Internet Engineering
KvK: 61527076  | http://www.tuxis.nl/
T: 0318 200208 | [email-masked]

---

From: "i3D.net - Martijn Schmidt" <[email-masked]>
Date: Tue, 6 Sep 2016 15:31:41 +0200

Dear IDR,

As a network operator - i3D.net / AS49544 - we have frequently run into
the limitations of the existing BGP community system:

1) Assisting customers with 32-bit ASN's in configuring their BGP
routers and having to tag their internal prefixes with an "invalid"
operator community as per Job's description below. Furthermore, this
becomes an even larger problem when a 32-bit ASN gets downstream
customers and wants to provide them with the various signaling options
usually implemented through RFC1997 BGP communities.

2) Running into overlapping communities for prepend actions, meaning we
have to strip a lot of valuable information from an announcement before
we can import the prefix into our network and/or export it to another
network.

* For example, our customers would use 65500:3356 to signal AS49544
prevent us from exporting the prefix to our Level3 sessions, but
coincidentally NTT uses the same format. If we don't strip the community
before propagating to NTT they'd also stop exporting the prefix to their
Level3 sessions. As a result singlehomed Level3 customers might no
longer be able to see the affected prefix at all, which would of course
be an undesirable situation.

* If we could use something like 49544:3356:0 instead it would
immediately be clear that AS49544, when propagating to AS3356, has to
skip transmitting that prefix.

As such I fully support the adoption of this draft and hope for a swift
implementation in today's router software!

Best regards,
Martijn Schmidt
i3D.net / AS49544

---

From: Greg Hankins <[email-masked]>
Date: Tue, 6 Sep 2016 10:02:38 -0400

Support!

-- 
Greg Hankins <[email-masked]>

-----Original Message-----
Date: Tue, 6 Sep 2016 13:39:19 +0200
From: Job Snijders <[email-masked]>
To: [email-masked]
Subject: [Idr] Request to adopt draft-heitz-idr-large-community

Background
----------

Kind regards,

Job Snijders

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 6 Sep 2016 14:04:58 +0000

I support WG adoption.

On 9/6/16, 7:39 AM, "Idr on behalf of Job Snijders" <[email-masked]

---

From: "Bertrand Duvivier (bduvivie)" <[email-masked]>
Date: Tue, 6 Sep 2016 14:07:42 +0000

Same for me, I do support adoption
Best Regards Bertrand Duvivier
https://www.youtube.com/playlist?list=PLcSD8Cbk0fFHTO4bnb3NC8pJka3_ZvoRY

---

From: Barry O'Donovan <[email-masked]>
Date: Tue, 06 Sep 2016 14:31:24 +0100

+1

> Knowing that the amount of noise generated by an idea
> is inversely proportional to the complexity of the idea\

So true in all walks of life. Sadly.

  - Barry

-- 

Kind regards,
Barry O'Donovan

Open Solutions - Internet Infrastructure Specialists

---

From: heasley <[email-masked]>
Date: Tue, 6 Sep 2016 14:19:56 +0000

> draft-heitz-idr-large-community [1] as a working group document.

I support this for swift adoption and publication.

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 6 Sep 2016 14:42:18 +0000

Support. 

Linda Dunbar

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Job Snijders
Sent: Tuesday, September 06, 2016 6:39 AM
To: [email-masked]
Subject: [Idr] Request to adopt draft-heitz-idr-large-community

I would like to request that the IDR Working Group adopts draft-heitz-idr-large-community [1] as a working group document.

Background
----------
RFC1997 BGP communities are the most common method to signal meta-information between autonomous systems. RFC1997 communities are a
32 bit entity. The convention is that the first 16 bits are the ASN in which the last 16 bits have a meaning. RFC1997 is so popular because of its elegant simplicity and ubiquitous support.

The operator community (no pun intended!) is suffering from a fatal flaw. One in five ASNs in the Default-free zone are a 4-byte ASN (RFC 4893). One cannot fit a 32-bit value into a 16-bit field.

4-byte ASN Operators work around this issue by either resorting to kludges such as using private 16-bit ASNs as in the "Global Administrator" field, or by returning the ASN to their respective RIR and requesting a 16-bit ASN. However, both the RIRs and the IANA have depleted their supply of 16-bit ASNs.

Work to address the issue of BGP communities has been ongoing for years.
Notable examples are 'flexible communities' (12 years ago) and 'wide communities' (6 years ago). The WG so far has been unable to produce an internet standard which enjoys a status similar to RFC1997. Now that the RIRs are running out, the issue has become a matter of extreme urgency.

The Large BGP Community specification gives every network operator (regardless of whether they have a 2-byte ASN or a 4-byte ASN) 8 bytes to signal meta-information in an opaque fashion. This will align with current, well-established practices deployed by network operators.

The Large BGP Community has purposefully been specified to be narrow and as simple as possible to meet the operator community immediate needs, without dissuading from existing community extensions that are in the standards process pipeline.

The Large Community, by design, is not extendable, because extensibility comes at a cost. Knowing that the amount of noise generated by an idea is inversely proportional to the complexity of the idea, I urge the WG to consider the Large Community's simplicity not a disadvantage, but a virtue.

We ask for your support in this narrow focus to re-imagine the RFC1997 communities in this way as it should have been done when RFC4893 was published.

Kind regards,

Job Snijders

---

From: "Marco Davids (IETF IMAP)" <[email-masked]>
Date: Tue, 6 Sep 2016 16:45:12 +0200

> draft-heitz-idr-large-community [1] as a working group document.

Yes, good suggestion. I support this.

--
Marco

---

From: Gaurab Raj Upadhaya <[email-masked]>
Date: Tue, 6 Sep 2016 16:11:58 +0100

> draft-heitz-idr-large-community [1] as a working group document.

support this. long overdue.

-gaurab

---

From: Jeff Tantsura <[email-masked]>
Date: Tue, 6 Sep 2016 08:42:57 -0700

Support!

Regards,
Jeff

> On Sep 6, 2016, at 4:39 AM, Job Snijders <[email-masked]> wrote:
>

---

From: Theodore Baschak <[email-masked]>
Date: Tue, 6 Sep 2016 11:00:53 -0500

> On Sep 6, 2016, at 6:39 AM, Job Snijders <[email-masked]> wrote:
> 

As an operator of several 32-bit ASNs, I strongly support!
I ran into the exact issue being described, what ASN do you use instead of your own? 
What if the private ASN you pick collides with someone else's choices? etc 

Theodore Baschak - AS395089 - Hextet Systems
https://ciscodude.net/ - https://hextet.systems/
http://mbix.ca/

---

From: Pier Carlo Chiodi <[email-masked]>
Date: Tue, 06 Sep 2016 18:12:57 +0200

Support!

--
Pier Carlo Chiodi

---

From: Nabeel Cocker <[email-masked]>
Date: Tue, 6 Sep 2016 12:18:08 -0400

Support 

Regards,
Nabeel

> On Sep 6, 2016, at 7:39 AM, Job Snijders <[email-masked]> wrote:
>

---

From: "Dickinson, Ian" <[email-masked]>
Date: Tue, 6 Sep 2016 16:26:50 +0000

> draft-heitz-idr-large-community [1] as a working group document.

+1 support

I'd say better late than never, but actually - we need this now, not later.

Ian
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: Dunc <[email-masked]>
Date: Tue, 6 Sep 2016 19:06:21 +0100

> On 6 Sep 2016, at 12:39, Job Snijders <[email-masked]> wrote:
> 

+1   support

Cheers,

Dunc

---

From: David Farmer <[email-masked]>
Date: Tue, 6 Sep 2016 17:37:31 -0500

As an operator and someone involved in RIR policy, I support this and most
any solution that provides usable communities for 4-byte ASNs.

However, communities for 4-byte ASNs are not a new issue and there have
been several solutions proposed over the past couple years.  The blocking
issue seems to have been implementations, or the lack of them.

So, my question before we get too invested in another solution to this
problem, are BGP implementers, both open source and commercial, willing to
implement something along the lines of this proposal?  If they are, then
full-speed ahead PLEASE!  But, if not, them I not sure how effective yet
another communities for 4-byte ASNs proposal will be.

Thanks

-- 
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

---

From: Job Snijders <[email-masked]>
Date: Wed, 7 Sep 2016 00:46:48 +0200

Hi David,

On Tue, Sep 06, 2016 at 05:37:31PM -0500, David Farmer wrote:
> As an operator and someone involved in RIR policy, I support this and
> most any solution that provides usable communities for 4-byte ASNs.
> 
> However, communities for 4-byte ASNs are not a new issue and there
> have been several solutions proposed over the past couple years.  The
> blocking issue seems to have been implementations, or the lack of
> them.

You make a valid point. Without implementations this thread is worthless.

I have hope that this time around it'll be different: the specification
is so simple it is almost in-excusable to not implement it. Having no
extendability is also a feature: there will be no suprises, what is
written down is what it is.

I'm tracking implementations here: http://largebgpcommunities.net/implementations/ 
(and ofcourse in the RFC7942 section of the draft). I rely on what
people tell me, but you are probably best off to engage with your
vendors directly.

I encourage implementors to state whether this is on the roadmap and
what the ETAs will be for GM releases (if they are known yet).

Kind regards,

Job

---

From: "John G. Scudder" <[email-masked]>
Date: Tue, 6 Sep 2016 18:54:15 -0400

TL;DR: If you want to contribute to a working group consensus thread, please subscribe to the mailing list. Thanks.

Hi Everybody,

I've noticed a number of "+1" messages on the thread "Request to adopt draft-heitz-idr-large-community" from people who aren't subscribed to the IDR mailing list. (Such messages are held for moderator approval instead of being sent directly to the list.) I'm guessing that someone must have posted about this thread on another list, perhaps an operators' forum? In any case, let me remind you that in a call for working group adoption, it's the chairs' responsibility to judge, among other things, whether the working group is interested in taking the work on. Now, in the IETF we have quite a liberal definition of what it means to be part of a working group, but at a minimum working group members are generally expected to be subscribed to the mailing list. So, comments from people who are not subscribed to the list do not directly contribute to our ability to judge whether the working group, as such, is interested. For this reason, I'm not going to approve any more "+1" messages from people who aren't subscribed. Now, there are a number of things to keep in mind:

- Although such comments don't directly contribute to our ability to gauge working group consensus, they may still indirectly contribute to forming that consensus, since members of the working group should pay attention to what the users of the protocol need and want. Presumably these comments are coming from people who use the protocol and have legitimate needs and wants. We should take this into account.
- The IETF (famously, or maybe infamously) doesn't operate by voting, but by rough consensus. So it's legitimate, depending on the circumstances, for chairs to determine that consensus was not achieved even though there were lots of +1 "votes".
- Even from someone who is a list subscriber, a "+1" message is pretty low-content, so regardless of whether you are, or are not, a list subscriber it's helpful for you to state your reasoning and to be prepared to engage in further discussion.
- Anybody who wants to can become a list subscriber without further approval from me or anyone else, and I have no intention of changing that. All are welcome. You can use the web form at https://www.ietf.org/mailman/listinfo/idr or the usual mailman interface. Messages from list members are not moderated. 
- In general, we still will welcome (including providing moderator approval) contributions from people who don't choose to become list subscribers. The emphasis is on "contributions", that is to say, messages with non-trivial content. 
- People who for some reason wish to weigh in on this conversation without subscribing to the list, should consider introducing themselves, describing what their interest is in the subject, and then stating their position. For example, "hi, I am J. R. Operator, I work in the operations group at Bill's Bait, Sushi, and Wholesale Internet. Here at BBS&WI we have been suffering grievously from lack of #feature for several years and I believe that #draft is the most expedient way to correct this problem. Thanks."
- Finally, my comments above notwithstanding I'd like to say the vast majority of contributions to the thread have been high-content and productive, thank you very much to those who have contributed so far. Carry on!

Presumably the people who most need to see this message won't, because by definition they aren't subscribed to the list. Please forward as necessary. I will also provide a pointer to this info with any bounce messages (but people often filter bounce messages so that's not a very reliable channel unfortunately).

Thanks!

--John

---

From: David Farmer <[email-masked]>
Date: Tue, 6 Sep 2016 18:45:14 -0500

Thanks for the response, more below.

> written down is what it is.

I like the simplicity, I hope it gets implemented.  A solution to this
problem is desperately needed, but I think you know that. :)

> what the ETAs will be for GM releases (if they are known yet).

Thank you for the pointer to the web site and the implementation tracking
information in particular; while not yet sufficient to guarantee success,
the current list seems encouraging.  Maybe you should add a pointer to the
website and the implementation tracking information as an appendix to be
deleted once published.

I have a few other thoughts on the content of the draft, but I'll take them
outside of this thread.

Thanks.

---

From: Randy Bush <[email-masked]>
Date: Wed, 07 Sep 2016 08:50:57 +0900

uh, yes

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Wed, 7 Sep 2016 00:56:37 +0000

Thanks for your support David.
My code so far supports the draft in its entirety. Not just the attribute encoding, but a full set of route-policy statements, show commands and aggregation code to make it a useable BGP feature. It is not production ready, but the support here will certainly help push it through the process.

Thanks,
Jakob.

On Sep 6, 2016, at 7:45 PM, David Farmer <[email-masked]<mailto:[email-masked]>> wrote:

On Tue, Sep 6, 2016 at 5:46 PM, Job Snijders <[email-masked]<mailto:[email-masked]>> wrote:
Hi David,

I like the simplicity, I hope it gets implemented.  A solution to this problem is desperately needed, but I think you know that. :)

Kind regards,

Job

Thank you for the pointer to the web site and the implementation tracking information in particular; while not yet sufficient to guarantee success, the current list seems encouraging.  Maybe you should add a pointer to the website and the implementation tracking information as an appendix to be deleted once published.

I have a few other thoughts on the content of the draft, but I'll take them outside of this thread.

Thanks.

--
===============================================
David Farmer               Email:[email-masked]<mailto:[email-masked]>
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================
_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/idr

---

From: Kay Rechthien <[email-masked]>
Date: Wed, 7 Sep 2016 15:41:11 +0200

Hi IDR,

> On 06 Sep 2016, at 13:39, Job Snijders <[email-masked]> wrote:
> 
> ...

we, ECIX, support this proposal.
We run IXPs with BGP community based controllable route-servers, where the peer has the ability to block announcements to certain other peers based on the ASN. As we use 65000:XXX, where XXX is the ASN which should not receive the route, this proposal would give us the option to also extend the control-mechanisms towards 32-bit ASNs and not just 16-bit ASNs anymore.

Best Regards
Kay

---

From: Rob Shakir <[email-masked]>
Date: Wed, 7 Sep 2016 08:33:44 -0700

When we discussed this in the WG, and I discussed it offline with Job, I
was in favour of a more generic TLV-based community encoding. The reasoning
being that it seems (to me) that we are creating a new attribute which
suffers from the exact issue that has prompted its creation (that is to
say, a fixed length, which we'll subsequently then want to change the
format of).

However, there is also a pressing operational need, as per the folks
replying to this thread, so the question really becomes, should we allow
perfect to be the enemy of "shipped"? It seems a shame to me that we should
proceed with a solution that is not particularly future-proof, but then the
cost of creating new attributes is also not particularly high. It's also
noteworthy that, as Job noted, there seem to be zero implementations of the
alternate solutions to this problem that have been around in the WG for a
long time. If those alternate solutions would like to progress, then
AFAICS, there is no reason that they could not do so in parallel to this
work - with their longer implementation cycle, and additional complexity.

I'd also remind folks of something I mentioned in Berlin - standardised by
IDR does not equate to there being widely available, stable code that
actually supports a feature.

So, given these reasons - I'd support this progressing (quickly) through WG
adoption, and if sufficient implementations exist, almost immediately to
last call.

r.

On Wed, Sep 7, 2016 at 6:41 AM, Kay Rechthien <[email-masked]> wrote:

> We run IXPs with BGP community based controllable route-servers, where the
> peer has the ability to block announcements to certain other peers based on
> the ASN. As we use 65000:XXX, where XXX is the ASN which should not receive
> the route, this proposal would give us the option to also extend the
> control-mechanisms towards 32-bit ASNs and not just 16-bit ASNs anymore.
>
> Best Regards
> Kay

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 7 Sep 2016 17:47:27 +0200

I agree with all statements made by Rob S.

Kay's email however triggered the clarification question to the current -03
version.

What is the meaning of explicit AS number listed in the first 4 octets of
the community. I was under impression that originally it was the AS number
in which given community needs to be executed however it seems that this
sentence is no longer in the current version of the draft.

So it may be unclear if this is AS number inserting this community, if this
is target AS to execute it or perhaps like in the case of Route Server is
it AS acting as proxy for other ASes it peers with ?

The answer could be none of the above - it's all local significant - but
then shouldn't it rather use a 4:4:4 description.

Thx,
Robert.

On Wed, Sep 7, 2016 at 5:33 PM, Rob Shakir <[email-masked]> wrote:

> So, given these reasons - I'd support this progressing (quickly) through
> WG adoption, and if sufficient implementations exist, almost immediately to
> last call.
>
> r.
>
>> We run IXPs with BGP community based controllable route-servers, where
>> the peer has the ability to block announcements to certain other peers
>> based on the ASN. As we use 65000:XXX, where XXX is the ASN which should
>> not receive the route, this proposal would give us the option to also
>> extend the control-mechanisms towards 32-bit ASNs and not just 16-bit ASNs
>> anymore.
>>
>> Best Regards
>> Kay

---

From: heasley <[email-masked]>
Date: Wed, 7 Sep 2016 16:04:55 +0000

> sentence is no longer in the current version of the draft.

Is this not something to discuss AFTER adoption as a working group item?

---

From: David Farmer <[email-masked]>
Date: Wed, 7 Sep 2016 11:04:59 -0500

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

>
> Kay's email however triggered the clarification question to the current
> -03 version.
>

 The current version is -04, I made that mistake yesterday.

---

From: Job Snijders <[email-masked]>
Date: Wed, 7 Sep 2016 18:11:13 +0200

Hi Robert,

On Wed, Sep 07, 2016 at 05:47:27PM +0200, Robert Raszuk wrote:
> Kay's email however triggered the clarification question to the
> current -03 version.
> 
> What is the meaning of explicit AS number listed in the first 4 octets
> of the community. I was under impression that originally it was the AS
> number in which given community needs to be executed however it seems
> that this sentence is no longer in the current version of the draft.

The first 4 bytes contain the ASN in which the last 8 bytes have a
meaning. Its not about what is executed where. Consider the last 8
bytes, the 'local opaque data', a namespace of sorts, the first 4 bytes
indicate who owns that namespace. The owner of the namespace can
publicly or privately document what the meaning communities are within
his/her namespace.

I welcome suggestions to improve the text on this aspect. RFC 1997 had
language like "Global Administrator" and "Local Administrator" - but I
think that is a somewhat archaic to explain this concept. In -04 we're
talking about "Autonomous System Number" and "Local Data".

> So it may be unclear if this is AS number inserting this community, if
> this is target AS to execute it or perhaps like in the case of Route
> Server is it AS acting as proxy for other ASes it peers with ?
> 

What Kay described is that they today with RFC 1997 communities they are
using a horrible kludge because there is not enough space. 

With Large communities, ECIX (AS 9033) could say "Dear customers, if you
attach 9033:XXX:YYY to your prefix, our routeserver will do A", where
XXX and YYY are values decided by ECIX. This way, there will never be
collisions. What XXX and YYY are is up to ECIX, XXX could be the ASN of
a peer on the route server, YYY could be an identifier which triggers an
action, such as no-export.

Given the above context and what Kay sent to the list:

> > As we use 65000:XXX, where XXX is the ASN which should
>> extend the control-mechanisms towards 32-bit ASNs and not just 16-bit
>> ASNs anymore.

With Large Communities, the above example could be turned into:
9033:65000:XXX, where XXX is the ASN which should not receive the route.
Suddenly they aren't overloading a Global Administrator field with a private ASN! :-)

ECIX (and other Route Server operators) gain two advantages: There won't
be a risk of collision because its in their own namespace, (in ECIX's
case '9033'), and XXX can be a 4-byte value, meaning they can target
4-byte ASNs, which is something they cannot do today but clearly want to
do for consistency.

It is important to recognise that it is up to ECIX to decide how they
use the 8 bytes of data available to them. They can put ASNs in there
directly, or use a mapping table, or throw a dice and just publish which
value means what on their Route Server. It is entirely opaque.

Kind regards,

Job

ps. Large Communities' expiry date will be the moment the IETF starts
working on 8-byte ASNs. If that ever happens, we'll hopefully remember
this thread.

---

From: Adam Davenport <[email-masked]>
Date: Wed, 7 Sep 2016 12:45:55 -0400

I for one support this initiative, as this problem has existed for far 
too long without resolution, and actually does have material real world 
impact for networks utilizing 4-byte ASN's.  I also like the simplistic 
approach which not only provides a solution for the root issue, but 
should make it significantly easier for the applicable vendors to 
support such a change on their respective platforms.

Adam Davenport / [email-masked]
Director, Interconnection Strategy
GTT Communications / www.gtt.net

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 7 Sep 2016 19:56:40 +0200

Hi Job,

Excellent.

And my only point was to add that single sentence to the spec when next rev
comes out.

Suggestion for the sentence to add into bottom of the section 3:

"The Autonomous System number used within the community field is an Autonomous
System which understands the encoded meaning of the 8 octets which follow
and which is to act on it."

... or something along those lines.

Cheers,
R.

---

From: Warren Kumari <[email-masked]>
Date: Wed, 7 Sep 2016 15:31:10 -0400

[ TL;DR - I support adoption ]

On Wed, Sep 7, 2016 at 11:33 AM, Rob Shakir <[email-masked]> wrote:
> When we discussed this in the WG, and I discussed it offline with Job, I was
> in favour of a more generic TLV-based community encoding. The reasoning
> suffers from the exact issue that has prompted its creation (that is to say,
> a fixed length, which we'll subsequently then want to change the format of).

I was also part of these offline discussions - I'd really really
prefer this to be a (simple) TLV (or even just prefixed with a version
number ) so that when we realize that we want 9 local bytes[0]  we can
simply bump a version / TLV and not have this whole discussion again.

But, A: we can have that discussion once adopted and / or B: this is
good enough.
So, support adoption, want to see it move along...

> long time. If those alternate solutions would like to progress, then AFAICS,
> there is no reason that they could not do so in parallel to this work - with
> their longer implementation cycle, and additional complexity.
>
> I'd also remind folks of something I mentioned in Berlin - standardized by

What?! Mind blown -- you've shaken my entire world view...

> adoption, and if sufficient implementations exist, almost immediately to

Yup, what he said.

W

[0]: I want 4 bytes to stuff the peer AS in, 4 bytes to carry the RID
of the receiving router, and, um, a flavor... or preferred animal....
or region... no-idea, but I'm sure we'll come up with an important
thingie to carry in a few months...

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

---

From: Gert Doering <[email-masked]>
Date: Wed, 7 Sep 2016 21:48:53 +0200

Hi,

> draft-heitz-idr-large-community [1] as a working group document.

I think that makes sense.  The lack of a working and implemented 
BGP community system that enables IXP operators and backbone operators
to make proper use of 4-byte ASNs is a problem that has come up a
few times in other fora (like, RIPE routing and address policy WGs).

This approach with a fixed 4:4:4 format seems good, because it's simple
and much easier to get the implementation right than with "extensible
formats".

So: support to adopt this draft as a WG item.

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: Thomas King <[email-masked]>
Date: Wed, 7 Sep 2016 20:57:53 +0000

Full support!
Thomas

---

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

Here is how I would treat the first 4 octet so of the large community.
The community is normally used by an ISP to allow a directly connected customer to express its wishes about how to process the route. In that case, the first four octets and all octets are totally in control of the ISP. The ISP has total control of the definition of the octets. If an ISP is willing to carry communities that are destined to another AS, then it makes sense for everyone to agree on the encoding of the target ASN in the community.
I would phrase it like this:

The meaning of all octets in the large community is to be defined by mutual agreement between the originating and terminating ASes. However, if a large community is intended to transit an AS, then the ASN of the terminating AS SHOULD be encoded in the first 4 octets of the large community.

For example, there is no reason that an invalid ASN (say 0 or 23456) should be disallowed as long as the intended recipients of the community understand the meaning.

Thanks,
Jakob.

On Sep 7, 2016, at 1:57 PM, Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:

Hi Job,

Excellent.

And my only point was to add that single sentence to the spec when next rev comes out.

"The Autonomous System number used within the community field is an Autonomous System which understands the encoded meaning of the 8 octets which follow and which is to act on it."

Cheers,
R.

On Wed, Sep 7, 2016 at 6:11 PM, Job Snijders <[email-masked]<mailto:[email-masked]>> wrote:
Hi Robert,

Kind regards,

Job

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 8 Sep 2016 01:29:27 +0200

Hi Jakob,

To me what you proposed here below is sufficient and covers second sentence:

"
​
The meaning of all octets in the large community is to be defined by mutual
agreement between the originating and terminating ASes."

- - -

However while we do not talk about this often in IDR and just leave freedom
of implementation let me risk a question what filtering capabilities should
be or are expected to be implemented for large communities at the ASBRs ?

Q1: In your current implementation can I selectively accept communities
only with my AS listed in the first 4 octets and drop everything else ?

Q2: If as you say large community is intended to "transit an AS" how do I
know the destination/terminating AS will get what real sender sent or
intended to sent in the remaining 4:4 ?

Q3: Assume the terminating AS as agreed with with originating AS did the
job. Should spec enforce (MUST) to strip such community before propagating
the route any other EBGP speaker ? Why do we want to trash the Internet
with something which by AS-PATH rules should never be needed again (leave
alone allowas-in tricks or as-overwrite) ?

Thx,
R.

On Thu, Sep 8, 2016 at 12:39 AM, Jakob Heitz (jheitz) <[email-masked]>
wrote:

> The community is normally used by an ISP to allow a directly connected
> customer to express its wishes about how to process the route. In that
> case, the first four octets and all octets are totally in control of the
> ISP. The ISP has total control of the definition of the octets. If an ISP
> is willing to carry communities that are destined to another AS, then it
> makes sense for everyone to agree on the encoding of the target ASN in the
> community.
> ​​
> The meaning of all octets in the large community is to be defined by
> mutual agreement between the originating and terminating ASes. However, if
> a large community is intended to transit an AS, then the ASN of the
> terminating AS SHOULD be encoded in the first 4 octets of the large
> community.
>
> For example, there is no reason that an invalid ASN (say 0 or 23456)
> should be disallowed as long as the intended recipients of the community
> understand the meaning.
>
> Thanks,
> Jakob.
>
>
> On Sep 7, 2016, at 1:57 PM, Robert Raszuk <[email-masked]> wrote:
>
> Hi Job,
>
> Excellent.
>

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Thu, 8 Sep 2016 01:08:34 +0000

Q1. My implementation as it stands uses ios-regex to filter, so you can filter whatever you want. I have an optimization in mind that will make it easier to match on each field individually, but it's not done yet.
Your example: delete largecommunity not in (ios-regex '^2914:')

Q2. If your ISP offers the service to transit communities, then that ISP will be able to transmit the large communities unchanged with my implementation.

Q3. The spec must not enforce any stripping. It is up to a receiver to strip whatever it does not want to receive. In my implementation, large communities are dropped by default by EBGP senders. You must configure send-community-ebgp if you want it to send large communities. You can use the delete statement of Q1 in a neighbor outbound route-policy if you want to selectively remove large communities.

BTW, this all works the same way as it does with regular communities.

Thanks,
Jakob.

On Sep 7, 2016, at 7:29 PM, Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:

Hi Jakob,

"
​
The meaning of all octets in the large community is to be defined by mutual agreement between the originating and terminating ASes."

- - -

However while we do not talk about this often in IDR and just leave freedom of implementation let me risk a question what filtering capabilities should be or are expected to be implemented for large communities at the ASBRs ?

Q1: In your current implementation can I selectively accept communities only with my AS listed in the first 4 octets and drop everything else ?

Q2: If as you say large community is intended to "transit an AS" how do I know the destination/terminating AS will get what real sender sent or intended to sent in the remaining 4:4 ?

Q3: Assume the terminating AS as agreed with with originating AS did the job. Should spec enforce (MUST) to strip such community before propagating the route any other EBGP speaker ? Why do we want to trash the Internet with something which by AS-PATH rules should never be needed again (leave alone allowas-in tricks or as-overwrite) ?

Thx,
R.

On Thu, Sep 8, 2016 at 12:39 AM, Jakob Heitz (jheitz) <[email-masked]<mailto:[email-masked]>> wrote:
Here is how I would treat the first 4 octet so of the large community.
The community is normally used by an ISP to allow a directly connected customer to express its wishes about how to process the route. In that case, the first four octets and all octets are totally in control of the ISP. The ISP has total control of the definition of the octets. If an ISP is willing to carry communities that are destined to another AS, then it makes sense for everyone to agree on the encoding of the target ASN in the community.
I would phrase it like this:

​​

Thanks,
Jakob.

Hi Job,

Excellent.

Cheers,
R.

Kind regards,

Job

---

From: <[email-masked]>
Date: Thu, 8 Sep 2016 07:57:42 +0000

Hi Jakob,

Please see inline, [Bruno]

From: Idr [mailto:[email-masked]] On Behalf Of Jakob Heitz (jheitz)
Sent: Thursday, September 08, 2016 12:40 AM
To: Robert Raszuk
Cc: idr wg
Subject: Re: [Idr] Request to adopt draft-heitz-idr-large-community

The meaning of all octets in the large community is to be defined by mutual agreement between the originating and terminating ASes. However, if a large community is intended to transit an AS, then the ASN of the terminating AS SHOULD be encoded in the first 4 octets of the large community.
[Bruno] The problem is that in living networks, people start using a solution (e.g. large community) with a given use case in mind. Then once deployed, it's very hard to change (well, I guess it depends on how big and complex is the network).
So people start with 2 ASes (originating and terminating), then use one VPN AS to transit, then come inter-AS VPN. And those transit AS will see name space collision, which will be a headache. (e.g. who must be forced to renumber?)
Note that a transit AS may also be introduced between 2 peers, without VPN.

So I would strongly prefer that the first 4 octets be dedicated to the AS number defining the usage of the community, just like RFC 1997 (BGP community) (and RT for extended community and RD in VPNs)

[Bruno]
IMHO, I would interpret your proposition as a fear that in some future, the large-community, is found not to be large enough. If this is the case, it's not too late to make it bigger. e.g. 4*32 bits.
On a side note, I'm also a bit nervous that 3 days after the start of the WGLC, so extremely early for a solution that I would expect to be running for 20 years, we are already discussing that the numbering space may be too small. (full disclosure, I'm co-authoring draft-ietf-idr-wide-bgp-communities)

Thanks,
Regards,
--Bruno

Thanks,
Jakob.

Excellent.

Cheers,
R.

Kind regards,

Job

_________________________________________________________________________________________________________________________

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.

---

From: <[email-masked]>
Date: Thu, 8 Sep 2016 10:31:41 +0000

[re-sending in ascii]

Hi Jakob,

> From: Jakob Heitz (jheitz) > Sent: Thursday, September 08, 2016 12:40 AM
> 
> The community is normally used by an ISP to allow a directly connected customer to
> express its wishes about how to process the route. In that case, the first four octets and all
> octets are totally in control of the ISP. The ISP has total control of the definition of the
> octets. If an ISP is willing to carry communities that are destined to another AS, then it
> makes sense for everyone to agree on the encoding of the target ASN in the community.
> The meaning of all octets in the large community is to be defined by mutual agreement
> between the originating and terminating ASes. However, if a large community is intended
> to transit an AS, then the ASN of the terminating AS SHOULD be encoded in the first 4
> octets of the large community.

[Bruno]

Thanks,
Regards,
--Bruno

> For example, there is no reason that an invalid ASN (say 0 or 23456) should be disallowed
> as long as the intended recipients of the community understand the meaning.
> 
> Thanks,
> Jakob.
> 
> 
> System which understands the encoded meaning of the 8 octets which follow and which is
> to act on it."
>

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Thu, 8 Sep 2016 10:50:34 +0000

I fully expect people to use the first 4 octets to encode the target ASN for all the reasons mentioned. However, I will not enforce it in the code or in the spec. It is enough to RECOMMEND it in the spec, stating the reason.

Thanks,
Jakob.

> On Sep 8, 2016, at 6:31 AM, "[email-masked]" <[email-masked]> wrote:
> 
> [re-sending in ascii]
> 
> Hi Jakob,
>

---

From: <[email-masked]>
Date: Thu, 8 Sep 2016 12:24:59 +0000

Hi Jakob,

> From: Jakob Heitz
> Sent: Thursday, September 08, 2016 12:51 PM
> 
> I fully expect people to use the first 4 octets to encode the target ASN for all the reasons
> mentioned. However, I will not enforce it in the code or in the spec. It is enough to
> RECOMMEND it in the spec, stating the reason.

Although I'd prefer RFC 4360 (extended community) formulation ("This sub-field contains an Autonomous System number assigned by IANA."), if the goal is to keep RFC 1997 communities usages as-is, I would be fine re-using RFC 1997 text:

"The rest of the community attribute values shall be encoded using an
   autonomous system number in the first two octets.  The semantics of
   the final two octets may be defined by the autonomous system."

but updated with a 2119 keyword. i.e. :s/shall/SHALL

I'm not asking for any enforcement in the code. (and I don't see how the code could enforce it).
I'm asking for the document to make it clear, that AS X owns the community space starting with X. Such that if there is a conflicting usage, it's clear which AS/actor needs to renumber.

Note that I can live with current wording in the draft. It's your proposed change that I am commenting on.

As another comment, I think section 3 ("Textual Representation") could normatively reference RFC5396 ("Textual Representation of Autonomous System (AS) Numbers").

Thanks,
--Bruno
 
> > [Bruno] The problem is that in living networks, people start using a solution (e.g. large
> community) with a given use case in mind. Then once deployed, it's very hard to change
> (well, I guess it depends on how big and complex is the network).
> > So people start with 2 ASes (originating and terminating), then use one VPN AS to
> transit, then come inter-AS VPN. And those transit AS will see name space collision, which
> will be a headache. (e.g. who must be forced to renumber?)
> > So I would strongly prefer that the first 4 octets be dedicated to the AS number defining
> the usage of the community, just like RFC 1997 (BGP community) (and RT for extended
> community and RD in VPNs)
> >
> > [Bruno]
> > IMHO, I would interpret your proposition as a fear that in some future, the large-
> community, is found not to be large enough. If this is the case, it's not too late to make it
> bigger. e.g. 4*32 bits.
> > On a side note, I'm also a bit nervous that 3 days after the start of the WGLC, so
> extremely early for a solution that I would expect to be running for 20 years, we are
> already discussing that the numbering space may be too small. (full disclosure, I'm co-
> authoring draft-ietf-idr-wide-bgp-communities)
> >
> > Thanks,
> > Regards,
> > --Bruno
> >
> >
> __________________________________________________________________________

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Thu, 8 Sep 2016 12:29:26 +0000

Makes sense. Merci Bruno.

Jakob.

> On Sep 8, 2016, at 8:25 AM, "[email-masked]" <[email-masked]> wrote:
> 
> Hi Jakob,
> 
>> From: Jakob Heitz

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 8 Sep 2016 15:09:41 +0200 (CEST)

>> draft-heitz-idr-large-community [1] as a working group document.

I also support adoption. This is long overdue.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Wesley Steehouwer <[email-masked]>
Date: Thu, 8 Sep 2016 11:29:00 +0000

Dear IDR,

From my personal experience as a network consultant for multiple Autonomous Systems, I can conclude that adoption of draft-heitz-idr-large-community should be done years a go already.  So I support this draft.

Met vriendelijke groeten,

Wesley Steehouwer
Consulting Network Engineer

******** IMPORTANT NOTICE ********
The content of this e-mail is intended for the addressee(s) only and may contain information that is confidential and/or otherwise protected from disclosure. If you are not the intended recipient, please note that any copying, distribution or any other use or dissemination of the information contained in this e-mail (and its attachments) is strictly prohibited. If you have received this e-mail in error, kindly notify the sender immediately by replying to this e-mail and delete the e-mail and any copies thereof.

Tele2 AB (publ) and its subsidiaries (“Tele2 Group”) accepts no responsibility for the consequences of any viruses, corruption or other interference transmitted by e-mail.

---

From: brad dreisbach <[email-masked]>
Date: Mon, 12 Sep 2016 10:16:57 -0400

>draft-heitz-idr-large-community [1] as a working group document.

support adoption

---

From: [email-masked]
Date: Mon, 19 Sep 2016 17:01:00 +0200

Hi,

I represent AS32787.  We use communities to steer inbound traffic 
between ports / locations.  Longer communities would allow us to use 
communities on a per peer (or per category of peer) per peering 
session basis whilst retaining a human friendly format.

32-bit commmunities can’t do that at scale without turning the 
community into an opaque number that needs tooling to interpret / 
operate.  If we retain 32787 as 16 of those bits we have 16 bits with 
which to express a set of actions on peering sessions which only 
scales to a few thousand sessions.

Considering this, I'd like to voice my approval for adoption of this 
draft.

Regards,

	-- Niels.

>draft-heitz-idr-large-community [1] as a working group document.
[...]

--

---

From: "John G. Scudder" <[email-masked]>
Date: Mon, 19 Sep 2016 14:06:03 -0400

Forwarding on behalf of Jens Ott.

--John

> Begin forwarded message:
> 
> From: Jens Ott - Opteamax GmbH <[email-masked]>
> Date: September 19, 2016 at 1:48:32 PM EDT
> To: <[email-masked]>
> 
> Hi,
> 
> I subscribed to the idr list (and got confirmation). Then I tried sending this mail below but I get bounce I'd not be subscribed. I was told to ask you as chair of idr, if you could please forward it to the list on my behalf.
> 
> Thank you and kind regards
> Jens  
> 
> 
> I represent AS48200, a small German IP-Transit Provider. 
> 
> Several IXP route-servers are offering Do-Not-Announce communities in the format IXPASN:PEERASN. This works fine for route-server-peers with 16bit ASN, but it's no longer possible to set DNA for peers with 32bit ASN. Only choice for not being seen from our customers over the IXP is currently to not peer with the route-servers. 
> 
> Additionally we needed to implement a complex mapping for giving our customers the opportunity to prepend their prefixes to specific peers, which always requires long explanation to new customers. 
> 
> Therefore I highly support Job's request to adopt the draft.
> 
> Best regards 
> Jens Ott 
> 
> Am 6. September 2016 14:39:19 OESZ, schrieb Job Snijders <[email-masked]>:
>> !DSPAM:1229,57dfd6a4170271841914067!
> 
> -- 
> Jens Ott
> Geschäftsführer
> 
> Opteamax GmbH
> 
> Simrockstr. 4b
> 53619 Rheinbreitbach
> 
> Tel.: +49 2224 969500
> Fax: +49 2224 97691059
> Email: [email-masked]
> 
> HRB: 23144, Amtsgericht Montabaur
> Geschäftsführer: Jens Ott
> Umsatzsteuer-ID.: DE264133989
> -- 
> Jens Ott
> Geschäftsführer
> 
> Opteamax GmbH
> 
> Simrockstr. 4b
> 53619 Rheinbreitbach
> 
> Tel.: +49 2224 969500
> Fax: +49 2224 97691059
> Email: [email-masked]
> 
> HRB: 23144, Amtsgericht Montabaur
> Geschäftsführer: Jens Ott
> Umsatzsteuer-ID.: DE264133989
> -- 
> Jens Ott
> Geschäftsführer
> 
> Opteamax GmbH
> 
> Simrockstr. 4b
> 53619 Rheinbreitbach
> 
> Tel.: +49 2224 969500
> Fax: +49 2224 97691059
> Email: [email-masked]
> 
> HRB: 23144, Amtsgericht Montabaur
> Geschäftsführer: Jens Ott
> Umsatzsteuer-ID.: DE264133989

---

From: Tom Daly <[email-masked]>
Date: Mon, 19 Sep 2016 17:09:28 -0400

IDR Team,

I am Tom Daly from Fastly, Inc. - AS54113 - a global content delivery
networks. I'm writing to express our support of BGP Large Communities. As a
large user of IP anycast routing, we commonly use BGP communities to
control route propagation via transit providers, peers, and IXP route
servers. This draft increases our functionality to express policy.

First, as others have written, our ability to express policy towards four
byte ASNs is limited.

Second, while opaque, the construct of <ASN1>:<ASN2>:<PARAMETER> is very
logical to us an operator. Using this construct makes the application of
BGP communities - on who and via whom - very simple for a human being to
understand. Incredibly useful during situational debugging. Simplicity is
elegant in a world of more and more complex APIs.

Also worth mentioning that Fastly's implementation/adoption would be
accelerated due to our use of BIRD as a routing daemon. We understand a
patch is already underway which would allow us to rapidly test and adopt.

We are also happy to see the support of the vendor community behind this
effort: http://largebgpcommunities.net/implementations/

Thanks,
Tom