draft-ietf-idr-reserved-extended-communities-02.txt | draft-ietf-idr-reserved-extended-communities-03.txt | |||
---|---|---|---|---|
Network Working Group B. Decraene | Network Working Group B. Decraene | |||
Internet-Draft France Telecom - Orange | Internet-Draft France Telecom - Orange | |||
Intended status: Standards Track P. Francois | Intended status: Standards Track P. Francois | |||
Expires: June 7, 2012 IMDEA Networks | Expires: November 22, 2012 IMDEA Networks | |||
Dec 05, 2011 | May 21, 2012 | |||
Assigned BGP extended communities | Assigned BGP extended communities | |||
draft-ietf-idr-reserved-extended-communities-02 | draft-ietf-idr-reserved-extended-communities-03 | |||
Abstract | Abstract | |||
This document defines two IANA registries in order to assign | This document defines an IANA registry in order to assign non- | |||
transitive and non-transitive extended communities from. These are | transitive extended communities from. These are similar to the | |||
similar to the existing well-known BGP communities defined in RFC | existing well-known BGP communities defined in RFC 1997 but provide a | |||
1997 but provide an easier control of inter-AS community | control over inter-AS community advertisement as, per RFC RFC 4360, | |||
advertisement as a community could be chosen as transitive or non- | they are not transitive across Autonomous System boundaries. | |||
transitive across ASes. | ||||
For that purpose, this document defines the use of the reserved AS | For that purpose, this document defines the use of the reserved | |||
number 0 for the transitive and non-transitive generic four-octet AS | Autonomous System number 0.65535 in the non-transitive generic four- | |||
specific extended community types. | octet AS specific extended community type. | |||
Requirements Language | Requirements Language | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
document are to be interpreted as described in RFC 2119 [RFC2119]. | document are to be interpreted as described in RFC 2119 [RFC2119]. | |||
Status of this Memo | Status of this Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
skipping to change at page 1, line 46 | skipping to change at page 1, line 45 | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on June 7, 2012. | This Internet-Draft will expire on November 22, 2012. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2011 IETF Trust and the persons identified as the | ||||
Copyright (c) 2012 IETF Trust and the persons identified as the | ||||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
described in the Simplified BSD License. | described in the Simplified BSD License. | |||
1. Introduction | 1. Introduction | |||
[RFC1997] defines the BGP community attribute and some BGP well-known | [RFC1997] defines the BGP community attribute and some BGP well-known | |||
communities whose meaning SHALL be understood by all compliant | communities whose meaning SHALL be understood by all compliant | |||
implementations. New communities can be registered in the IANA "BGP | implementations. New communities can be registered in the IANA "BGP | |||
Well-known Communities" registry but it can't be assumed anymore that | Well-known Communities" registry but it can't be assumed anymore that | |||
they will be known by all BGP implementations. Implementations or | they will be known by all BGP implementations. Implementations or | |||
BGP policies which recognize them will behave as specified. | BGP policies which recognize them will behave as specified in the | |||
Implementations which do not recognize those new reserved communities | IANA registry. Implementations which do not recognize those new IANA | |||
will propagate them from BGP neighbor to BGP neighbor and from AS to | assigned communities will propagate them from BGP neighbor to BGP | |||
AS with an unlimited scope. | neighbor and from AS to AS with an unlimited scope. | |||
There is currently no agreed way to register a non transitive well- | There is currently no agreed way to register a non-transitive well- | |||
known community: | known community. | |||
On one hand, [RFC1997] defines BGP Well-known communities with no | On one hand, [RFC1997] defines BGP Well-known communities with no | |||
structure to set their transitiveness across ASes. Without | structure to set their transitiveness across ASes. Without | |||
structure, communities can only be filtered by explicitly enumerating | structure, communities can only be filtered by explicitly enumerating | |||
all community values that will be denied or allowed to BGP speakers | all community values that will be denied or allowed to BGP speakers | |||
in neighboring ASes. This is not satisfactory as this would require | in neighboring ASes. This is not satisfactory as this would require | |||
upgrading all border routers to understand this community before its | upgrading all border routers to understand this community before its | |||
first usage. | first usage. | |||
On the other hand, [RFC4360] defines the BGP extended community | On the other hand, [RFC4360] defines the BGP extended community | |||
attribute with a structure including a type and a transitive bit "T". | attribute with a structure including a type and a transitive bit "T". | |||
This transitive bit, when set, allows to restrict the scope of the | This transitive bit, when set, allows to restrict the scope of the | |||
community within an AS. But their is no IANA registry to allocate | community within an AS. But there is no IANA registry to allocate | |||
one well-known extended community. [RFC4360] defines IANA registries | one well-known extended community. [RFC4360] defines IANA registries | |||
to allocate BGP Extended Communities types. Each type is able to | to allocate BGP Extended Communities types. Each type is able to | |||
encode 2^48 or 2^56 values depending on the type being extended or | encode 2^48 or 2^56 values depending on the type being extended or | |||
regular. Therefore, one needing to reserve a single non-transitive | regular. Therefore, one needing to reserve a single non-transitive | |||
extended community would need to reserve an extended subtype which | extended community would need to reserve an extended subtype which | |||
represents 2^48 communities, while a single value is used. This | represents 2^48 communities, while a single value is used. This | |||
would both waste the resources and disable the ability to define | would both waste the resources and disable the ability to define | |||
global policies on reserved communities, such as to accept them or to | global policies on reserved communities, such as to accept them or to | |||
filter them out. | filter them out. In addition, using a new community type typically | |||
requires a software upgrade on both the router setting the community | ||||
and the router using it in a BGP policy. So this would not allow the | ||||
networking community to quickly define and use a new community. | ||||
To address this limitation, this document defines two IANA registries | To address this limitation, this document defines an IANA registry in | |||
in order to allow the registration of transitive and non-transitive | order to allow the registration of non-transitive extended | |||
extended communities. These are similar to the existing Well-known | communities. These are similar to the existing Well-known BGP | |||
BGP communities defined in [RFC1997] but provides a control on | communities defined in [RFC1997] but provides a control on inter-AS | |||
inter-AS community advertisement as a community could be chosen as | community advertisement. Indeed, as per [RFC4360] non-transitive | |||
transitive or non-transitive across ASes. | communities are removed from routes propagated to another AS. | |||
2. Assigned extended communities | 2. Assigned non-transitive extended communities | |||
[I-D.ietf-idr-as4octet-extcomm-generic-subtype] defines a generic | [I-D.ietf-idr-as4octet-extcomm-generic-subtype] defines a generic | |||
sub-type for the four-octet AS specific extended community. The | sub-type for the four-octet AS specific extended community. The | |||
value of the four-octets Global Administrator sub-field contains a | value of the four-octets Global Administrator sub-field contains a | |||
four-octet Autonomous System number. The value of their two-octet | four-octet Autonomous System number. The value of their two-octet | |||
Local Administrator sub-field has semantics defined by the Autonomous | Local Administrator sub-field has semantics defined by the Autonomous | |||
System set in the Global Administrator sub-field. | System set in the Global Administrator sub-field. | |||
This document updates [I-D.ietf-idr-as4octet-extcomm-generic-subtype] | This document updates [I-D.ietf-idr-as4octet-extcomm-generic-subtype] | |||
and defines the use of the Local Administrator sub-field when the AS | and defines the use of the Local Administrator sub-field of the "non- | |||
number encoded in the Global Administrator sub-field has the reserved | transitive generic four-octet AS specific" extended community type | |||
value 0. | when the AS number has the reserved value 0.65535 (0x0000FFFF). | |||
When the AS number encoded in the Global Administrator sub-field has | When the AS number, encoded in the Global Administrator sub-field, | |||
the reserved value 0, the communities have global significance. The | has the reserved value 0.65535, the communities have global | |||
lists of those communities are maintained by the IANA in the | significance. The lists of those communities are maintained by the | |||
registries "Assigned transitive extended communities" for the | IANA in the registry "Assigned non-transitive extended communities". | |||
"transitive generic four-octet AS specific" extended community type | ||||
and "Assigned non-transitive extended communities" for the "non- | ||||
transitive generic four-octet AS specific" extended community type. | ||||
Note that this use of the reserved AS number 0 in the AS field of the | Note that this use of the reserved AS number 0.65535 in the AS field | |||
communities is similar to the one defined by [RFC1997] for the BGP | of the communities is similar to the one defined by [RFC1997] for the | |||
Well-Known communities. | BGP Well-Known communities. In particular, [RFC1997] also uses the | |||
reserved AS number 65535. | ||||
3. IANA Considerations | 3. Assigned transitive extended communities | |||
The IANA is requested to create and maintain a registry entitled | As per [RFC4893], a 2-octet Autonomous System number can be converted | |||
"Assigned transitive extended communities" with the following | into a 4-octet Autonomous System number by setting the two high-order | |||
registration procedure: | octets of the 4-octet field to zero. This applies to the reserved | |||
2-octet Autonous System number 65535 which could use either a | ||||
standard community or the 4-octet AS specific generic extended | ||||
community. As noted in | ||||
[I-D.ietf-idr-as4octet-extcomm-generic-subtype], this is undesirable | ||||
as they would be treated as different communities, even if they had | ||||
the same values. | ||||
Registry Name: Assigned transitive extended communities | Therefore, this document does not define a non-transitive extended | |||
community registry and transitive communities are still to be | ||||
assigned as per [RFC1997]. | ||||
Range Registration Procedures | 4. IANA Considerations | |||
----------- ------------------------- | ||||
0x0000-8000 First Come First Served | ||||
0x8001-FFFF Standards Action/Early IANA Allocation | ||||
The IANA is requested to create and maintain a registry entitled | The IANA is requested to create and maintain a registry entitled | |||
"Assigned non-transitive extended communities" with the following | "Assigned non-transitive extended communities" with the following | |||
registration procedure: | registration procedure: | |||
Registry Name: Assigned non-transitive extended communities | Registry Name: Assigned non-transitive extended communities | |||
with Global Significance | ||||
Range Registration Procedures | Range Registration Procedures | |||
----------- ------------------------- | ----------- ------------------------- | |||
0x0000-8000 First Come First Served | 0x0000-8000 First Come First Served | |||
0x8001-FFFF Standards Action/Early IANA Allocation | 0x8001-FFFF Standards Action/Early IANA Allocation | |||
An application may need both a transitive and a non-transitive | An application may need both a transitive and a non-transitive | |||
community and it may be beneficial to have the same value for both | community and it may be beneficial to have the same value for both | |||
communities. (Note that both extended communities will still be | communities. Therefore, the IANA SHOULD try to accommodate such | |||
different as they will differ from their T bit). The IANA SHOULD try | request to get both a non-transitive community from the above | |||
to accommodate such request to get both a transitive and non- | "Assigned non transitive extended communities" and a transitive | |||
transitive assigned community with the same value for both. | community from [RFC1997] BGP Well-known Communities with the same | |||
(lower two-octets) value for both. | ||||
4. Security Considerations | 5. Security Considerations | |||
This document defines IANA actions. In itself, it has no impact on | This document defines IANA actions. In itself, it has no impact on | |||
the security of the BGP protocol. | the security of the BGP protocol. | |||
5. Normative References | It allows the allocation of non-transitive global communities which | |||
are not propagated across Autonomous System boundaries. Compared to | ||||
a transitive well-known community, a non-transitive community can | ||||
provide some security benefit both for the sender and the receiver of | ||||
the community. | ||||
6. Acknowledgements | ||||
We would like to acknowledge John Scudder and Jeffrey Haas for their | ||||
contribution to this document. | ||||
7. Normative References | ||||
[I-D.ietf-idr-as4octet-extcomm-generic-subtype] | [I-D.ietf-idr-as4octet-extcomm-generic-subtype] | |||
Rao, D., Mohapatra, P., and J. Haas, "Generic Subtype for | Rao, D., Mohapatra, P., and J. Haas, "Generic Subtype for | |||
BGP Four-octet AS specific extended community", | BGP Four-octet AS specific extended community", | |||
draft-ietf-idr-as4octet-extcomm-generic-subtype-04 (work | draft-ietf-idr-as4octet-extcomm-generic-subtype-05 (work | |||
in progress), July 2011. | in progress), March 2012. | |||
[RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP | [RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP | |||
Communities Attribute", RFC 1997, August 1996. | Communities Attribute", RFC 1997, August 1996. | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, March 1997. | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended | [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended | |||
Communities Attribute", RFC 4360, February 2006. | Communities Attribute", RFC 4360, February 2006. | |||
[RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS | ||||
Number Space", RFC 4893, May 2007. | ||||
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an | [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an | |||
IANA Considerations Section in RFCs", BCP 26, RFC 5226, | IANA Considerations Section in RFCs", BCP 26, RFC 5226, | |||
May 2008. | May 2008. | |||
Appendix A. Appendix A. Changes / Author Notes | ||||
[RFC Editor: Please remove this section before publication ] | ||||
Changes -01 | ||||
o Name changed from 'Reserved BGP extended communities' to 'Assigned | ||||
BGP extended communities' | ||||
o Addition of section 'Assigned extended communities' | ||||
Changes -02: no change, refresh only. | ||||
Changes -03 | ||||
o Use of AS number 0.65535 (0x0000FFFF) instead of AS 0. This is | ||||
better aligned with RFC 1997 which also uses AS 65535. | ||||
o Remove the transitive flavor of assigned extended communities. | ||||
RFC 1997 well-known standard communities to be used instead. | ||||
Authors' Addresses | Authors' Addresses | |||
Bruno Decraene | Bruno Decraene | |||
France Telecom - Orange | France Telecom - Orange | |||
38 rue du General Leclerc | 38 rue du General Leclerc | |||
Issy Moulineaux cedex 9 92794 | Issy Moulineaux cedex 9 92794 | |||
France | France | |||
Email: bruno.decraene@orange.com | Email: bruno.decraene@orange.com | |||
End of changes. 26 change blocks. | ||||
59 lines changed or deleted | 102 lines changed or added | |||
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |