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 |