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

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

On 09/06/2016 01:39 PM, Job Snijders wrote:
> 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
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr