Subject: [Idr] Why do we define so many communities for BGP

From: "[email-masked]" <[email-masked]>
Date: Tue, 8 Nov 2016 19:51:52 +0800

Hello all,

I am confused by large community defined in draft-ietf-idr-large-community, wide community defined in draft-ietf-idr-wide-bgp-communities, extended community defined in RFC4360, community defined in RFC1997. Why do we need so many kinds of BGP communities? Can the large community be encoded in type 3 wide community? Thank you for your explaination.

Best Regards,

[email-masked]

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 08 Nov 2016 12:57:48 +0100

[email-masked] wrote:
> I am confused by large community defined
> in draft-ietf-idr-large-community, wide community defined
> in draft-ietf-idr-wide-bgp-communities, extended community defined in
> RFC4360, community defined in RFC1997. Why do we need so many kinds of
> BGP communities? Can the large community be encoded in type 3 wide
> community? Thank you for your explaination.

this issue has already been addressed extensively on the IDR mailing
list.  Please see the list archives:

http://www.ietf.org/mail-archive/web/idr/

The relevant discussion starts on Sep 3 and ended around Sep 27.  There
were over 400 emails in several threads.

Nick

---

From: Job Snijders <[email-masked]>
Date: Tue, 8 Nov 2016 13:14:00 +0100

Dear,

On Tue, Nov 08, 2016 at 07:51:52PM +0800, [email-masked] wrote:
> I am confused by large community defined in
> draft-ietf-idr-large-community, wide community defined in
> draft-ietf-idr-wide-bgp-communities, extended community defined in
> BGP communities?

It is healthy for the IETF that ideas can compete with each other.

Without competing drafts, the IETF would suffer from a anti-pattern
where someone (metaphorically) takes a cookie, licks it and puts it back
on the cookie tray, essentially preventing anyone else from having it,
but not eating it by himself or herself.

This anti-pattern can be often seen within volunteer communities when
discussing a certain issue or an improvement. Someone says "I've already
done draft on this topic,". This would prevent others from working on
the feature as there is already someone who started working on it. If
it's not followed up on by this person, it's essentially a dead project.
Nobody else touches it, but nothing real gets done.

Regarding RFC4360 - it has been documented that RFC4360 communities are
unsuitable, this is described as following in the draft:

    """Since the adoption of four-octet ASNs [RFC6793], the BGP
    Communities attribute can no longer accommodate the above encoding,
    as a two- octet word cannot fit a four-octet ASN.  The BGP Extended
    Communities attribute [RFC4360] is also unsuitable.  The six-octet
    length of the Extended Community value precludes the common
    operational practise of encoding four-octet ASNs in both the Global
    Administrator and the Local Administrator sub-fields."""

> Can the large community be encoded in type 3 wide community?

No. There was disagreement on the transivity behaviourisms between
various parties involved. And in the end, there is no reason the two
technologies can't co-exist.

I want to conclude with an emphasis on the fact that the Large BGP
Communities effort has running code, lots of it. Please take a look
here: http://largebgpcommunities.net/implementations/

You can see that not only the BGP implementations have taken on to
support Large BGP Communities, but that the entire ecosystem is being
upgraded to work with large communities: tcpdump, wireshark, pmacct,
pgbpp, zebra-dump-parser, mrtparse, and the list is growing weekly.

Perhaps the following saying is applicable?

兩鳥在林不如一鳥在手

Kind regards,

Job

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 8 Nov 2016 10:17:01 -0500

[Removing individual draft aliases.]

> I am confused by large community defined in draft-ietf-idr-large-community, wide community defined in draft-ietf-idr-wide-bgp-communities, extended community defined in RFC4360, community defined i…

With specific regard to version wide communities draft -03, as part of
discussion with the large communities authors on various encoding options,
-03 was issued to provide suitable talking points about how various
behaviors could be accomplished under a common header.  As Job noted, the
fundamental differences in the proposals resulted in large communities not
utilizing the common header.

Wide communities was not really intended to be a generic 1997 replacement
and is intended to cover different goals.  We will be restoring the -02
common header format so Huawei's prototype is again conformant and other
prototypes will utilize that format.

The Type 2 wide community which covered the 4:4 will similarly be removed
since its functionality is covered by large comms.

----

With regard to the more general question, routing marking mechanisms
continue to vary in format mostly to cover differing use cases.  Extended
communities, for example, were originally deployed primarily for BGP VPN use
cases.  They've proven flexible enough to cover similar abstract marking for
a number of other applications, although as Job noted the 4:4 case wasn't
able to fit into that format.

RFC 1997 communities proved to be a good marking mechanism for generic
applications over the years.  For single-state marking, the well known
communities fit well into that.  Large communities covered the general need
to expand the ability to fit AS numbers in a 1997 style marking mechanism
for 4-byte ASes.  As you've also noticed, those authors also added an
additional field expanding the scope of 1997 communities to add the
flexibility to add another "parameter".

Wide communities is intended to cover more "intent-based" route marking.

As a fundamental CS observation, it is understood that all marking
mechanisms that have scoped namespaces can be collapsed into a smaller
number of equivalence classes.  This is effectively how 1997 community
policy has been implemented over the years, with the mapping of
functionality in those ECs present in a service provider's published
community policy.  However, equivalence classes make operational work more
difficult since it removes more natural human and machine readable versions
of the policy elements.  It's this property that has encouraged a
diversification in marking mechanisms.

-- Jeff

---

From: Randy Bush <[email-masked]>
Date: Wed, 09 Nov 2016 11:06:50 +0900

> It is healthy for the IETF that ideas can compete with each other.

that's what we say until somebody competes with our draft :-)/2