Subject: LC comments on draft-ietf-idr-bgp-ext-communities-03.txt

From: Alex Zinin <[email-masked]>
Date: Thu, 25 Apr 2002 21:16:43 -0700

Srihari, Dan, Yakov:

 Please find some comment on the draft below.

 A meta comment:

  please check all occurrences of must/should/may, make
  sure they are capitalized where used to express requirement
  levels, and include a reference to 2119.

 Other comments inline:
  
>                draft-ietf-idr-bgp-ext-communities-03.txt
...
>
> 2. Abstract
> 
>    This document describes an extension to BGP [BGP-4] which may be used
>    to provide flexible control over the distribution of routing
>    information.
> 

The rfc-ed will not like the citation in the abstract.

> 3. Introduction
> 
>    The Extended Community Attribute provides two important enhancements
>    over the existing BGP Community Attribute:
> 
>       - It provides an extended range, ensuring that communities can be
>         assigned for a plethora of uses, without fear of overlap.
> 
>       - The addition of a Type field provides structure for the
>         community space.
> 
>    The addition of structure allows the usage of policy based on the
>    application for which the community value will be used. For example,
>    one can filter out all communities of a particular type, or allow
>    only certain values for a particular type of community. It also
>    allows one to specify whether a particular community is transitive or
>    non-transitive across Autonomous system boundary. Without structure,
>    this can only be accomplished by explicitly enumerating all community
>    values which will be denied or allowed and passed to BGP speakers in
>    neighboring ASes based on the transitive property.
> 
> 
> 4. BGP Extended Communities Attribute
> 
>    The Extended Communities Attribute is a transitive optional BGP
>    attribute.  The attribute consists of a set of "extended
>    communities".  Each extended community is coded as an eight octet
>    value.  All routes with  the Extended Communities attribute belong to
>    the communities listed in the attribute.
> 
>    The Extended Communities Attribute has Type Code 16.
> 
>    Each Extended Community is encoded as an eight octet quantity, as
>    follows:

It might be helpful to include a format illustration here,
something like this maybe:

     The value of the Extended Communities Attribute is a series
     of eight octet Type and Value field groups, each encoding a specific
     Extended Community as shown below:

        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 high    |  Type low(*)  |                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+          Value                |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       .                                                               .
       .                                                               .
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Type high    |  Type low(*)  |                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+          Value                |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       *) Present for Extended types only, used for the Value field
          otherwise

>       - Type Field  : 1 or 2 octets
>       - Value Field : Remaining octets
> 
>       Type Field:
> 
>          Two classes of Type Field are introduced: Regular type and
>          Extended type.
> 
>          The size of Type Field for Regular types is 1 octet and the
>          size of the Type Field for Extended types is 2 octets.
> 
>          The value of the high-order octet will determine if its a
>          regular type or an extended type. The value of the high-order
> 
> 
> 
> Sangli, Tappan, Rekhter                                         [Page 2]
> 
> 
> 
> 
> 
> Internet Draft  draft-ietf-idr-bgp-ext-communities-03.txt     March 2002
> 
> 
>          octet of the Type Field defined as regular type (or extended
>          type) for a extended community MUST NOT be reused as the value
>          of the high-order octet of the Type Field defined as extended
>          type (or regular type). In other words, a new extended
>          community of regular type (extended type) should have unique
>          (and new) value for the high-order octet (high-order and low-
>          order octet).
> 
>          The high-order octet of the Type Field is as shown below:
> 
>             First bit (MSB)   : IANA authority bit
>                                 Value 0 : IANA assignable type
>                                 Value 1 : Vendor-specific types
> 
>             Second bit        : Transitive bit
>                                 Value 0 : The community is
>                                           Transitive across ASes
>                                 Value 1 : The community is
>                                           Non-Transitive across ASes
> 
>             Remaining 6 bits  : Indicates the structure of the
>                                 community

An IETF-style format for the field would be appreciated :)

Maybe a couple of words saying that the IANA bit does not
require special processing would be good.

>       Value Field:
> 
>          The encoding of the Value Field is dependent on the "type" of
>          the community as specified by the Type Field. The encoding of
>          the community for the transitive communities should be such
>          that it is unique globally (i.e.  across the Autonomous
>          Systems).

It is not clear what kind of implications the last sentence imposes
on the implementations from the _encoding_ perspective...

