Skip to main content

BGP Extended Communities Attribute
draft-ietf-idr-bgp-ext-communities-09

Revision differences

Document history

Date Rev. By Action
2012-08-22
09 (System) post-migration administrative database adjustment to the No Objection position for Brian Carpenter
2012-08-22
09 (System) post-migration administrative database adjustment to the No Objection position for Mark Townsley
2012-08-22
09 (System) post-migration administrative database adjustment to the No Objection position for David Kessens
2012-08-22
09 (System) post-migration administrative database adjustment to the No Objection position for Alex Zinin
2012-08-22
09 (System) post-migration administrative database adjustment to the No Objection position for Russ Housley
2005-07-30
09 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2005-07-18
09 Amy Vezza IESG state changed to Approved-announcement sent
2005-07-18
09 Amy Vezza IESG has approved the document
2005-07-18
09 Amy Vezza Closed "Approve" ballot
2005-07-15
09 Bill Fenner State Changes to Approved-announcement to be sent from IESG Evaluation by Bill Fenner
2005-07-15
09 Bill Fenner Removed from agenda for telechat - 2005-07-21 by Bill Fenner
2005-07-15
09 Bill Fenner Note field has been cleared by Bill Fenner
2005-07-15
09 Russ Housley [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley
2005-07-14
09 Bill Fenner Placed on agenda for telechat - 2005-07-21 by Bill Fenner
2005-07-14
09 Bill Fenner State Changes to IESG Evaluation from IESG Evaluation::AD Followup by Bill Fenner
2005-07-14
09 Bill Fenner [Note]: 'Return to agenda to see if Russ is OK with the security considerations.' added by Bill Fenner
2005-07-07
09 (System) [Ballot Position Update] Position for Mark Townsley has been changed to no from discuss by IESG Secretary
2005-07-07
09 Amy Vezza State Changes to IESG Evaluation::AD Followup from IESG Evaluation by Amy Vezza
2005-07-07
09 David Kessens [Ballot Position Update] Position for David Kessens has been changed to No Objection from Discuss by David Kessens
2005-07-07
09 Brian Carpenter [Ballot Position Update] Position for Brian Carpenter has been changed to No Objection from Discuss by Brian Carpenter
2005-07-06
09 Alex Zinin [Ballot Position Update] Position for Alex Zinin has been changed to No Objection from Discuss by Alex Zinin
2005-07-06
09 Jon Peterson [Ballot Position Update] New position, No Objection, has been recorded for Jon Peterson by Jon Peterson
2005-07-06
09 Bert Wijnen [Ballot Position Update] Position for Bert Wijnen has been changed to No Objection from Undefined by Bert Wijnen
2005-07-06
09 Bert Wijnen [Ballot comment]
No further objections
2005-07-06
09 Bert Wijnen [Ballot Position Update] New position, Undefined, has been recorded for Bert Wijnen by Bert Wijnen
2005-07-06
09 Bill Fenner State Changes to IESG Evaluation from IESG Evaluation::AD Followup by Bill Fenner
2005-07-06
09 Bill Fenner [Note]: 'Late addition; updated I-D has posted now.' added by Bill Fenner
2005-07-06
09 (System) Sub state has been changed to AD Follow up from New Id Needed
2005-07-06
09 (System) New version available: draft-ietf-idr-bgp-ext-communities-09.txt
2005-07-06
09 Mark Townsley [Ballot discuss]
Picking up Thomas' DISCUSS regarding type codes, see detail for more.
2005-07-06
09 Mark Townsley [Ballot Position Update] New position, Discuss, has been recorded for Mark Townsley by Mark Townsley
2005-07-05
09 Bill Fenner [Note]: 'Late addition; updated I-D has been submitted but if it''s not available yet see http://homepage.mac.com/BillFenner/draft-ietf-idr-bgp-ext-communities-09.txt .' added by Bill Fenner
2005-07-01
09 Bill Fenner Placed on agenda for telechat - 2005-07-07 by Bill Fenner
2005-07-01
09 Bill Fenner [Note]: 'Late addition; updated I-D hasn''t been submitted yet but is available at http://homepage.mac.com/BillFenner/draft-ietf-idr-bgp-ext-communities-09.txt .' added by Bill Fenner
2005-07-01
09 Bill Fenner
Summary of changes in -09:
- 4 byte AS communities removed, since there are no implementations.
- Link Bandwidth community removed, since there is no …
Summary of changes in -09:
- 4 byte AS communities removed, since there are no implementations.
- Link Bandwidth community removed, since there is no description how to use it.
- Equality comparison update
- Clarify that the Class (Regular or Extended) is not in the structure of the type but in the registration
- Abtract rewritten
- Add a reference to [BGP-MPLS-VPN] for the Route Target & Route Origin
- Clarify that the security considerations are the same as for RFC 1997
2005-05-01
09 Brian Carpenter [Ballot discuss]
I'm picking up Harald's discuss. The reasons are at
http://www.alvestrand.no/ietf/gen/reviews/draft-ietf-idr-bgp-ext-communities-08-allman.txt
2005-05-01
09 Brian Carpenter [Ballot Position Update] New position, Discuss, has been recorded for Brian Carpenter by Brian Carpenter
2005-03-09
09 Thomas Narten
[Ballot comment]
Editorial (some of the following may be irrelvant based on the discuss
comments):

abstract could be a bit more descriptive

>    The …
[Ballot comment]
Editorial (some of the following may be irrelvant based on the discuss
comments):

abstract could be a bit more descriptive

>    The Extended Community Attribute provides two important enhancements
>    over the existing BGP Community Attribute:

Reference to bgp communities?

>            I - IANA authority bit
>
>                Value 0: IANA assignable type using the "First Come First
>                Serve" policy
>
>                Value 1: IANA assignable type using the IETF Consensus
>                policy and experimental

Don't understand what the "and experimental" means here.


>            Remaining 6 bits: Indicates the structure of the
              community

Are these actually  reserved? Or undefined? or?

> 3.2. IPv4 address specific extended community
>
>    This is an extended type with Type Field comprising of 2 octets and
>    Value Field comprising of 6 octets.

How will we get interoperability if the sub-type is not even defined?
What values/semantics does it have?


>          This sub-field contains an IPv4 address assigned by IANA.

what is this? a globally unique unicast address (IANA doesn't  hand
out addresses directly anymore)


     
>    The two members in the tuple  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.

hard to parse: reword as:

    The remaining octets of the community are be interpreted based
    on the value of the Type field.

>    The Type could be either regular or extended. For a regular Type the
>    IANA allocates an 8-bits value; for an extended Type the IANA allo-
>    cates a 16-bits value.

This document defines some sub-types (apparently, but doesn't tell
IANA what values to register. This seems in conflict with the above.

>    The value allocated for a regular Type MUST NOT be reused as the
>    value of the high-order octet when allocating an extended Type.  The
>    value of the high-order octet allocated for an extended Type MUST NOT
>    be reused when allocating a regular Type.

This suggests to  me, that the "sub-type" is not actually a type, but
like the "code" for an ICMP type. I.e, it has meaning only relative to
a specific type. If that is the case, the document should just say
that (and eliminate a bunch of unclarity)
   
>    Future assignment are to be made using either the Standards Action
>    process defined in [RFC2434], or the Early IANA Allocation process
>    defined in [kompella-zinin], or the "First Come First Served" policy
>    defined in [RFC2434].

I'm not sure I understand the motivatoin for the above... I.e., it
looks like the entire name space can be allocated FCFS. If so, why
have more restrictive policies as well? (and is FCFS really the right
policy?)

>    The Type values 0x80-0x8f and 0xc0-0xcf for regular Types, and
>    0x8000-0x8fff and 0xc000-0xcfff for extended Types are experimental,
>    and are not to be assigned by IANA.

The range reserved for experimentation is huge... not really what it
was intended for.
2005-03-09
09 Thomas Narten
[Ballot discuss]
High-level: this document could be a lot clearer in terms of what it
does. After re-reading multiple times, I conclude that what this …
[Ballot discuss]
High-level: this document could be a lot clearer in terms of what it
does. After re-reading multiple times, I conclude that what this
document could/should do is:

Defines a 1 octet type field (not 2-octet), but that  some of the
attributes have a 1-octet "code" field (ala ICMP). The codes are
specific to the type message, and some type codes don't even bother
defining any codes.

Thus, what IANA needs to do is create a type registry, where types are
1-octet values, and that each assigned value may (or may not) have
code field, as defined by the specifically defined type.

So there is no "extended type" per se. It's just that some types have a
sub-type or "code".

>            I - IANA authority bit
>
>                Value 0: IANA assignable type using the "First Come First
>                Serve" policy
>
>                Value 1: IANA assignable type using the IETF Consensus
>                policy and experimental

I don't understand the value of this or what the technical point is.

Is there a _technical_ distinction between types with the high-order
bit set? I think no. But in that case, a better way to specify
the above is to just  say:

  Types 0-127 are assigned through "FCFS", types 128-255 are assigned
  via "IETF Consensus".

Finally, the above policies make me a little uncomfortable. We have a
number of exmaples where FCFS means someone goes to IANA and gets an
assignment. No Internet draft. No IETF review (even cursory). Is this
_really_ what the WG wants? I.e., couldn't you at least require an
Internet-Draft with (say) approval of the WG? While this isn't an
RFC2434 policy, the WG can certainly invent one, tailered to its
needs. For example, something like:

  Types 0-127 are assigned through "Expert Review" per RFC 2434. The
  intention is that the Expert Review consist of review of an Internet
  Draft (for which there is an expectation that an RFC will eventually
  be publishd), with approval of the IDR WG of the allocation.  In the
  event that the IDR WG no longer exists, Expert review would include
  consultation with the IDR mailing list or appropriate follow-on list
  where the BGP community can be openly consulted.

Finally, "experimental" use has a very specific meaning (see RFC
3692
) and IANA doesn't assign them. IF you want to reserve some for
experimentation, this document should just do so by saying something
like:

Types 250-255 are reserved for Experinemtnal use as defined in RFC
3692
.

>            T - Transitive bit
>
>                Value 0: The community is transitive across ASes
>
>                Value 1: The community is non-transitive across ASes

Here is a bit that does have technical significance. Too bad its not
the most significant bit, so that you coudl say something like:

types 0-127 are transitive across ASes, types 128-255 are
non-transitive.

But with the bit where it is, you really want to split the registry
into sub-registries, one for transitive and one for non-transitive.

Can this bit be made the most significant or is it too late for that?
I.e., I think what you need to say now is something like:

There are two kinds of types, transitive and
non-transitive. Transitive types include the ranges 0-63, 128-192,
Non-transitive types are in the range 64-127 and 193-255. Future
requests for assignment of a Type value must specify the specific type
of assignment that is requested.

Finally, I assume the1 T-bit really does  need to be part of the type value
itself? I.e, can the specific type (as part of its definition) state
whether an attribute is transitive or not, or is the intent that an
implementation be able to specify how to handle unrecognized types? (I
suspect so)
2005-03-09
09 Thomas Narten [Ballot Position Update] New position, Discuss, has been recorded for Thomas Narten by Thomas Narten
2005-02-17
09 Amy Vezza State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Amy Vezza
2005-02-17
09 Harald Alvestrand [Ballot discuss]
Got a review from Mark Allman just before telechat, indicating that stuff needs to be cleared up. This is a placeholder.
2005-02-17
09 Harald Alvestrand [Ballot Position Update] New position, Discuss, has been recorded for Harald Alvestrand by Harald Alvestrand
2005-02-17
09 Allison Mankin [Ballot Position Update] New position, No Objection, has been recorded for Allison Mankin by Allison Mankin
2005-02-17
09 David Kessens
[Ballot comment]
This document lacks an index and contains non US ASCII characters.

---
Value Field:

The encoding of the Value Field is dependent on …
[Ballot comment]
This document lacks an index and contains non US ASCII characters.

---
Value Field:

The encoding of the Value Field is dependent on the "type" of
the community as specified by the Type Field.
                 
Two extended communities are declared equal only when all 8 octets of
their encoding are equal.
---

the word 'encoding' is used in slightly different ways. I suggest to
avoid the word in the second sentence.
2005-02-17
09 David Kessens
[Ballot discuss]
What about including support for implementing 12 octet extended
community attributes? "If you've run out before, you'll run out again."
 
-----------

I …
[Ballot discuss]
What about including support for implementing 12 octet extended
community attributes? "If you've run out before, you'll run out again."
 
-----------

I think this document should be split in two:

- One document defines Extended communities
- The other describes the predefined communities

-----------
3.1. Two-octet AS specific extended community
---
3.3. Four-octet AS specific extended community
---

Do we really need/want to have two different types for the same thing ?

------------

---
3.2. IPv4 address specific extended community
---

How to do IPv6 specific extended communities ?
2005-02-17
09 David Kessens [Ballot Position Update] New position, Discuss, has been recorded for David Kessens by David Kessens
2005-02-16
09 Alex Zinin
[Ballot discuss]
The document suffers from the same problem it had back in 2002, namely for the
communities introduced in sections 4--6, only "bits on …
[Ballot discuss]
The document suffers from the same problem it had back in 2002, namely for the
communities introduced in sections 4--6, only "bits on the wire" are defined,
but not the algorithmic changes to the protocol behavior. This is solvable for
Router Target and Route Origin communities by including pointers to the right
2547bis documents.

The Link Bandwidth community needs more work, however. This community is used
by the router vendors to perform BW-proportional BGP load-balancing. The problem
is that BGP multipath load balancing hasn't been documented, though the WG made
a decision to do so back in 2002. I suggest that the WG takes on the multipath
work item and moves the description of the Link-BW community there.
2005-02-16
09 Alex Zinin [Ballot Position Update] New position, Discuss, has been recorded for Alex Zinin by Alex Zinin
2005-02-16
09 Margaret Cullen [Ballot Position Update] New position, No Objection, has been recorded for Margaret Wasserman by Margaret Wasserman
2005-02-16
09 Sam Hartman [Ballot Position Update] New position, No Objection, has been recorded for Sam Hartman by Sam Hartman
2005-02-16
09 Russ Housley
[Ballot discuss]
The security considerations are unacceptable.  A BGP speaker uses
  the Extended Communities attribute to determine which routing
  information it accepts or …
[Ballot discuss]
The security considerations are unacceptable.  A BGP speaker uses
  the Extended Communities attribute to determine which routing
  information it accepts or distributes to its peers.  Thus, it is
  a label-based access control mechanism where any BGP speaker can
  alter the label.  At a minimum, there are new data integrity
  considerations.  I expect that authorization considerations
  should also be discussed.
2005-02-16
09 Russ Housley [Ballot Position Update] Position for Russ Housley has been changed to Discuss from Undefined by Russ Housley
2005-02-16
09 Russ Housley [Ballot comment]
The Abstract is insufficient.  It does not even mention the
  Extended Community Attribute.

  The document authors need to turn off hyphenation.
2005-02-16
09 Russ Housley [Ballot Position Update] New position, Undefined, has been recorded for Russ Housley by Russ Housley
2005-02-15
09 Scott Hollenbeck
[Ballot comment]
The text in section 2 could be clearer about what actually identifies a regular type and an extended type.  After reading the text …
[Ballot comment]
The text in section 2 could be clearer about what actually identifies a regular type and an extended type.  After reading the text I half expected to see something like a bit flag being used to ID one or the other, but there's no bit flag and little additional text included to explain what distinguishes one type from the other.  It might be a good idea to supplement "The value of the high-order octet of the Type Field determines if an extended community is a Regular type or an Extended type" with some additional words to note that the value registered with IANA determines if a type is extended or regular.
2005-02-15
09 Scott Hollenbeck [Ballot Position Update] New position, No Objection, has been recorded for Scott Hollenbeck by Scott Hollenbeck
2005-02-14
09 Ted Hardie [Ballot Position Update] New position, No Objection, has been recorded for Ted Hardie by Ted Hardie
2005-02-09
09 Bill Fenner Placed on agenda for telechat - 2005-02-17 by Bill Fenner
2005-02-09
09 Bill Fenner State Changes to IESG Evaluation from Waiting for Writeup by Bill Fenner
2005-02-09
09 Bill Fenner [Ballot Position Update] New position, Yes, has been recorded for Bill Fenner
2005-02-09
09 Bill Fenner Ballot has been issued by Bill Fenner
2005-02-09
09 Bill Fenner Created "Approve" ballot
2005-02-01
08 (System) New version available: draft-ietf-idr-bgp-ext-communities-08.txt
2004-04-20
09 (System) State has been changed to Waiting for Writeup from In Last Call by system
2004-04-06
09 Amy Vezza Last call sent
2004-04-06
09 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2004-04-05
09 Bill Fenner State Changes to Last Call Requested from Publication Requested by Bill Fenner
2004-04-05
09 Bill Fenner Last Call was requested by Bill Fenner
2004-04-05
09 (System) Ballot writeup text was added
2004-04-05
09 (System) Last call text was added
2004-04-05
09 (System) Ballot approval text was added
2004-04-05
09 Bill Fenner
From: Yakov Rekhter
Subject: BGP Extended Communities to Proposed Standard
Date: Fri, 02 Apr 2004 06:27:14 -0800
To: Alex Zinin , Bill Fenner
Cc: idr@ietf.org …
From: Yakov Rekhter
Subject: BGP Extended Communities to Proposed Standard
Date: Fri, 02 Apr 2004 06:27:14 -0800
To: Alex Zinin , Bill Fenner
Cc: idr@ietf.org, iesg-secretary@ietf.org, skh@nexthop.com,
    yakov@juniper.net

Alex and Bill,

The IDR WG would like to ask the IESG to advance BGP Extended Communities
to a Proposed Standard.

The spec is draft-ietf-idr-bgp-ext-communities-07.txt.
The implementation report is draft-rekhter-ext-communities-survey-02.txt.
2004-04-05
09 Bill Fenner [Note]: 'Holding for BGP base spec.' has been cleared by Bill Fenner
2004-03-31
07 (System) New version available: draft-ietf-idr-bgp-ext-communities-07.txt
2003-08-25
06 (System) New version available: draft-ietf-idr-bgp-ext-communities-06.txt
2002-08-05
09 Bill Fenner Intended Status has been changed to Proposed Standard from None
2002-08-05
09 Bill Fenner Yakov submitted Thu, 01 Aug 2002 11:58:03 -0700.
draft-rekhter-ext-communities-survey-01.txt contains the implementation report.
2002-08-05
09 Bill Fenner Draft Added by fenner
2002-05-10
05 (System) New version available: draft-ietf-idr-bgp-ext-communities-05.txt
2002-05-06
04 (System) New version available: draft-ietf-idr-bgp-ext-communities-04.txt
2002-03-27
03 (System) New version available: draft-ietf-idr-bgp-ext-communities-03.txt
2001-10-04
02 (System) New version available: draft-ietf-idr-bgp-ext-communities-02.txt
2001-08-24
01 (System) New version available: draft-ietf-idr-bgp-ext-communities-01.txt
2001-07-10
00 (System) New version available: draft-ietf-idr-bgp-ext-communities-00.txt