draft-ietf-idr-deprecate-as-sets-01.txt   draft-ietf-idr-deprecate-as-sets-02.txt 
Network Working Group W. Kumari Network Working Group W. Kumari
Internet-Draft Google, Inc. Internet-Draft Google, Inc.
Intended status: Informational December 29, 2010 Intended status: Informational January 16, 2011
Expires: July 2, 2011 Expires: July 20, 2011
Deprecation of BGP AS_SET, AS_CONFED_SET. Deprecation of BGP AS_SET, AS_CONFED_SET.
draft-ietf-idr-deprecate-as-sets-01.txt draft-ietf-idr-deprecate-as-sets-02.txt
Abstract Abstract
This document deprecates the use of the AS_SET and AS_CONFED_SET This document deprecates the use of the AS_SET and AS_CONFED_SET
types of the AS_PATH in BGPv4. This is done to simplify the design types of the AS_PATH in BGPv4. This is done to simplify the design
and implementation of the BGP protocol and to make the semantics of and implementation of the BGP protocol and to make the semantics of
the originator of a route more clear. This will also simpify the the originator of a route more clear. This will also simplify the
design, implementation and deployment of onging work in the Secure design, implementation and deployment of bonging work in the Secure
Inter-Domain Routing Working Group. Inter-Domain Routing Working Group.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted 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). 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 July 2, 2011. This Internet-Draft will expire on July 20, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements notation . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements notation . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Deployment and modification of behavior . . . . . . . . . . . . 3
4. Deployment and modification of behavior . . . . . . . . . . . . 3 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 4
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 4 7. Normative References . . . . . . . . . . . . . . . . . . . . . 4
8. Normative References . . . . . . . . . . . . . . . . . . . . . 4
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction 1. Introduction
The AS_SET path segment type of the AS_PATH attribute ([RFC4271], The AS_SET path segment type of the AS_PATH attribute ([RFC4271],
Section 4.3) is created by a router that is performing route Section 4.3) is created by a router that is performing route
aggregation and contains an unordered set of ASs that the update has aggregation and contains an unordered set of ASs that the update has
traversed. The AS_CONFED_SET path segment type ([RFC5065]) of the traversed. The AS_CONFED_SET path segment type ([RFC5065]) of the
AS_PATH attribute is created by a router that is performing route AS_PATH attribute is created by a router that is performing route
aggregation and contains an unordered set of Member AS Numbers in the aggregation and contains an unordered set of Member AS Numbers in the
skipping to change at page 3, line 36 skipping to change at page 3, line 36
reduction in table size provided by the aggregation is outweighed by reduction in table size provided by the aggregation is outweighed by
additional complexity in the BGP protocol and confusion regarding additional complexity in the BGP protocol and confusion regarding
what exactly is meant by originating a route. what exactly is meant by originating a route.
2. Requirements notation 2. Requirements notation
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. Terminology 3. Deployment and modification of behavior
Deprecate: To advise against the use of a feature or function.
Typically done before the removal of the feature or function
from a product.
4. Deployment and modification of behavior
Operators who are currently announcing routes containing AS_SETs or Operators are strongly advised to not generate any new announcements
AS_CONFED_SETs are advised to investigate why they are doing so and containing AS_SETs or AS_CONFED_SETs and to withdraw any existing
withdraw these announcements (and possibly reannounce the network routes containing them as soon as possible. As with any change, the
without the aggregation). As with any change, the operator should operator should understand the full implications of the change.
understand the full implications of the change.
It is worth noting that new technologies (such as those that take It is worth noting that new technologies (such as those that take
advantage of the "X.509 Extensions for IP Addresses and AS advantage of the "X.509 Extensions for IP Addresses and AS
Identifiers" ([RFC3779]) MAY not support routes with AS_SETs / Identifiers" ([RFC3779]) may not support routes with AS_SETs /
AS_CONFED_SETs in them, and MAY treat as infeasible routes containing AS_CONFED_SETs in them, and MAY treat as infeasible routes containing
them. them. Future BGP implementations may also do the same.
It is expected that, even before the deployment of these It is expected that, even before the deployment of these
technologies, operators may begin filtering routers that contain technologies, operators may begin filtering routers that contain
AS_SETs or AS_CONFED_SETs. AS_SETs or AS_CONFED_SETs.
5. IANA Considerations 4. IANA Considerations
This document contains no IANA considerations. This document contains no IANA considerations.
6. Security Considerations 5. Security Considerations
By removing support for the AS_SET path segment type of the AS_PATH By removing support for the AS_SET path segment type of the AS_PATH
attribute future BGP implementations can be simplified. This will attribute future BGP implementations can be simplified. This will
also simplify the design and implementation of the RPKI and systems also simplify the design and implementation of the RPKI and systems
that will rely on it. By removing corner cases we remove complexity that will rely on it. By removing corner cases we remove complexity
and code that is not exercised very often, which decreases the attack and code that is not exercised very often, which decreases the attack
surface. surface.
7. Acknowledgements 6. Acknowledgements
The author would like to thank Tony Li, Randy Bush, John Scudder, The author would like to thank Tony Li, Randy Bush, John Scudder,
Chris Morrow, Danny McPherson, Douglas Montgomery, Enke Chen, Florian Chris Morrow, Danny McPherson, Douglas Montgomery, Enke Chen, Florian
Weimer, Ilya Varlashkin, Jakob Heitz, John Leslie, Keyur Patel, Paul Weimer, Ilya Varlashkin, Jakob Heitz, John Leslie, Keyur Patel, Paul
Jakma, Rob Austein, Russ Housley, Sandra Murphy, Sriram Kotikalapudi, Jakma, Rob Austein, Russ Housley, Sandra Murphy, Sriram Kotikalapudi,
Steve Bellovin, Steve Kent, Steve Padgett, Alfred Hones, Tom Petch, Steve Bellovin, Steve Kent, Steve Padgett, Alfred Hones, Tom Petch,
everyone in IDR and everyone else who provided input. Alvaro Retana, everyone in IDR and everyone else who provided input.
Apologies to those who I may have missed, it was not intentional. Apologies to those who I may have missed, it was not intentional.
8. Normative References 7. Normative References
[RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation, [RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation,
selection, and registration of an Autonomous System (AS)", selection, and registration of an Autonomous System (AS)",
BCP 6, RFC 1930, March 1996. BCP 6, RFC 1930, March 1996.
[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.
[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
Addresses and AS Identifiers", RFC 3779, June 2004. Addresses and AS Identifiers", RFC 3779, June 2004.
 End of changes. 15 change blocks. 
32 lines changed or deleted 24 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/