wdiff draft-ietf-idr-reserved-extended-communities-00.txt draft-ietf-idr-reserved-extended-communities-01.txt

Network Working Group B. Decraene
Internet-Draft France Telecom - Orange
Intended status: Standards Track P. Francois
Expires: August 11, November 24, 2011 UCL
February 07, Universite catholique de Louvain
May 23, 2011

Reserved

Assigned BGP extended communities
draft-ietf-idr-reserved-extended-communities-00
draft-ietf-idr-reserved-extended-communities-01

Abstract

This document assigns two BGP extended community types, one
transitive and one non-transitive. It also defines two IANA registries in order to allow the allocation of reserved assign
transitive and non-transitive extended communities. communities from. These are
similar to the existing reserved (formerly Well-known) well-known BGP communities defined in RFC
1997 but provides provide an easier control of inter-AS community
advertisement as a community could be chosen as transitive or non-
transitive across ASes.

For that purpose, this document defines the use of the reserved AS
number 0 for the transitive and non-transitive generic four-octet AS
specific extended community types.

Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].

Status of this Memo

This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

This Internet-Draft will expire on August 11, November 24, 2011.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.

1. Introduction

[RFC1997] defines the BGP community attribute and some BGP Well known well-known
communities whose meaning SHALL be understood by all compliant
implementations. New reserved communities can be registered in the IANA "BGP
Well-known Communities" registry but it can't be assumed anymore that
they will be known by all BGP implementations. Implementations or
BGP policies which recognize them will behave as specified. Implementation
Implementations which do not recognize those new reserved communities
will propagate them from BGP neighbor to BGP neighbor and from AS to
AS with an unlimited scope.

There is currently no agreed way to reserve register a non transitive well well-
known community:

On one hand, [RFC1997] defines BGP Well-known communities with no
structure to set their transitiveness across ASes. Without
structure, non
transitive communities can only be filtered by explicitly enumerating
all community values that will be denied or allowed to BGP speakers
in neighboring ASes. This is not satisfactory as this would require
upgrading all border routers to understand this community before its
first usage.

On the other hand, [RFC4360] defines the BGP extended community
attribute with a structure including a type and a transitive bit "T". 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
a (single) well known
one well-known extended community. RFC 4360 [RFC4360] defines IANA registries
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
regular. Therefore, one needing to reserve a single non-transitive
extended community would need to reserve an extended subtype which
represents 2^48 communities, while a single value is used. This
would both waste the resources and disable the ability to define
global policies on reserved communities, such as to accept them or to
filter them out.

To address this limitation, this document assigns two BGP extended
community types, one transitive and one non-transitive. It also defines two IANA registries
in order to allow the allocation registration of
reserved transitive and non-transitive
extended communities. These are similar to the existing Well-known
BGP communities defined in RFC
1997 [RFC1997] but provides a control on
inter-AS community advertisement as a community could be chosen as
transitive or non-transitive across ASes.

2. IANA Considerations

IANA is requested to assign, from the registry "BGP Extended
Communities Type - extended, transitive type", Assigned extended communities

[I-D.ietf-idr-as4octet-extcomm-generic-subtype] defines a type value TBD generic
sub-type for
"BGP Reserved transitive extended communities":

Registry Name: BGP Extended Communities Type - extended, transitive

Name Type Value
---- ----------
BGP Reserved transitive the four-octet AS specific extended communities TBD (e.g. 0x9000)

IANA is requested to assign, from community. The
value of the registry "BGP Extended
Communities Type - extended, non-transitive", four-octets Global Administrator sub-field contains a type
four-octet Autonomous System number. The value TBD of their two-octet
Local Administrator sub-field has semantics defined by the Autonomous
System set in the Global Administrator sub-field.

This document updates [I-D.ietf-idr-as4octet-extcomm-generic-subtype]
and defines the use of the Local Administrator sub-field when the AS
number encoded in the Global Administrator sub-field has the reserved
value 0.

When the AS number encoded in the Global Administrator sub-field has
the reserved value 0, the communities have global significance. The
lists of those communities are maintained by the IANA in the
registries "Assigned transitive extended communities" for
"BGP Reserved non-transitive the
"transitive generic four-octet AS specific" extended communities":

Registry Name: BGP Extended Communities Type - extended, non-transitive

Name Type Value
---- ----------
BGP Reserved community type
and "Assigned non-transitive extended communities TBD (e.g. 0xd000) 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
communities is similar to the IANA: suggested value one defined by [RFC1997] for the two reserved BGP Extended
Communities extended type are 0x9000 and 0xd000. Otherwise, both
values should be identical, except for their T - Transitive bit (bit
1 as defined in [RFC4360]).
Well-Known communities.

3. IANA Considerations

The IANA is requested to create and maintain a registry entitled "BGP
Reserved
"Assigned transitive extended communities": communities" with the following
registration procedure:

Registry Name: BGP Reserved Assigned transitive extended communities

Range Registration Procedures
---------------------------
----------- -------------------------
0x000000000000-FFFFFFFEFFFF Reserved
0xFFFFFFFF0000-00FFFFFF8000
0x0000-8000 First Come First Served
0x00FFFFFF8001-FFFFFFFFFFFF
0x8001-FFFF Standards Action/Early IANA Allocation

The IANA is requested to create and maintain a registry entitled "BGP
Reserved
"Assigned non-transitive extended communities": communities" with the following
registration procedure:

Registry Name: BGP Reserved Assigned non-transitive extended communities

An application may need both a transitive and a non-transitive reserved
community. It
community and it may be beneficial to have the same value for both
communities. (Note that both extended community communities will still be
different as they will differ from their T bit). The IANA SHOULD try
to accommodate such request to have get both a transitive and non-
transitive reserved assigned community with the same value for both.

4. Security Considerations

This document defines IANA actions. In itself, it has no impact on
the security of the BGP protocol.

5. Normative References

[I-D.ietf-idr-as4octet-extcomm-generic-subtype]
Rao, D., Mohapatra, P., and J. Haas, "Generic Subtype for
BGP Four-octet AS specific extended community",
draft-ietf-idr-as4octet-extcomm-generic-subtype-03 (work
in progress), October 2010.

[RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP
Communities Attribute", RFC 1997, August 1996.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
Communities Attribute", RFC 4360, February 2006.

[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.

Authors' Addresses

Bruno Decraene
France Telecom - Orange
38-40
38 rue du General Leclerc
Issy Moulineaux cedex 9 92794
France

Email: bruno.decraene@orange-ftgroup.com

Pierre Francois
UCL
Universite catholique de Louvain
Place Ste Barbe, 2
Louvain-la-Neuve 1348
BE

Email: francois@info.ucl.ac.be