Internet DRAFT - draft-hares-deprecate-atomic-aggregate
draft-hares-deprecate-atomic-aggregate
IDR S. Hares
Internet-Draft Huawei
Updates: 4271 (if approved) March 13, 2017
Intended status: Standards Track
Expires: September 14, 2017
Decprecate Atomic Aggregate
draft-hares-deprecate-atomic-aggregate-00.txt
Abstract
This document deprecates the support for the BGP well-know
discretionary attribute ATOMIC_AGGREGATE specified in RFC4271. It
proposes the changes to RFC4271 to remove its support.
Requirements Language
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].
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 14, 2017.
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
Hares Expires September 14, 2017 [Page 1]
Internet-Draft Deprecate Atomic Aggregate March 2017
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Changes to Section 4.3 . . . . . . . . . . . . . . . . . . . 2
3. Changes to Section 5 - Path Attributes . . . . . . . . . . . 3
4. Changes to Section 9 . . . . . . . . . . . . . . . . . . . . 3
4.1. Changes to section 9.1.4 . . . . . . . . . . . . . . . . 3
4.2. Section 9.2 Changes . . . . . . . . . . . . . . . . . . . 4
5. Operational Considerations . . . . . . . . . . . . . . . . . 4
6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 4
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
8. Security Considerations . . . . . . . . . . . . . . . . . . . 4
9. Normative References . . . . . . . . . . . . . . . . . . . . 5
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction
The ATOMIC_AGGREGATE well-known discretionary attribute is specified
in [RFC4271] in section 5.1.6. This document specifies the changes
to RFC4271 in order to remove the ATOMIC_AGGREGATE attribute.
2. Changes to Section 4.3
delete the following text:
Hares Expires September 14, 2017 [Page 2]
Internet-Draft Deprecate Atomic Aggregate March 2017
f) ATOMIC_AGGREGATE (Type Code 6)
ATOMIC_AGGREGATE is a well-known discretionary attribute of
length 0.
Usage of this attribute is defined in 5.1.6.
3. Changes to Section 5 - Path Attributes
1: Section 5.0 should have the following changes (p. 24)
Old:
attribute EBGP IBGP
ORIGIN mandatory mandatory
AS_PATH mandatory mandatory
NEXT_HOP mandatory mandatory
MULTI_EXIT_DISC discretionary discretionary
LOCAL_PREF see Section 5.1.5 required
ATOMIC_AGGREGATE see Section 5.1.6 and 9.1.4
AGGREGATOR discretionary discretionary
New:
attribute EBGP IBGP
ORIGIN mandatory mandatory
AS_PATH mandatory mandatory
NEXT_HOP mandatory mandatory
MULTI_EXIT_DISC discretionary discretionary
LOCAL_PREF see Section 5.1.5 required
AGGREGATOR discretionary discretionary
2: Delete Section 5.1.6
4. Changes to Section 9
4.1. Changes to section 9.1.4
3: Changes to section 9.1.4
Old:
If a BGP speaker chooses to aggregate, then it SHOULD either include
all ASes used to form the aggregate in an AS_SET, or add the
ATOMIC_AGGREGATE attribute to the route.
New
Hares Expires September 14, 2017 [Page 3]
Internet-Draft Deprecate Atomic Aggregate March 2017
If a BGP speaker chooses to aggregate, then it SHOULD either include
all ASes used to form the aggregate in an AS_SET.
delete the following text:
"In particular, a route that carries the ATOMIC_AGGREGATE attribute
MUST NOT be de-aggregated."
4.2. Section 9.2 Changes
Text to delete:
ATOMIC_AGGREGATE:
If at least one of the routes to be aggregated has
ATOMIC_AGGREGATE path attribute, then the aggregated route
SHALL have this attribute as well.
5. Operational Considerations
Input needed here.
6. Error Handling
An ATOMIC_AGGREGATE attribute received should be silently ignored.
7. IANA Considerations
IANA Is asked to deprecate the BGP Attribute: Atomic_Aggregate with
this document as reference.
8. Security Considerations
Deprecating a BGP attribute does not change the BGP messages sent on
over a secure transport.
Users of this mechanism should be aware that unless a transport that
provides integrity (such as TCP-AO [RFC5925]) is used for the BGP
session in question, BGP Attributes can be forged. This could become
an attack vector.
Unless a transport that provides confidentiality (such as IPSec
[RFC4303]) is used, BGP attributes Communication messages could be
snooped by an attacker allowing access to BGP attributes. These
issues are common to any BGP message but may be of greater interest
in the context of this proposal since a BGP Attribute is being
deleted.
Hares Expires September 14, 2017 [Page 4]
Internet-Draft Deprecate Atomic Aggregate March 2017
9. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006,
<http://www.rfc-editor.org/info/rfc4271>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005,
<http://www.rfc-editor.org/info/rfc4303>.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
June 2010, <http://www.rfc-editor.org/info/rfc5925>.
Appendix A. Acknowledgements
The author would like to gratefully acknowledge the IDR WG discussion
Author's Address
Susan Hares
Huawei
7453 Hickory Hill
Saline, MI 48176
USA
Email: shares@ndzh.com
Hares Expires September 14, 2017 [Page 5]
