draft-ietf-idr-deprecate-as-sets-00.txt   draft-ietf-idr-deprecate-as-sets-01.txt 
Network Working Group W. Kumari Network Working Group W. Kumari
Internet-Draft Google, Inc. Internet-Draft Google, Inc.
Intended status: Informational November 18, 2010 Intended status: Informational December 29, 2010
Expires: May 22, 2011 Expires: July 2, 2011
Deprecation of BGP AS_SET, AS_CONFED_SET. Deprecation of BGP AS_SET, AS_CONFED_SET.
draft-ietf-idr-deprecate-as-sets-00.txt draft-ietf-idr-deprecate-as-sets-01.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. the originator of a route more clear. This will also simpify the
design, implementation and deployment of onging work in the Secure
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 May 22, 2011. This Internet-Draft will expire on July 2, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 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 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
skipping to change at page 2, line 15 skipping to change at page 2, line 16
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements notation . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements notation . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Deployment and modification of behavior . . . . . . . . . . . . 3 4. Deployment and modification of behavior . . . . . . . . . . . . 3
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 4 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 4
8. Normative References . . . . . . . . . . . . . . . . . . . . . 4 8. Normative References . . . . . . . . . . . . . . . . . . . . . 4
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 4 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
local confederation that the update has traversed (AS_CONFED_SETs are local confederation that the update has traversed (AS_CONFED_SETs are
skipping to change at page 3, line 26 skipping to change at page 3, line 26
By performing aggregation, a router is, in essence, combining By performing aggregation, a router is, in essence, combining
multiple routes into a new route. This type of aggregation blurs the multiple routes into a new route. This type of aggregation blurs the
semantics of what it means to originate a route. These can cause semantics of what it means to originate a route. These can cause
operational issues that include reachability problems and traffic operational issues that include reachability problems and traffic
engineering issues. engineering issues.
From analysis of past Internet routing data it is apparent that From analysis of past Internet routing data it is apparent that
aggregation that involves AS_SETs is very seldom used in practice on aggregation that involves AS_SETs is very seldom used in practice on
the public network and, when it is, often contains reserved AS the public network and, when it is, often contains reserved AS
numbers ([RFC1930]) and / or only a single AS in the AS_SET. The numbers ([RFC1930]) and / or only a single AS in the AS_SET. The
reductions 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. Terminology
Deprecate: To mark (a component of a software standard) as obsolete Deprecate: To advise against the use of a feature or function.
to warn against its use in the future so that it may be phased Typically done before the removal of the feature or function
out. from a product.
4. Deployment and modification of behavior 4. Deployment and modification of behavior
It is expected that initially AS_SETs / AS_CONFED_SETs will be Operators who are currently announcing routes containing AS_SETs or
deprecated by the few operators that are currently generating them, AS_CONFED_SETs are advised to investigate why they are doing so and
and operator policy changed to filter them. Operators should take withdraw these announcements (and possibly reannounce the network
note that new technologies (such as those that make use of the RPKI) without the aggregation). As with any change, the operator should
MAY not support routes with AS_SETs / AS_CONFED_SETs in them, and MAY understand the full implications of the change.
treat as infeasible routes containing them.
It is worth noting that new technologies (such as those that take
advantage of the "X.509 Extensions for IP Addresses and AS
Identifiers" ([RFC3779]) MAY not support routes with AS_SETs /
AS_CONFED_SETs in them, and MAY treat as infeasible routes containing
them.
It is expected that, even before the deployment of these
technologies, operators may begin filtering routers that contain
AS_SETs or AS_CONFED_SETs.
5. IANA Considerations 5. IANA Considerations
This document contains no IANA considerations. This document contains no IANA considerations.
6. Security Considerations 6. 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 7. 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
skipping to change at page 4, line 38 skipping to change at page 4, line 48
8. Normative References 8. 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
Addresses and AS Identifiers", RFC 3779, June 2004.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006. Protocol 4 (BGP-4)", RFC 4271, January 2006.
[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.
Author's Address Author's Address
Warren Kumari Warren Kumari
Google, Inc. Google, Inc.
 End of changes. 10 change blocks. 
17 lines changed or deleted 31 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/