draft-ietf-idr-rfc4893bis-01.txt   draft-ietf-idr-rfc4893bis-02.txt 
Network Working Group Q. Vohra Network Working Group Q. Vohra
Internet Draft Juniper Networks Internet Draft Juniper Networks
Obsoletes: 4893 (if approved) E. Chen Obsoletes: 4893 (if approved) E. Chen
Intended Status: Standards Track Cisco Systems Intended Status: Standards Track Cisco Systems
Expiration Date: April 3, 2010 October 2, 2009 Expiration Date: October 6, 2010 April 5, 2010
BGP Support for Four-octet AS Number Space BGP Support for Four-octet AS Number Space
draft-ietf-idr-rfc4893bis-01.txt draft-ietf-idr-rfc4893bis-02.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 33 skipping to change at page 1, line 33
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on April 3, 2010. This Internet-Draft will expire on October 6, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. 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.
Abstract Abstract
Currently the Autonomous System (AS) number is encoded as a two-octet Currently the Autonomous System (AS) number is encoded as a two-octet
entity in BGP. This document describes extensions to BGP to carry the entity in BGP. This document describes extensions to BGP to carry the
Autonomous System number as a four-octet entity. Autonomous System number as a four-octet entity.
1. Introduction 1. Introduction
Currently the Autonomous System number is encoded as a two-octet Currently the Autonomous System number is encoded as a two-octet
skipping to change at page 2, line 23 skipping to change at page 2, line 27
More specifically, this document defines a new BGP capability, Four- More specifically, this document defines a new BGP capability, Four-
octet AS Number Capability, that can be used by a BGP speaker to octet AS Number Capability, that can be used by a BGP speaker to
indicate its support for the four-octet AS numbers. Two new indicate its support for the four-octet AS numbers. Two new
attributes, AS4_PATH and AS4_AGGREGATOR, are introduced that can be attributes, AS4_PATH and AS4_AGGREGATOR, are introduced that can be
used to propagate four-octet based AS path information across BGP used to propagate four-octet based AS path information across BGP
speakers that do not support the four-octet AS numbers. This speakers that do not support the four-octet AS numbers. This
document also specifies mechanisms for constructing the AS path document also specifies mechanisms for constructing the AS path
information from the AS_PATH attribute and the AS4_PATH attribute. information from the AS_PATH attribute and the AS4_PATH attribute.
The extensions proposed in this document allow a gradual transition The extensions specified in this document allow a gradual transition
from 2-octet AS numbers to 4-octet AS numbers. from 2-octet AS numbers to 4-octet AS numbers.
2. Specification of Requirements 2. Specification of Requirements
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 [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Protocol Extensions 3. Protocol Extensions
skipping to change at page 7, line 18 skipping to change at page 7, line 18
AS_CONFED_SET path segment SHALL be prepended if it is either the AS_CONFED_SET path segment SHALL be prepended if it is either the
leading path segment or adjacent to a path segment that is prepended. leading path segment or adjacent to a path segment that is prepended.
5. Handling BGP Communities 5. Handling BGP Communities
As specified in [RFC1997], when the high-order two-octets of the As specified in [RFC1997], when the high-order two-octets of the
community attribute is neither 0x0000 nor 0xffff, these two octets community attribute is neither 0x0000 nor 0xffff, these two octets
encode the Autonomous System number. Quite clearly this would not encode the Autonomous System number. Quite clearly this would not
work for a NEW BGP speaker with a non-mappable 4-octet AS number. work for a NEW BGP speaker with a non-mappable 4-octet AS number.
Such BGP speakers should use the Four-octet AS Specific Extended Such BGP speakers should use the Four-octet AS Specific Extended
Communities [AS-EXT-COM] instead. Communities [RFC5668] instead.
6. Error Handling 6. Error Handling
The general guidelines presented in [ATTR-ERROR] apply to the error The general guidelines presented in [OPT-TRANS] apply to the error
handling of the AS4_PATH and AS4_AGGREGATOR attributes introduced in handling of the AS4_PATH and AS4_AGGREGATOR attributes introduced in
this document. this document. It is noted, however, that the nature (i.e., NEW
speaker or OLD speaker) of a direct neighbor based on the
announcement of the 4-octet AS Capability allows a local speaker to
determine unequivocally whether the direct neighbor recognizes these
new attributes. Thus there is no need to examine the the attribute
flags (somewhat weaker indicator in this case) for that
determination.
Given that the two-octet AS numbers dominate during the transition, Given that the two-octet AS numbers dominate during the transition,
and are carried in the AS_PATH attribute by an OLD BGP speaker, in and are carried in the AS_PATH attribute by an OLD BGP speaker, in
this document the "attribute discard" approach is chosen to handle a this document the "attribute discard" approach is chosen to handle a
malformed AS4_PATH attribute. malformed AS4_PATH attribute.
Similarly, as the AS4_AGGREGATOR is just informational, the Similarly, as the AS4_AGGREGATOR is just informational, the
"attribute discard" approach is chosen to handle a malformed "attribute discard" approach is chosen to handle a malformed
AS4_AGGREGATOR attribute. AS4_AGGREGATOR attribute.
skipping to change at page 10, line 34 skipping to change at page 10, line 35
and Jeffrey Haas for the numerous discussions that went into the and Jeffrey Haas for the numerous discussions that went into the
making of this document. making of this document.
The authors would also like to thank members of the IDR Working Group The authors would also like to thank members of the IDR Working Group
for their review and comments. for their review and comments.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271, January Border Gateway Protocol 4 (BGP-4)", RFC 4271, January
2006. 2006.
[RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities [RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities
Attribute", RFC 1997, August 1996. Attribute", RFC 1997, August 1996.
[RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement
with BGP-4", RFC 5492, February 2009. with BGP-4", RFC 5492, February 2009.
[RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous [RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous
System Confederations for BGP", RFC 5065, August 2007. System Confederations for BGP", RFC 5065, August 2007.
[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.
11.2. Informative References 11.2. Informative References
[AS-EXT-COM] Rekhter, Y., Ramachandra, S., and D. Tappan, "Four-octet [RFC5668] Rekhter, Y., Ramachandra, S., and D. Tappan, "4-Octet AS
AS Specific BGP Extended Community", Work in Progress, Specific BGP Extended Community", RFC 5668, October 2009.
November 2008.
[ATTR-ERROR] Scudder, J. and E. Chen, "Error Handling for Optional [OPT-TRANS] Scudder, J. and E. Chen, "Error Handling for Optional
Transitive BGP Attributes", Work in Progress, April Transitive BGP Attributes", Work in Progress, March 2010.
2009.
Appendix A. Comparison with RFC 4893 Appendix A. Comparison with RFC 4893
This document includes several minor editorial changes, and specifies This document includes several minor editorial changes, and specifies
the error handling for the new attributes. the error handling for the new attributes.
12. Authors' Addresses 12. Authors' Addresses
Quaizar Vohra Quaizar Vohra
Juniper Networks Juniper Networks
 End of changes. 16 change blocks. 
30 lines changed or deleted 38 lines changed or added

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