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

[Jeffrey Haas <[e-mail]>]

[Removing individual draft aliases.]

On Tue, Nov 08, 2016 at 07:51:52PM +0800, [e-mail] 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.

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