>       Two extended communities are declared equal only when entire 8
>       octets are equal.
>
>       The two members in the tuple <Type, Value> should be enumerated to
>       specify any community value. Based on the value of the Type field,
>       the remaining octets of the community should be interpreted.
>
> 5. New BGP Extended Community Types.
> 
>    This document introduces a few extended types and defines the Value
                                                              ^
                                                       "the format of"
>    Field for those types.

Probably some wording should be added here to say that the communities
below provide semantical "templates" that are used later for different
functions; each template type is identified by the high order byte
of the Ext Comm Type field, and the low order byte (sub-type) is used
to specify the function... or something along these lines

>       Type 0x00:

I think the type should have a meaningful name at
least to use it in the IANA registry.
Something like "Two-octet AS specific extended community"

>          This is an extended type with Type Field comprising of 2 octets
>          and Value Field comprising of 6 octets.
> 
>          The value of the high-order octet of this extended type is
>          0x00. The low-order octet of this extended type is used to
>          indicate sub-types.
> 
>          The Value Field consists of two sub-fields:

Something like this would be great:

        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 High=0x00 |   Sub-Type    |    Global Administrator       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Local Administrator                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

>
>             Global Administrator sub-field: 2 octets
> 
>                This sub-field contains an Autonomous System number
>                assigned by IANA.
> 
>             Local Administrator sub-field: 4 octets
> 
>                The organization identified by Autonomous System number
>                in the Global Administrator sub-field, can encode any

"the organization ... can encode". A little weird...

>                information in this sub-field.  The value and meaning of
>                the value encoded in this sub-field should be defined by
>                the sub-type of the community.

"The value... be defined by the sub-type"
probably the format is meant...

>       Type 0x01:

Same comment about name. Something like "IPv4 address specific
extended community"

> 
>          This is an extended type with Type Field comprising of 2 octets
>          and Value Field comprising of 6 octets.
> 
>          The value of the high-order octet of this extended type is
>          0x01. The low-order octet of this extended type is used to
>          indicate sub-types.
> 
>          The Value field consists of two sub-fields.

ditto format

> 
>             Global Administrator sub-field: 4 octets
> 
>                This sub-field contains an IPv4 address assigned by IANA.
> 
>             Local Administrator sub-field: 2 octets
> 
>                The organization which has been assigned the IPv4 address
>                in the Global Administrator sub-field, can encode any

same comment

>
>                information in this sub-field.  The value and meaning of
>                this value encoded in this sub-field should be defined by
>                the sub-type of the community.

same comment about the value/format

>       Type 0x02:

Name as well: like "Four-octet AS specific..."?

> 
>          This is an extended type with Type Field comprising of 2 octets
>          and Value Field comprising of 6 octets.
> 
>          The value of the high-order octet of this extended type is
>          0x02. The low-order octet of this extended type is used to
>          indicate sub-types.
> 
>          The Value Field consists of two sub-fields.

ditto format

>             Global Administrator sub-field: 4 octets
> 
>                This sub-field contains a 4-octets Autonomous System
>                number assigned by IANA.
> 
>             Local Administrator sub-field: 2 octets
> 
>                The organization identified by Autonomous System number
>                in the Global Administrator sub-field, can encode any
>                information in this sub-field.  The value and meaning of
>                the value encoded in this sub-field should be defined by
>                the sub-type of the community.

ditto comments above

>       Type 0x03:

Same comment about name here, "Opaque" ?

> 
>          This is an extended type with Type Field comprising of 2 octets
>          and Value Field comprising of 6 octets.
> 
>          The value of the high-order octet of this extended type is
>          0x03. The low-order octet of this extended type is used to
>          indicate sub-types.
> 
>          The Value Field contains a 6 byte value of structure with sub-
>          fields.

What kind of sub-fields? Do we need this sentence here?

