draft-ietf-idr-as4octet-extcomm-generic-subtype-02.txt   draft-ietf-idr-as4octet-extcomm-generic-subtype-03.txt 
Network Working Group D. Rao Network Working Group D. Rao
Internet-Draft P. Mohapatra Internet-Draft P. Mohapatra
Intended status: Standards Track Cisco Systems Intended status: Standards Track Cisco Systems
Expires: January 27, 2011 J. Haas Expires: April 22, 2011 J. Haas
Juniper Networks Juniper Networks
July 26, 2010 October 24, 2010
Generic Subtype for BGP Four-octet AS specific extended community Generic Subtype for BGP Four-octet AS specific extended community
draft-ietf-idr-as4octet-extcomm-generic-subtype-02.txt draft-ietf-idr-as4octet-extcomm-generic-subtype-03.txt
Abstract Abstract
Maintaining the current best practices with communities, ISPs and Maintaining the current best practices with communities, ISPs and
enterprises that are assigned a 4-octet AS number may want the BGP enterprises that are assigned a 4-octet AS number may want the BGP
UPDATE messages they receive from their customers or peers to include UPDATE messages they receive from their customers or peers to include
a 4-octet AS specific extended community. This document defines a a 4-octet AS specific extended community. This document defines a
new sub-type within the four-octet AS specific extended community to new sub-type within the four-octet AS specific extended community to
facilitate this practice. facilitate this practice.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 January 27, 2011. This Internet-Draft will expire on April 22, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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
skipping to change at page 4, line 34 skipping to change at page 4, line 34
Local Administrator sub-field: 2 octets Local Administrator sub-field: 2 octets
This sub-field contains a value that can influence routing This sub-field contains a value that can influence routing
policies. This value has semantics that are of significance for policies. This value has semantics that are of significance for
the Autonomous System in the Global Administrator field. the Autonomous System in the Global Administrator field.
3. Deployment Considerations 3. Deployment Considerations
There are situations in peering where a 4-octet AS specific generic There are situations in peering where a 4-octet AS specific generic
extended community cannot be used. A speaker with a 4-octet AS may extended community cannot be used.
not support 4-octet extended communities; or the speaker may have a
customer or peer that does not support 4-octet extended communities.
In all such cases, the speaker may need to define an appropriate
standard community value for the same purpose. As an example, a peer
may tag its routes with communities that encode AS_TRANS [RFC4893] as
the first two octets.
Similarly, a 2-octet AS number may have two valid representations as A speaker with a 4-octet AS may not support 4-octet extended
either a standard community or a 4-octet extended community with the communities; or the speaker may have a customer or peer that does not
upper two octets of the AS number set to zero. For backward support 4-octet extended communities. In all such cases, the speaker
compatibility with existing deployments, and to avoid inconsistencies may need to define an appropriate standard community value for the
between standard communities and 4-octet extended communities, two- same purpose. As an example, a peer may tag its routes with a
octet ASes SHOULD use standard 2-octet communities as defined in RFC community that encodes AS_TRANS [RFC4893] as the first two octets.
1997 rather than the 4-octet AS specific community as defined in this
document. Similarly, as per [RFC4893], a 2-octet Autonomous System number can
be converted into a 4-octet Autonomous System number by setting the
two high-order octets of the 4-octet field to zero. As a
consequence, at least in principle, an Autonomous System that has a
2-octet AS number could use either a standard community or the
4-octet AS specific generic extended community. This is undesirable,
as they would be treated as different communities, even if they had
the same values.
Therefore, for backward compatibility with existing deployments and
to avoid inconsistencies between standard communities and 4-octet
extended communities, Autonomous Systems that use 2-octet Autonomous
System numbers SHOULD use standard 2-octet communities as defined in
RFC1997 rather than the 4-octet AS specific extended community as
defined in this document.
4. Acknowledgments 4. Acknowledgments
The authors would like to thank Paul Jakma, Bruno Decraene and Cayle The authors would like to thank Paul Jakma, Bruno Decraene and Cayle
Spandon for their useful comments on the document. Spandon for their useful comments on the document.
5. IANA Considerations 5. IANA Considerations
This document defines a specific application of the four-octet AS This document defines a specific application of the four-octet AS
specific extended community. IANA is requested to to assign a sub- specific extended community. IANA is requested to to assign a sub-
 End of changes. 6 change blocks. 
19 lines changed or deleted 27 lines changed or added

This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/