Subject: BGP Extended Communities

From: [email-masked]
Date: Tue, 16 Jul 2002 22:14:14 -0700

Greetings,

I was going over the draft-ietf-idr-bgp-ext-communities-05.txt.  I
think we can make significant enhancements to the functionality,
efficency and flexibility of this draft.  If we step back and look
at defining a more generic solution which can address both
current and future needs we will be better served.

In order to do that, I'd like to propose a couple of changes to the
current draft.  Here are the enhancements these changes will provide:

- Support for IPv6.  If we are going to move to IPv6 at some point,
we should include support for it in the protocol extentions we define.
- More efficient packing of values in the data field.  A good example
of where this enhancement would be applicable is in the
draft-ietf-ptomaine-bgp-redistribution-00.txt document.
- Cleaner support for a broad range of future data field structures,
and interpretations.
- Support for locally defined community structures (types).
- Support for locally defined community sub-types.

Below I have proposed some modifications to the text of the draft to
support these enhancements.

(Section 5)

Each Extended Community is encoded as a variable length quantity, as
follows:

  - Type Field: 1 octet
  - Subtype Field: 1 octet
  - Length Field: 1 octet
  - Value Field: 0-63 octets

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |    Subtype    |    Length     |               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     Value     |
      |                                               (0-63 octets)   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

**  1) This eliminates the "regular" and the "extended" variations in favor
**  of a single definition.  Since all of the current proposals are or can be
**  represented as extended types, and the addition of a variable length
**  value field allows as many bytes are needed for data, the "regular" type
**  can be removed.
**  2) The Value field is made variable length.  This key enhancement allows
**  us to efficently encode lists of ASN's, IPv4 and IPv6 addresses.

Type Field:

  The Type field is one octet.  This octect is split into three sections:

             0 1 2 3 4 5 6 7
            +-+-+-+-+-+-+-+-+
            |I|T|           |
            +-+-+-+-+-+-+-+-+
<< all the same as the existing draft until: >>

  Remaining 6 bits:  Indicates the structure of the community.  Specifically
   the type defined by these bits indicates how the data in the Value field
   is structured.  For example, a type 1 (000001) might represent a 2 part
   value field where the first part is expected to be a 2-octet ASN and
   the second part would be a variable-length value.  A basic set of
   useful types are defined later in this document.

Subtype Field:

  The Subtype field is one octet.  This contents of this octet are used
  to clarify the interpretation of the type field.  For example, a
  subtype 2, which would apply to both the IP-addres types defined later
  in this document, might indicate that the IP addresses contained in
  part one of the value field indicate that the BGP route originated
  at the router with that IP address.

(Section 6)

Base BGP Extended Community Type

  This section defines the base BGP community specification.  Since the
  root value of communities is the ability to tag a route with arbitrary
  information, and then create a system to give that information meaning,
  the base extended community type (type 0), is very simple.  This
  base type could also be described as the "opaque type."

  Like all extended commnuities, this type can be transitive or
  non-transitive.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |      0x00     |    Length     |               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     Value     |
      |                                               (0-63 octets)   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

** The differentiation of the base type from the other types defined in
** this document is important.  The base type is what the rest are built
** on.  Similar functionality to all the other types can be recreated
** with sufficient manual configuration and this base type.

(Section 7)

Extended Community Type Summary:

  Not including the base type, there are four community types defined in
  this document.  Each represents a different structure a community can
  take.

  Type 1:
    2 part Value Field.  The first part is 2 octets.  The second part
    is variable.  If this type is transitive, the first part
    MUST contain the 2-octet ASN of the originating network.
  Type 2:
    2 part Value Field.  The first part is 4 octets.  The second part
    is variable.  If the type is transitive, the first part
    MUST contain the 4-octet ASN of the originating network.
  Type 3:
    2 part Value Field.  The first part is 4 octets.  The second part
    is variable.  The first part contains an IPv4 address.
  Type 4:
    2 part Value Field.  The first part is 16 octets. The second part
    is variable.  The first part contains an IPv6 address.

(Section 8)

Extended Community Subtype Summary:

  Type 0:
    No Subtype Defined.
  Type 1:
    This is the Route Target Subtype.  This subtype applies to the
    IP address type communities (types 3 & 4). The first part of a community
    with this subtype represents the loopback of the router where this
    route is to be announced.  Please see RFC2547 for more details.