>          This is a generic community of extended type. The value of the
>          sub-type which should define the Value Field is to be assigned
>          by IANA.
>
...
> 
> 8. Link Bandwidth Community
> 
>    When a router receives a route from a directly connected external
>    neighbor (the external neighbor that is one IP hop away), and
>    advertises this route (via IBGP) to internal neighbors, as part of
>    this advertisement the router may carry the bandwidth of the link
>    that connects the router with the external neighbor. The bandwidth of
>    such a link is carried in the Link Bandwidth Community. The community
>    MAY be marked as non-transitive across the Autonomous system
>    boundary.
> 
>    If the community is marked as non-transitive, then the value of the
>    high-order octet of the extended Type Field is 0x40, otherwise it is
>    0x00.  The value of the low-order octet of the extended type field
>    for this community is 0x04.
> 
> 
> 
> 
> Sangli, Tappan, Rekhter                                         [Page 6]
> 
> 
> 
> 
> 
> Internet Draft  draft-ietf-idr-bgp-ext-communities-03.txt     March 2002
> 
> 
>    The value of the Global Administrator sub-field in the Value Field
>    MUST represent the Autonomous System of the router that attaches the
>    Link Bandwidth Community. When a router receives a route with the
>    community, the router may check the AS number in the Global
>    Administrator sub-field to see if its not the local AS and hence
>    ignore the information carried in the Link Bandwidth Community.
> 
>    The bandwidth of the link is expressed as 4 octets in IEEE floating
>    point format, units being bytes per second. It is carried in the
>    Local Administrator sub-field of the Value Field.

Is this supposed to be used in the path selection algo to choose
the best exit? If so, how do we make sure that routers that support
this and those that don't, do not make inconsistent decisions and
thus do not form permanent loops?

> 9. Operations
> 
>    A BGP speaker may use the Extended Communities attribute to control
>    which routing information it accepts, prefers or distributes to its
>    peers.

Do we need some words about consistent acceptance policy among
BGP speakers within the same AS?

>    A BGP speaker receiving a route that doesn't have the Extended
>    Communities attribute may append this attribute to the route when
>    propagating it to its peers.
> 
>    A BGP speaker receiving a route with the Extended Communities
>    attribute may modify this attribute according to the local policy.
> 
>    A BGP speaker should not propagate a non-transitive extended
>    community across the Autonomous system boundary.

What about the situation where a locally originated non-transitive
community is sent over an eBGP session?

>    A route may carry both the BGP Communities attribute  as defined in
>    [RFC1997]), and the Extended BGP Communities attribute. In this case
>    the BGP Communities attribute is handled as specified in [RFC1997],
>    and the Extended BGP Communities attribute is handled as specified in
>    this document.
> 
> 
> 10. IANA Considerations
> 
>    For the high-order octet of the Type Field, values 0x00 through 0x03
>    are assigned in this document and are defined as extended types. For
>    the combination of the high-order and low-order octets of the Type
>    Field values 0x0002-0x0004, 0x0102-0x0103, and 0x0202-0x0203 are
>    assigned in this document.
> 
>    The Type Field values 0x04-0x3f for regular types (0x0400-0x3fff when
>    expressed as extended types) are to be assigned by IANA, using the
>    "First Come First Served" policy defined in RFC 2434. The extended
>    type field values 0x0000-0x0001, 0x0005-0x00ff, 0x0100-0x0101,
>    0x0104-0x01ff, 0x0200-0x0201, 0x0204-0x02ff and 0x0300-0x03ff are to
> 
> 
> 
> Sangli, Tappan, Rekhter                                         [Page 7]
> 
> 
> 
> 
> 
> Internet Draft  draft-ietf-idr-bgp-ext-communities-03.txt     March 2002
> 
> 
>    be assigned by IANA, using the "First Come First Served" policy
>    defined in RFC 2434. Type values 0x80-0xbf for regular types
>    (0x8000-0xbfff when expressed as extended types) are vendor-specific
>    types, and values in this range are not to be assigned by IANA.

Couple of thoughts here...

It might be a good idea to reserve something for the IETF consensus
allocation to be on the safe side.

Also, the text above might not be transparent enough for IANA to
manage efficiently.

Maybe one could say that IANA is supposed to maintain one registry
for the high-order octet of the Type field, associate a
regular/extended attribute with each value, exclude the Transitive
bit from allocation, and make the following allocations according
to this document:

         Type     Reg/Ext   Description
     ----------------------------------------
            0x00    Ext     Name-for-type-00
            0x01    Ext     Name-for-type-01
            0x02    Ext     Name-for-type-02
            0x03    Ext     Name-for-type-03
       0x04-0x3F     -      unassigned
       0x80-0xBF     -      vendor specific

Then also say that for each extended type, a registry of sub-types
is maintained and give the initial assignment like this:
       
  Sub-types for type 0x00:

      Sub-type    Description
     --------------------------------------
      0x00-0x01   unassigned
           0x02   Route target community
           0x03   Route origin community
           0x04   Link bandwidth community
      0x05-0xFF   unassigned

Cheers,
Alex