Network Working Group P. Mohapatra Internet-Draft Cisco Systems Intended status: Standards Track J. Uttaro Expires: October 25, 2011 ATT April 23, 2011 One Administrative Domain Autonomous Systems in BGP draft-pmohapat-idr-oad-ebgp-00 Abstract The base BGP specification assumes routing across autonomous systems (inter-AS) to be across administrative domains. The definition of external BGP (EBGP) and external peering has been largely influenced by this fact to facilitate the inter-administration coordination. However there are deployments in which a single administration runs several contiguous BGP networks and ASes. In such cases, it can be desirable to modify and relax the rules for EBGP to provide more flexibility. This document discusses those rules. 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 October 25, 2011. Copyright Notice Copyright (c) 2011 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 carefully, as they describe your rights and restrictions with respect Mohapatra & Uttaro Expires October 25, 2011 [Page 1] Internet-Draft One Administrative Domain April 2011 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. Mohapatra & Uttaro Expires October 25, 2011 [Page 2] Internet-Draft One Administrative Domain April 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Path Attribute Usage . . . . . . . . . . . . . . . . . . . . . 5 3.1. LOCAL_PREF . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. NEXT_HOP . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.3. MULTI_EXIT_DISC (MED) . . . . . . . . . . . . . . . . . . . 6 3.4. Extended Community . . . . . . . . . . . . . . . . . . . . 6 3.5. ORIGINATOR_ID . . . . . . . . . . . . . . . . . . . . . . . 6 3.6. AIGP . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Route Flap Damping . . . . . . . . . . . . . . . . . . . . . . 7 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 9. Normative References . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Mohapatra & Uttaro Expires October 25, 2011 [Page 3] Internet-Draft One Administrative Domain April 2011 1. Introduction The base BGP specification [RFC4271] assumes routing across autonomous systems (inter-AS) to be across administrative domains. The definition of external BGP (EBGP) and external peering has been largely influenced by this fact to facilitate the inter- administration coordination. However there are deployments in which a single administration runs several contiguous BGP networks and ASes. In such cases, it can be desirable to modify and relax the rules for EBGP to provide more flexibility. This document discusses those rules. 1.1. 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 RFC 2119 [RFC2119]. 1.2. Terminology One Administrative Domain (OAD): A collection of autonomous systems (ASes) that are managed by a single administrative entity. They do not appear any different to ASes that belong to a separate administration. Member Autonomous System (Member-AS): An autonomous system that is contained within the OAD. 2. Operation All EBGP peering sessions across ASes are configured with an indication on whether they belong to the same OAD. Additionally, each BGP speaker is also configured with a list of member ASes that belong to the OAD. This essentially gives rise to the following classification for EBGP: a. OAD-EBGP: inter-AS peering sessions that belong to the same administration, b. non-OAD-EBGP: inter-AS peering sessions that belong to different administrations. The revised procedures described in the following sections apply with this classification in mind. Note that future protocol extensions may support dynamic exchange of the "OAD concept" in the BGP sessions Mohapatra & Uttaro Expires October 25, 2011 [Page 4] Internet-Draft One Administrative Domain April 2011 (e.g. an OAD cookie capability exchange). However that should not change the revised procedures described herewith. In the absence of any configuration, the default EBGP peering is assumed to be non-OAD-EBGP. 3. Path Attribute Usage This section discusses the revisions to the processing of some of the attributes at a BGP SPEAKER that understands OAD. The revisions are summarized in Table 1. Subsequent sections go into the details of each such attribute revision. +---------------+---------------------------------------------------+ | Attribute | Description | +---------------+---------------------------------------------------+ | LOCAL_PREF | Allow it to be included in updates to OAD-EBGP | | | peers | | - | - | | NEXT_HOP | Allow it to be unchanged (not next-hop-self) in | | | updates to OAD-EBGP peers | | - | - | | MED | Allow an unchanged MED value to appear in UPDATE | | | message to OAD-EBGP peers | | - | - | | Extended | Allow non-transitive extended community across | | Community | OAD-EBGP boundary | | - | - | | ORIGINATOR_ID | Allow it to be included in updates to OAD-EBGP | | | peers | | - | - | | AIGP | Enable it by default for OAD-EBGP peers | +---------------+---------------------------------------------------+ Table 1: Summary of Attribute revisions 3.1. LOCAL_PREF As defined in [RFC4271], LOCAL_PREF is a well-known attribute that SHALL be included in all UPDATE messages to internal peers and MUST NOT be included in UPDATE messages to external peers, except in the case of confederation peers. This document revises the above rule to permit its inclusion in UPDATE messages to OAD-EBGP peers. Customization of LOCAL_PREF attribute within a provider network is a common method used today [RFC1998] and the goal of this proposal is to extend that ability for Mohapatra & Uttaro Expires October 25, 2011 [Page 5] Internet-Draft One Administrative Domain April 2011 providers running multiple ASes. 3.2. NEXT_HOP It SHALL be legal for a BGP speaker to advertise an unchanged NEXT_HOP attribute to OAD-EBGP peers. It is common to have a homogeneous reachability of next hops across all member ASes of an OAD. It thus becomes a requirement to create end-to-end paths for prefix forwarding from the ingress points of the OAD to the egress points. 3.3. MULTI_EXIT_DISC (MED) It SHALL be legal for a BGP speaker to advertise an unchanged MED attribute to peers in a neighboring member-AS of the OAD. MEDs of two routes should only be compared if the AS in the first AS_SEQUENCE after skipping the member ASes in both routes is the same. An implementation should also provide ability to override this so that the MED is compared as per the default rule (i.e. the first AS in the first AS_SEQUENCE is the same irrespective of OAD). 3.4. Extended Community It SHALL be legal for a BGP speaker to advertise and receive non- transitive extended communities across OAD-EBGP peering sessions. 3.5. ORIGINATOR_ID It SHALL be legal for a BGP speaker to advertise and receive ORIGINATOR_ID attribute across OAD-EBGP peering sessions. This revision is required for consistent best path selection across the ASes of the OAD. 3.6. AIGP As defined in section 3.2 of [I-D.ietf-idr-aigp], An implementation that supports the AIGP attribute MUST support a per-session configuration item, AIGP_SESSION, that indicates whether the attribute is enabled or disabled for use on that session. o The default value of AIGP_SESSION, for EBGP sessions, MUST be "disabled". o The default value of AIGP_SESSION, for IBGP and confederation- EBGP sessions, MUST be "enabled." This document revises the above as follows: Mohapatra & Uttaro Expires October 25, 2011 [Page 6] Internet-Draft One Administrative Domain April 2011 o The default value of AIGP_SESSION, for non-OAD-EBGP sessions MUST be "disabled". o The default value of AIGP_SESSION, for IBGP, confederation- EBGP, and OAD-EBGP sessions, MUST be "enabled." 4. Route Flap Damping Route Flap Damping techniques should not be applied to OAD-EBGP peers, for the same reasons that they are not applied to IBGP peers. 5. Discussion Conceptually, the mechanism is very similar to confederations [RFC5065]. The significant difference is that each of the ASes in an OAD is unique in the inter-provider network. Hence the idea of AS_CONFED segment types as well the confederation identifier do not apply. 6. Acknowledgements 7. IANA Considerations None. 8. Security Considerations Improper configuration of OAD-EBGP sessions could result in undesired behavior with respect to attribute passing, unsound selection of paths, or tearing down EBGP sessions. 9. Normative References [I-D.ietf-idr-aigp] Fernando, R., Mohapatra, P., Rosen, E., and J. Uttaro, "The Accumulated IGP Metric Attribute for BGP", draft-ietf-idr-aigp-05 (work in progress), March 2011. [RFC1998] Chen, E. and T. Bates, "An Application of the BGP Community Attribute in Multi-home Routing", RFC 1998, August 1996. Mohapatra & Uttaro Expires October 25, 2011 [Page 7] Internet-Draft One Administrative Domain April 2011 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, February 2006. [RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous System Confederations for BGP", RFC 5065, August 2007. Authors' Addresses Pradosh Mohapatra Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 USA Email: pmohapat@cisco.com James Uttaro ATT 200 S. Laurel Avenue Middletown, NJ 07748 USA Email: uttaro@att.com Mohapatra & Uttaro Expires October 25, 2011 [Page 8]