draft-ietf-idr-rfc4893bis-00.txt   draft-ietf-idr-rfc4893bis-01.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: October 18, 2009 April 17, 2009 Expiration Date: April 3, 2010 October 2, 2009
BGP Support for Four-octet AS Number Space BGP Support for Four-octet AS Number Space
draft-ietf-idr-rfc4893bis-00.txt draft-ietf-idr-rfc4893bis-01.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 October 18, 2009. This Internet-Draft will expire on April 3, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 10 skipping to change at page 2, line 10
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
entity in BGP [BGP]. To prepare for the anticipated exhaustion of entity in BGP [RFC4271]. To prepare for the anticipated exhaustion
the two-octet AS numbers, this document describes extensions to BGP of the two-octet AS numbers, this document describes extensions to
to carry the Autonomous System number as a four-octet entity. BGP to carry the Autonomous System number as a four-octet entity.
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.
skipping to change at page 5, line 15 skipping to change at page 5, line 15
octet AS numbers only. In this case, the NEW speaker MUST NOT send octet AS numbers only. In this case, the NEW speaker MUST NOT send
the AS4_PATH attribute. the AS4_PATH attribute.
In the AS_PATH attribute encoded with 2-octet AS numbers, non- In the AS_PATH attribute encoded with 2-octet AS numbers, non-
mappable 4-octet AS numbers are represented by the well-known 2-octet mappable 4-octet AS numbers are represented by the well-known 2-octet
AS number, AS_TRANS. This will preserve the path length property of AS number, AS_TRANS. This will preserve the path length property of
the AS path information and also help in updating the AS path the AS path information and also help in updating the AS path
information received on a NEW BGP speaker from an OLD speaker, as information received on a NEW BGP speaker from an OLD speaker, as
explained in the next section. explained in the next section.
The NEW speaker constructs the AS4_PATH attribute from the The NEW speaker constructs the AS4_PATH attribute from the AS path
information carried in the AS_PATH attribute. In the case where the information. In the case where the AS path information contains
AS_PATH attribute contains either AS_CONFED_SEQUENCE or AS_CONFED_SET either AS_CONFED_SEQUENCE or AS_CONFED_SET path segments, the NEW
path segments, the NEW speaker, when constructing the AS4_PATH speaker, when constructing the AS4_PATH attribute from the AS path
attribute from the AS_PATH attribute, MUST exclude such path information, MUST exclude such path segments. The AS4_PATH attribute
segments. The AS4_PATH attribute will be carried across a series of will be carried across a series of OLD BGP speakers without
OLD BGP speakers without modification and will help preserve the modification and will help preserve the non-mappable 4-octet AS
non-mappable 4-octet AS numbers in the AS path information. numbers in the AS path information.
Similarly, if the NEW speaker has to send the AGGREGATOR attribute, Similarly, if the NEW speaker has to send the AGGREGATOR attribute,
and if the aggregating Autonomous System's AS number is a non- and if the aggregating Autonomous System's AS number is a non-
mappable 4-octet AS number, then the speaker MUST use the mappable 4-octet AS number, then the speaker MUST use the
AS4_AGGREGATOR attribute, and set the AS number field in the existing AS4_AGGREGATOR attribute, and set the AS number field in the existing
AGGREGATOR attribute to the reserved AS number, AS_TRANS. Note that AGGREGATOR attribute to the reserved AS number, AS_TRANS. Note that
if the AS number is 2-octets only, then the AS4_AGGREGATOR attribute if the AS number is 2-octets only, then the AS4_AGGREGATOR attribute
MUST NOT be sent. MUST NOT be sent.
4.2.3. Processing Received Updates 4.2.3. Processing Received Updates
skipping to change at page 6, line 42 skipping to change at page 6, line 42
- the AS4_AGGREGATOR attribute SHALL be taken as the information - the AS4_AGGREGATOR attribute SHALL be taken as the information
about the aggregating node, and about the aggregating node, and
- the AS path information would need to be constructed, as in all - the AS path information would need to be constructed, as in all
other cases. other cases.
In order to construct the AS path information, it would be necessary In order to construct the AS path information, it would be necessary
to first calculate the number of AS numbers in the AS_PATH and to first calculate the number of AS numbers in the AS_PATH and
AS4_PATH attributes using the method specified in Section 9.1.2.2 AS4_PATH attributes using the method specified in Section 9.1.2.2
[BGP] and [RFC5065] for route selection. [RFC4271] and [RFC5065] for route selection.
If the number of AS numbers in the AS_PATH attribute is less than the If the number of AS numbers in the AS_PATH attribute is less than the
number of AS numbers in the AS4_PATH attribute, then the AS4_PATH number of AS numbers in the AS4_PATH attribute, then the AS4_PATH
attribute SHALL be ignored, and the AS_PATH attribute SHALL be taken attribute SHALL be ignored, and the AS_PATH attribute SHALL be taken
as the AS path information. as the AS path information.
If the number of AS numbers in the AS_PATH attribute is larger than If the number of AS numbers in the AS_PATH attribute is larger than
or equal to the number of AS numbers in the AS4_PATH attribute, then or equal to the number of AS numbers in the AS4_PATH attribute, then
the AS path information SHALL be constructed by taking as many AS the AS path information SHALL be constructed by taking as many AS
numbers and path segments as necessary from the leading part of the numbers and path segments as necessary from the leading part of the
skipping to change at page 7, line 22 skipping to change at page 7, line 22
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 [AS-EXT-COM] instead.
6. Error Handling 6. Error Handling
The general guidelines presented in [OPT-ATTR-E] apply to the error The general guidelines presented in [ATTR-ERROR] 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. In this section we also take into consideration the this document.
fact that these new attributes are neither sourced nor validated by
an OLD BGP speaker. 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
this document the "attribute discard" approach is chosen to handle a
malformed AS4_PATH attribute.
Similarly, as the AS4_AGGREGATOR is just informational, the
"attribute discard" approach is chosen to handle a malformed
AS4_AGGREGATOR attribute.
The AS4_PATH attribute and AS4_AGGREGATOR attribute MUST NOT be The AS4_PATH attribute and AS4_AGGREGATOR attribute MUST NOT be
carried in an UPDATE message between NEW BGP speakers. A NEW BGP carried in an UPDATE message between NEW BGP speakers. A NEW BGP
speaker that receives the AS4_PATH attribute or the AS4_AGGREGATOR speaker that receives the AS4_PATH attribute or the AS4_AGGREGATOR
attribute in an UPDATE message from another NEW BGP speaker MUST attribute in an UPDATE message from another NEW BGP speaker MUST
discard the path attribute and continue processing the UPDATE discard the path attribute and continue processing the UPDATE
message. This case SHOULD be logged locally for analysis. message. This case SHOULD be logged locally for analysis.
In addition, the path segment types AS_CONFED_SEQUENCE and In addition, the path segment types AS_CONFED_SEQUENCE and
AS_CONFED_SET [RFC5065] MUST NOT be carried in the AS4_PATH attribute AS_CONFED_SET [RFC5065] MUST NOT be carried in the AS4_PATH attribute
of an UPDATE message. A NEW BGP speaker that receives these path of an UPDATE message. A NEW BGP speaker that receives these path
segment types in the AS4_PATH attribute of an UPDATE message from an segment types in the AS4_PATH attribute of an UPDATE message from an
OLD BGP speaker MUST discard these path segments, adjust the relevant OLD BGP speaker MUST discard these path segments, adjust the relevant
attribute fields accordingly, and continue processing the UPDATE attribute fields accordingly, and continue processing the UPDATE
message. This case SHOULD be logged locally for analysis. message. This case SHOULD be logged locally for analysis.
The AS4_PATH attribute in an UPDATE message SHALL be considered The AS4_PATH attribute in an UPDATE message SHALL be considered
malformed under the following conditions: malformed under the following conditions:
- the attribute length is not a multiple of two, or is - the attribute length is not a multiple of two, or is too small
inconsistent with the "Total Path Attribute Length" in the (i.e., less than 6) for the attribute to carry at least one
UPDATE message, or AS number, or
- the path segment length in the attribute is either zero, or - the path segment length in the attribute is either zero, or
is inconsistent with the attribute length, or is inconsistent with the attribute length, or
- the path segment type in the attribute is not one of the - the path segment type in the attribute is not one of the
types defined: AS_SEQUENCE, AS_SET, AS_CONFED_SEQUENCE types defined: AS_SEQUENCE, AS_SET, AS_CONFED_SEQUENCE
and AS_CONFED_SET. and AS_CONFED_SET.
A NEW BGP speaker that receives a malformed AS4_PATH attribute in an A NEW BGP speaker that receives a malformed AS4_PATH attribute in an
UPDATE message from an OLD BGP speaker MUST discard the attribute, UPDATE message from an OLD BGP speaker MUST discard the attribute,
skipping to change at page 10, line 27 skipping to change at page 10, line 27
speakers within the confederation have transitioned to support 4- speakers within the confederation have transitioned to support 4-
octet AS numbers. Such a misconfiguration would weaken the AS path octet AS numbers. Such a misconfiguration would weaken the AS path
loop detection within a confederation. loop detection within a confederation.
10. Acknowledgments 10. Acknowledgments
The authors would like to thank Yakov Rekhter, Chaitanya Kodeboyina, The authors would like to thank Yakov Rekhter, Chaitanya Kodeboyina,
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
for their review and comments.
11. References 11. References
11.1. Normative References 11.1. Normative References
[BGP] 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
skipping to change at page 11, line 11 skipping to change at page 11, line 11
[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 [AS-EXT-COM] Rekhter, Y., Ramachandra, S., and D. Tappan, "Four-octet
AS Specific BGP Extended Community", Work in Progress, AS Specific BGP Extended Community", Work in Progress,
November 2008. November 2008.
[OPT-ATTR-E] Scudder, J. and E. Chen, "Error Handling for Optional [ATTR-ERROR] Scudder, J. and E. Chen, "Error Handling for Optional
Transitive BGP Attributes", Work in Progress, April Transitive BGP Attributes", Work in Progress, April
2009. 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
 End of changes. 12 change blocks. 
24 lines changed or deleted 34 lines changed or added

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