--- 1/draft-ietf-idr-aigp-14.txt 2014-01-31 10:14:34.021367031 -0800 +++ 2/draft-ietf-idr-aigp-15.txt 2014-01-31 10:14:34.053367805 -0800 @@ -1,26 +1,26 @@ Network Working Group Pradosh Mohapatra Internet Draft Cumulus Networks Intended Status: Proposed Standard -Expires: June 16, 2014 Rex Fernando +Expires: July 31, 2014 Rex Fernando Eric C. Rosen Cisco Systems, Inc. James Uttaro ATT - December 16, 2013 + January 31, 2014 The Accumulated IGP Metric Attribute for BGP - draft-ietf-idr-aigp-14.txt + draft-ietf-idr-aigp-15.txt Abstract Routing protocols that have been designed to run within a single administrative domain ("IGPs") generally do so by assigning a metric to each link, and then choosing as the installed path between two nodes the path for which the total distance (sum of the metric of each link along the path) is minimized. BGP, designed to provide routing over a large number of independent administrative domains ("autonomous systems"), does not make its path selection decisions @@ -49,21 +49,21 @@ material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright and License Notice - Copyright (c) 2013 IETF Trust and the persons identified as the + Copyright (c) 2014 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 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 @@ -80,24 +80,24 @@ 3.4 Creating and Modifying the AIGP Attribute ............. 7 3.4.1 Originating the AIGP Attribute ........................ 7 3.4.2 Modifications by the Originator ....................... 9 3.4.3 Modifications by a Non-Originator ..................... 9 4 Decision Process ...................................... 11 4.1 When a Route has an AIGP Attribute .................... 11 4.2 When the Route to the Next Hop has an AIGP attribute .. 12 5 Deployment Considerations ............................. 13 6 IANA Considerations ................................... 13 7 Security Considerations ............................... 13 - 8 Acknowledgments ....................................... 13 + 8 Acknowledgments ....................................... 14 9 Authors' Addresses .................................... 14 -10 Normative References .................................. 14 -11 Informative References ................................ 14 +10 Normative References .................................. 15 +11 Informative References ................................ 15 1. Specification of requirements 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]. 2. Introduction There are many routing protocols that have been designed to run @@ -286,24 +286,32 @@ 3.4.1. Originating the AIGP Attribute An implementation that supports the AIGP attribute MUST support a configuration item, AIGP_ORIGINATE, that enables or disables its creation and attachment to routes. The default value of AIGP_ORIGINATE MUST be "disabled". A BGP speaker MUST NOT add the AIGP attribute to any route whose path leads outside the "AIGP administrative domain" to which the BGP - speaker belongs. It may be added only to routes that satisfy one of + speaker belongs. When the AIGP attribute is used, changes in IGP + routing will directly impact BGP routing. Attaching the AIGP + attribute to "customer routes", "Internet routes", or other routes + whose paths lead outside the infrastructure of a particular AIGP + administrative domain, could result in BGP scaling and/or thrashing + problems. + + The AIGP attribute may be added only to routes that satisfy one of the following conditions: - - The route is a static route that is being redistributed into BGP; + - The route is a static route, not leading outside the AIGP + administrative domain, that is being redistributed into BGP; - The route is an IGP route that is being redistributed into BGP; - The route is an IBGP-learned route whose AS_PATH attribute is empty; - The route is an EBGP-learned route whose AS_PATH contains only ASes that are in the same AIGP Administrative Domain as the BGP speaker. @@ -531,41 +539,41 @@ will tend to pass the paths for which the IGP distance from the Route Reflector itself to the next hop is smallest. This may result in a non-optimal choice by the clients. 6. IANA Considerations IANA has assigned the codepoint 26 in the "BGP Path Attributes" registry to the AIGP attribute. IANA shall create a registry for "BGP AIGP Attribute Types". The - type field consists of a single octet, with possible values from 0 to - 255. The allocation policy for this field is to be "Standards Action - with Early Allocation". Type 1 should be defined as "AIGP", and - should refer to this document. + type field consists of a single octet, with possible values from 1 to + 255. (The value 0 is "reserved".) The allocation policy for this + field is to be "Standards Action". Type 1 should be defined as + "AIGP", and should refer to this document. 7. Security Considerations The spurious introduction, though error or malfeasance, of an AIGP attribute, could result in the selection of paths other than those desired. Improper configuration on both ends of an EBGP connection could result in an AIGP attribute being passed from one service provider to another. This would likely result in an unsound selection of paths. 8. Acknowledgments - The authors would like to thank Waqas Alam, Rajiv Asati, Bruno - Decraene, Brian Dickson, Clarence Filsfils, Anoop Kapoor, Pratima - Kini, Sue Hares, Thomas Mangin, Robert Raszuk, Yakov Rekhter, Eric - Rosenberg, Samir Saad, John Scudder, Shyam Sethuram, and Ilya + The authors would like to thank Waqas Alam, Rajiv Asati, Ron Bonica, + Bruno Decraene, Brian Dickson, Clarence Filsfils, Anoop Kapoor, + Pratima Kini, Sue Hares, Thomas Mangin, Robert Raszuk, Yakov Rekhter, + Eric Rosenberg, Samir Saad, John Scudder, Shyam Sethuram, and Ilya Varlashkin for their input. 9. Authors' Addresses Rex Fernando Cisco Systems, Inc. 170 Tasman Drive San Jose, CA 95134 Email: rex@cisco.com