draft-ietf-idr-as4bytes-08.txt   draft-ietf-idr-as4bytes-09.txt 

Network Working Group Quaizar Vohra Network Working Group Quaizar Vohra
Internet Draft Juniper Networks Internet Draft Juniper Networks
Expiration Date: September 2004 Enke Chen Expiration Date: June 2005 Enke Chen
Network Working Group Redback Networks, Inc. Cisco Systems
BGP support for four-octet AS number space BGP support for four-octet AS number space
draft-ietf-idr-as4bytes-08.txt draft-ietf-idr-as4bytes-09.txt
1. Status of this Memo 1. Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668.
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
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.
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".
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
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.
2. Abstract 2. Abstract
Currently the Autonomous System number is encoded in BGP [BGP] as a Currently the Autonomous System number is encoded in BGP [BGP] as a
two-octets field. This document describes extensions to BGP to carry two-octets field. This document describes extensions to BGP to carry
the Autonomous System number as a four-octets field. the Autonomous System number as a four-octets field.
3. Protocol Extensions 3. Specification of Requirements
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 [RFC2119].
4. Protocol Extensions
For the purpose of this document lets define a BGP speaker which For the purpose of this document lets define a BGP speaker which
doesn't support the new 4-octets AS number extensions as an OLD BGP doesnt support the new 4-octets AS number extensions as an OLD BGP
speaker, and a BGP speaker which supports the new 4-octets AS number speaker, and a BGP speaker which supports the new 4-octets AS number
extensions as a NEW BGP speaker. extensions as a NEW BGP speaker.
BGP carries the Autonomous System number in the My Autonomous System BGP carries the Autonomous System number in the My Autonomous System
field of the OPEN message, in the AS_PATH attribute of the UPDATE field of the OPEN message, in the AS_PATH attribute of the UPDATE
message, and in the AGGREGATOR attribute of the UPDATE message. BGP message, and in the AGGREGATOR attribute of the UPDATE message. BGP
also carries the Autonomous System number in the BGP Communities also carries the Autonomous System number in the BGP Communities
attribute. attribute.
A NEW BGP speaker uses BGP Capability Advertisements [RFC2842] to A NEW BGP speaker uses BGP Capability Advertisements [RFC2842] to
skipping to change at page 3, line 16 skipping to change at page 3, line 30
into 4-octets Autonomous System numbers by setting the high-order 2 into 4-octets Autonomous System numbers by setting the high-order 2
octets of the 4-octets field to zero. Such a 4-octets AS number is octets of the 4-octets field to zero. Such a 4-octets AS number is
said to be mappable to a 2-octets AS number. said to be mappable to a 2-octets AS number.
To represent 4-octets AS numbers (which are not mapped from 2-octets) To represent 4-octets AS numbers (which are not mapped from 2-octets)
as 2-octets AS numbers in the AS path information encoded with as 2-octets AS numbers in the AS path information encoded with
2-octets AS numbers, this document reserves a 2-octets AS number. 2-octets AS numbers, this document reserves a 2-octets AS number.
Lets denote this special AS number as AS_TRANS for ease of Lets denote this special AS number as AS_TRANS for ease of
description in the rest of this specification. This AS number is also description in the rest of this specification. This AS number is also
placed in the My Autonomous System field of the OPEN message placed in the My Autonomous System field of the OPEN message
originated by a NEW BGP speaker if the speaker doesn't have a originated by a NEW BGP speaker if the speaker doesnt have a
(globally unique) 2-octets AS number. (globally unique) 2-octets AS number.
4. Operations 5. Operations
4.1. Interaction between NEW BGP speakers 5.1. Interaction between NEW BGP speakers
A BGP speaker that supports 4-octets Autonomous System numbers may A BGP speaker that supports 4-octets Autonomous System numbers may
advertise this to its peers using the BGP Capability Advertisements. advertise this to its peers using the BGP Capability Advertisements.
A BGP speaker that advertises such capability to a particular peer, A BGP speaker that advertises such capability to a particular peer,
and receives from that peer the advertisement of such capability MUST and receives from that peer the advertisement of such capability MUST
encode Autonomous System numbers as 4-octets entities in both the encode Autonomous System numbers as 4-octets entities in both the
AS_PATH and the AGGREGATOR attributes in the updates it sends to the AS_PATH and the AGGREGATOR attributes in the updates it sends to the
peer, and MUST assume that these attributes in the updates received peer, and MUST assume that these attributes in the updates received
from the peer encode Autonomous System numbers as 4-octets entities. from the peer encode Autonomous System numbers as 4-octets entities.
The new attributes, NEW_AS_PATH and NEW_AGGREGATOR should not be The new attributes, NEW_AS_PATH and NEW_AGGREGATOR should not be
carried in the UPDATE messages between NEW BGP peers. A NEW BGP carried in the UPDATE messages between NEW BGP peers. A NEW BGP
speaker that receives the NEW_AS_PATH and NEW_AGGREGATOR path speaker that receives the NEW_AS_PATH and NEW_AGGREGATOR path
attributes in an UPDATE message from a NEW BGP speaker should discard attributes in an UPDATE message from a NEW BGP speaker should discard
these path attributes and continue processing the UPDATE message. these path attributes and continue processing the UPDATE message.
4.2. Interaction between NEW and OLD BGP speaker 5.2. Interaction between NEW and OLD BGP speaker
4.2.1. BGP Peering 5.2.1. BGP Peering
Note that peering between a NEW BGP speaker and an OLD one is Note that peering between a NEW BGP speaker and an OLD one is
possible only if the NEW BGP speaker has a 2-octets AS number. possible only if the NEW BGP speaker has a 2-octets AS number.
However, this document doesn't assume that an Autonomous System with However, this document doesnt assume that an Autonomous System with
NEW speakers has to have a globally unique 2-octets AS number - NEW speakers has to have a globally unique 2-octets AS number -
AS_TRANS could be used instead (even if multiple Autonomous System AS_TRANS could be used instead (even if multiple Autonomous System
would use it). would use it).
4.2.2. Generating Updates 5.2.2. Generating Updates
When communicating with an OLD BGP speaker, a NEW speaker MUST send When communicating with an OLD BGP speaker, a NEW speaker MUST send
the AS path information in the AS_PATH attribute encoded with the AS path information in the AS_PATH attribute encoded with
2-octets AS numbers. The NEW speaker also MUST send the AS path 2-octets AS numbers. The NEW speaker also MUST send the AS path
information in the NEW_AS_PATH attribute (encoded with 4-octets AS information in the NEW_AS_PATH attribute (encoded with 4-octets AS
numbers), except for the case where the entire AS path information is numbers), except for the case where the entire AS path information is
composed of 2-octets AS numbers only. In this case the NEW speaker composed of 2-octets AS numbers only. In this case the NEW speaker
should not send the NEW_AS_PATH attribute. should not send the NEW_AS_PATH attribute.
In the AS_PATH attribute encoded with 2-octets AS numbers, non- In the AS_PATH attribute encoded with 2-octets AS numbers, non-
skipping to change at page 4, line 32 skipping to change at page 4, line 45
The NEW speaker constructs the NEW_AS_PATH attribute from the The NEW speaker constructs the NEW_AS_PATH attribute from the
information carried in the AS_PATH attribute. In the case where the information carried in the AS_PATH attribute. In the case where the
AS_PATH attribute contains either AS_CONFED_SEQUENCE or AS_CONFED_SET AS_PATH attribute contains either AS_CONFED_SEQUENCE or AS_CONFED_SET
path segments, the NEW speaker, when constructing the NEW_AS_PATH path segments, the NEW speaker, when constructing the NEW_AS_PATH
attribute from the AS_PATH attribute, must exclude such path attribute from the AS_PATH attribute, must exclude such path
segments. The NEW_AS_PATH attribute will be carried across a series segments. The NEW_AS_PATH attribute will be carried across a series
of OLD BGP speakers without modification and will help preserve the of OLD BGP speakers without modification and will help preserve the
truely 4-octets AS numbers in the AS path information. truely 4-octets AS 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 truely and if the aggregating Autonomous Systems AS number is truely
4-octets, the speaker constructs the NEW_AGGREGATOR attributes by 4-octets, the speaker constructs the NEW_AGGREGATOR attributes by
taking the attribute length and attribute value from the AGGREGATOR taking the attribute length and attribute value from the AGGREGATOR
attribute and placing them into the attribute length and attribute attribute and placing them into the attribute length and attribute
value of the NEW_AGGREGATOR attribute, and sets the AS number field value of the NEW_AGGREGATOR attribute, and sets the AS number field
in the existing AGGREGATOR attribute to the reserved AS number, in the existing AGGREGATOR attribute to the reserved AS number,
AS_TRANS. Note that if the AS number is 2-octets only, then the AS_TRANS. Note that if the AS number is 2-octets only, then the
NEW_AGGREGATE attribute should not be sent. NEW_AGGREGATE attribute should not be sent.
4.2.3. Processing Received Updates 5.2.3. Processing Received Updates
When a NEW BGP speaker receives an update from an OLD one, it should When a NEW BGP speaker receives an update from an OLD one, it should
be prepared to receive the NEW_AS_PATH attribute along with the be prepared to receive the NEW_AS_PATH attribute along with the
existing AS_PATH attribute. If NEW_AS_PATH attribute is also existing AS_PATH attribute. If NEW_AS_PATH attribute is also
received, both the attributes will be used to construct the exact AS received, both the attributes will be used to construct the exact AS
path information, and therefore the information carried by both the path information, and therefore the information carried by both the
attributes will be considered for AS path loop detection. attributes will be considered for AS path loop detection.
Note that a route may have traversed a series of autonomous systems Note that a route may have traversed a series of autonomous systems
with 2-octets AS numbers and OLD BGP speakers only. In that case, if with 2-octets AS numbers and OLD BGP speakers only. In that case, if
skipping to change at page 5, line 17 skipping to change at page 5, line 33
2-octets AS numbers and OLD BGP speakers only) is contained only in 2-octets AS numbers and OLD BGP speakers only) is contained only in
the current AS_PATH attribute (encoded in the leading part of the the current AS_PATH attribute (encoded in the leading part of the
AS_PATH attribute). This AS path information should be prepended to AS_PATH attribute). This AS path information should be prepended to
the NEW_AS_PATH attribute to construct the exact AS path information. the NEW_AS_PATH attribute to construct the exact AS path information.
Similarly, a NEW BGP speaker should be prepared to receive the Similarly, a NEW BGP speaker should be prepared to receive the
NEW_AGGREGATOR attribute from an OLD BGP speaker. In that case, the NEW_AGGREGATOR attribute from an OLD BGP speaker. In that case, the
AGGREGATOR attribute is ignored and the NEW_AGGREGATOR contains the AGGREGATOR attribute is ignored and the NEW_AGGREGATOR contains the
exact information about the aggregating node. exact information about the aggregating node.
4.3. Interaction between OLD BGP speakers 5.3. Interaction between OLD BGP speakers
In all other cases the speaker MUST encode Autonomous System numbers In all other cases the speaker MUST encode Autonomous System numbers
as 2-octets entities in both the AS_PATH and the AGGREGATOR attribute as 2-octets entities in both the AS_PATH and the AGGREGATOR attribute
in the updates it sends to the peer, and MUST assume that these in the updates it sends to the peer, and MUST assume that these
attributes in the updates received from the peer encoded Autonomous attributes in the updates received from the peer encoded Autonomous
System numbers as 2-octets entities. System numbers as 2-octets entities.
5. Handling BGP Communities 6. 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 routers that use 4-octets Autonomous System numbers. Such work for routers that use 4-octets Autonomous System numbers. Such
routers should use the Extended Communities [EXT-COMM] attribute routers should use the Extended Communities [EXT-COMM] attribute
instead. instead.
6. Transition 7. Transition
The scheme described in this document allows a gradual transition The scheme described in this document allows a gradual transition
from 2-octets AS numbers to 4-octets AS numbers. One can upgrade one from 2-octets AS numbers to 4-octets AS numbers. One can upgrade one
Autonomous system or one router at a time. Autonomous system or one router at a time.
To simplify transition this document assumes that an Autonomous To simplify transition this document assumes that an Autonomous
System could start using 4-octets AS number only after all the BGP System could start using 4-octets AS number only after all the BGP
speakers within that Autonomous System have been upgraded to support speakers within that Autonomous System have been upgraded to support
4-octets AS numbers. 4-octets AS numbers.
skipping to change at page 6, line 28 skipping to change at page 7, line 5
the NEW_AS_PATH attribute are aggregated by an OLD BGP speaker, and the NEW_AS_PATH attribute are aggregated by an OLD BGP speaker, and
the NEW_AS_PATH attribute of at least one of these routes carries at the NEW_AS_PATH attribute of at least one of these routes carries at
least one 4-octets AS number (as oppose to a 2-octets AS number that least one 4-octets AS number (as oppose to a 2-octets AS number that
is encoded in 4 octets). When such aggregation results in creating a is encoded in 4 octets). When such aggregation results in creating a
route that is less specific than any of the component routes, (route route that is less specific than any of the component routes, (route
whose NLRI covers NLRI of all the component routes), loss of the AS whose NLRI covers NLRI of all the component routes), loss of the AS
path information does not create a risk of a routing loop. In all path information does not create a risk of a routing loop. In all
other cases loss of the AS path information does create a risk of a other cases loss of the AS path information does create a risk of a
routing loop. routing loop.
7. IANA Consideration 8. IANA Consideration
This document uses a BGP Capability code to indicate that a BGP This document uses a BGP Capability code to indicate that a BGP
speaker supports the 4-octets AS numbers. The Capability code has speaker supports the 4-octets AS numbers. The Capability code has
been assigned by IANA per RFC 2842. been assigned by IANA per RFC 2842.
In addition, this document introduces two new BGP optional transitive In addition, this document introduces two new BGP optional transitive
attributes. The first is the NEW_AS_PATH attribute, which preserves attributes. The first is the NEW_AS_PATH attribute, which preserves
the AS path information with 4-octet AS numbers across old BGP the AS path information with 4-octet AS numbers across old BGP
speakers. The second is the NEW_AGGREGATOR attribute, which is speakers. The second is the NEW_AGGREGATOR attribute, which is
similar in use to the current AGGREGATOR attribute but it carries similar in use to the current AGGREGATOR attribute but it carries
4-octet AS numbers. The Type Codes for these attributes has been 4-octet AS numbers. The Type Codes for these attributes has been
assigned by IANA. assigned by IANA.
Finally, this document introduces a reserved 2-octets AS number - Finally, this document introduces a reserved 2-octets AS number -
AS_TRANS. The AS number for AS_TRANS has been assigned by the IANA. AS_TRANS. The AS number for AS_TRANS has been assigned by the IANA.
8. Security Considerations 9. Security Considerations
Security issues are not discussed in this document. Security issues are not discussed in this document.
9. 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 which went into the and Jeffrey Haas for the numerous discussions which went into the
making of this draft. making of this draft.
10. References 11. References
[BGP] Rekhter, Y., Li, T., "Border Gateway Protocol 4", draft-ietf- [BGP] Rekhter, Y., Li, T., and Hares, S., "A Border Gateway Protocol
idr-bgp4-12.txt 4 (BGP-4)", draft-ietf-idr-bgp4-26.txt, October 2004.
[EXT-COM] Ramachandra, S., Tappan, D., and Rekter Y. "BGP Extended [EXT-COM] Ramachandra, S., Tappan, D., and Rekter Y. "BGP Extended
Communities Attribute", draft-ramachandra-bgp-ext-communities-02.txt Communities Attribute", draft-ramachandra-bgp-ext-communities-07.txt,
March 2004.
[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.
[RFC2842] Chandra, R., and Scudder, J., "Capabilities Advertisement [RFC2842] Chandra, R., and Scudder, J., "Capabilities Advertisement
with BGP-4", RFC 2842, May 2000. with BGP-4", RFC 2842, May 2000.
[RFC3065] Traina, P., McPherson, D., Scudder, J., "Autonomous System [RFC3065] Traina, P., McPherson, D., Scudder, J., "Autonomous System
Confederations for BGP", RFC3065, February 2001. Confederations for BGP", RFC3065, February 2001.
11. Author Information [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
12. Author Information
Quaizar Vohra Quaizar Vohra
Juniper Networks Juniper Networks
1194 N.Mathilda Ave 1194 N.Mathilda Ave
Sunnyvale, CA 94089 Sunnyvale, CA 94089
e-mail: qv@juniper.net e-mail: qv@juniper.net
Enke Chen Enke Chen
Redback Networks, Inc. Cisco Systems, Inc.
350 Holger Way e-mail: enkechen@cisco.com
San Jose, CA 95134
e-mail: enke@redback.com 13. Intellectual Property Considerations
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
14. Full Copyright Notice
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/