** Correct me if my interperetation of the Route Target Community is
** incorrect.

  Type 2:
    This is the Route Origin Subtype.  This subtype applies to the
    IP address type communities (types 3 & 4). The first part of a community
    with this subtype represents the loopback of the router where this
    route is announced.
  Type 3:
    This is the Link Bandwidth Subtype.  This subtype applies to the
    ASN type communities (types 1 & 2). The first part od a community
    with this subtype represents the ASN of the eBGP neighbor whose
    link bandwidth you wish to distribute.  The second part of a
    community with this subtype represents the bandwidth of the link
    in bits-per-second, encoded in IEEE floating point format.

(Section 9)

Locally Defined Commnuity Types

  This section reserves a subgroup of the Vendor-Specific/Experimental
  type values (I bit = 1), for locally defined types.  This allows
  operators to define their own community structures.  To prevent type
  collision, these types MUST be non-transitive.

  Experimental Non-Transitive Type 32-63 (0xE0-0xFF)

  A locally defined type will have a syntax for interpretation defined
  on the routers that need to interpret it.  If a router receives a
  community type associated with this range, and does not have a value
  defined, it should pass it along normally, and ignore the contents.

(Section 10)

Locally Defined Community Subtypes

  This section reserves a subgroup of the subtype space for local
  definition.  This allows operator to define varriant interpertations
  for exiting types (locally defined or otherwise).  These subtypes
  MUST be attached to non-transitive community values to prevent
  subtype collision.

  Non-Transitive Subtypes 192-255 (0xC0-0xFF)

  A locally defined subtype will have an syntax for interpertation
  defined on the routers that need to interpret it.  If a router
  receives a community subtype associated with this range, and does
  not have a value defined, it should pass the it along normally, and
  ignore the contents.

---

From: Susan Hares <[email-masked]>
Date: Wed, 17 Jul 2002 03:52:55 -0400

Andrew:

You are on the agenda.  Could you send me your last name as well?

Sue

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 24 Jul 2002 12:18:03 -0400

Andrew,

I've given this some time for others to respond.  Since I'm
mostly hearing resounding silence, here's my take on the issue:

> current and future needs we will be better served.

IMO:
1. The authors *could* have done a much better job at providing
   a generic coloring mechnism for the routes.
2. Extended communities were originally deployed to solve a
   specific problem - RFC 2547 vpns.  These don't deal with IPv6
   either.
3. This extension is already widely deployed for the above.

While it would be nice to go back and redo things, IMO this is
too widely deployed by too many big router vendors to make this
change.

> - Support for locally defined community sub-types.

What I would recommend is that IDR spend a little time enumerating
what properties a generic route coloring mechanism should have.
(The above is a good start.)
Even if this has nothing done with it over the short term, it should
be there for anyone who decides to do the "next greatest thing".

The thing that makes me queasy is that we can very easily go
beyond TLVs and sub-TLVs into a mess that looks like BER.
For all their deficiencies, (extended) communities are easy to
parse in your code.  BER isn't.

-- 
Jeff Haas 
NextHop Technologies

---

From: [email-masked]
Date: Wed, 24 Jul 2002 12:38:08 -0700

Jeff,

Thanks for the input.  At the meeting in Yokohama, a number of other
people expressed your same concerns about deployment of the existing
2547-oriented extended communities draft.  The consensus was for me to
write up the proposal as a seperate BGP attribute.  I hope to get a 
draft out in the next couple weeks for the idr community to beat on.

Andrew

On Wed, Jul 24, 2002 at 12:18:03PM -0400, Jeffrey Haas wrote:
> Delivered-To: [email-masked]
> Delivered-To: [email-masked]
> Delivered-To: [email-masked]
> Date: Wed, 24 Jul 2002 12:18:03 -0400
> From: Jeffrey Haas <[email-masked]>
> To: [email-masked]
> Cc: [email-masked], [email-masked]
> Subject: Re: BGP Extended Communities
> User-Agent: Mutt/1.2.5i
> In-Reply-To: <[email-masked]>; from [email-masked] on Tue, Jul 16, 2002 at 10:14:14PM -0700
> X-Virus-Scanned: by AMaViS perl-11
> Precedence: bulk
> X-OriginalArrivalTime: 24 Jul 2002 16:19:49.0182 (UTC) FILETIME=[EEBEC5E0:01C2332D]
> 
> Andrew,
>