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

Network Working Group Quaizar Vohra Network Working Group Quaizar Vohra
Internet Draft Juniper Networks Internet Draft Juniper Networks
Expiration Date: June 2005 Enke Chen Expiration Date: January 2006 Enke Chen
Cisco Systems Cisco Systems
BGP support for four-octet AS number space BGP support for four-octet AS number space
draft-ietf-idr-as4bytes-09.txt draft-ietf-idr-as4bytes-10.txt
1. Status of this Memo 1. Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, each author represents that any
patent or other IPR claims of which I am aware have been disclosed, applicable patent or other IPR claims of which he or she is aware
or will be disclosed, and any of which I become aware will be have been or will be disclosed, and any of which he or she becomes
disclosed, in accordance with RFC 3668. aware will be disclosed, in accordance with Section 6 of BCP 79.
This document is an Internet-Draft and is in full conformance with
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
skipping to change at page 2, line 20 skipping to change at page 2, line 14
3. Specification of Requirements 3. 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].
4. Protocol Extensions 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
doesnt 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 30 skipping to change at page 3, line 23
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 doesnt 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.
5. Operations 5. Operations
5.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
skipping to change at page 4, line 13 skipping to change at page 4, line 11
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.
5.2. Interaction between NEW and OLD BGP speaker 5.2. Interaction between NEW and OLD BGP speaker
5.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 doesnt 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).
5.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
skipping to change at page 4, line 45 skipping to change at page 4, line 43
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 Systems 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.
5.2.3. Processing Received Updates 5.2.3. Processing Received Updates
skipping to change at page 7, line 38 skipping to change at page 7, line 38
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.
11. References 11. References
[BGP] Rekhter, Y., Li, T., and Hares, S., "A Border Gateway Protocol [BGP] Rekhter, Y., Li, T., and Hares, S., "A Border Gateway Protocol
4 (BGP-4)", draft-ietf-idr-bgp4-26.txt, October 2004. 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-07.txt, Communities Attribute", draft-ramachandra-bgp-ext-communities-09.txt,
March 2004. July 2005.
[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.
skipping to change at page 8, line 18 skipping to change at page 8, line 18
12. Author Information 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
Cisco Systems, Inc. Cisco Systems, Inc.
170 W. Tasman Dr.
San Jose, CA 95134
e-mail: enkechen@cisco.com e-mail: enkechen@cisco.com
13. Intellectual Property Considerations 13. Intellectual Property Considerations
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
skipping to change at page 9, line 7 skipping to change at page 9, line 7
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at ietf-
ipr@ietf.org. ipr@ietf.org.
14. Full Copyright Notice 14. Full Copyright Notice
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2005).
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. 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 This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 

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