--- 1/draft-ietf-idr-aigp-15.txt 2014-03-25 07:14:35.697810187 -0700 +++ 2/draft-ietf-idr-aigp-16.txt 2014-03-25 07:14:35.729810974 -0700 @@ -1,26 +1,26 @@ Network Working Group Pradosh Mohapatra Internet Draft Cumulus Networks Intended Status: Proposed Standard -Expires: July 31, 2014 Rex Fernando +Expires: September 25, 2014 Rex Fernando Eric C. Rosen Cisco Systems, Inc. James Uttaro ATT - January 31, 2014 + March 25, 2014 The Accumulated IGP Metric Attribute for BGP - draft-ietf-idr-aigp-15.txt + draft-ietf-idr-aigp-16.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 @@ -78,22 +78,22 @@ 3.2 Handling a Malformed AIGP Attribute ................... 6 3.3 Restrictions on Sending/Receiving ..................... 7 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 + 6 IANA Considerations ................................... 14 + 7 Security Considerations ............................... 14 8 Acknowledgments ....................................... 14 9 Authors' Addresses .................................... 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]. @@ -223,22 +223,22 @@ first one is used as described in Section 3.4 and Section 4. In the remainder of this document, we will use the term "value of the AIGP TLV" to mean the value of the first AIGP TLV in the AIGP attribute. Any other AIGP TLVs in the AIGP attribute MUST be passed along unchanged if the AIGP attribute is passed along. 3.1. Applicability Restrictions and Cautions This document only considers the use of the AIGP attribute in networks where each router uses tunneling of some sort to deliver a - packet to its BGP next hop. Use of the AIGP attribute in networks - that do not use tunneling is outside the scope of this document. + packet to its BGP next hop. Use of the AIGP attribute in other + scenarios is outside the scope of this document. If a Route Reflector supports the AIGP attribute, but some of its clients do not, then the routing choices that result may not all reflect the intended routing policy. 3.2. Handling a Malformed AIGP Attribute When receiving a BGP Update message containing a malformed AIGP attribute, the attribute MUST be treated exactly as if it were an unrecognized non-transitive attribute. That is, "it MUST be quietly @@ -522,30 +522,59 @@ an AIGP TLV, set A to 0. - The "AIGP-enhanced interior cost" of route T is the quantity A+m. The "interior cost" tie breaker of [BGP] is then applied, but using the "AIGP-enhanced interior cost" instead of the "interior cost" as defined in [BGP]. 5. Deployment Considerations - Using the AIGP attribute to achieve a desired routing policy will be - more effective if each BGP speaker can use it to choose from among - multiple routes. Thus is it highly recommended that the procedures of - [BESTEXT] and [ADD-PATH] be used in conjunction with the AIGP - Attribute. + - Using the AIGP attribute to achieve a desired routing policy will + be more effective if each BGP speaker can use it to choose from + among multiple routes. Thus is it highly recommended that the + procedures of [BESTEXT] and [ADD-PATH] be used in conjunction + with the AIGP Attribute. - If a Route Reflector does not pass all paths to its clients, then it - 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. + - If a Route Reflector does not pass all paths to its clients, then + it 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. + + - When the procedures of this document are deployed, it must be + understood that frequent changes of the IGP distance towards a + certain prefix may result in equally frequent transmission of BGP + updates about that prefix. + + - In an IGP deployment, there are certain situations in which a + network link may be temporarily assigned a metric whose value is + the maximum metric value (or close to the maximum) for that IGP. + This is known as "costing out" the link. A link may be "costed + out" to deflect traffic from the link before the link is actually + brought down, or to discourage traffic from using a link until + all the necessary state for that link has been set up (e.g., + [LDP-IGP-SYNC]). This assumes of course that a path containing a + "costed out" link will have a total distance that is larger than + any alternate path within the same IGP area; in that case the + normal IGP decision process will choose the path that does not + contain the costed out link. + + Costing out a link will have the same effect on BGP routes that + carry the AIGP attribute. The value of the AIGP TLV will be + larger for a route (to a given prefix) that contains a "costed + out" link than for a route (to the same prefix) that does not. + It must be understood though that a route that carries an AIGP + attribute will be preferred to a route that does not, no matter + what the value of the AIGP TLV is. This is similar to the + behavior in, e.g., an OSPF area, where an intra-area route is + preferred to an inter-area or external route, even if the intra- + area route's distance is large. 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 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 @@ -556,25 +585,25 @@ 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, 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. + The authors would like to thank Waqas Alam, Rajiv Asati, Alia Atlas, + 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 Pradosh Mohapatra @@ -603,14 +631,17 @@ [ADD-PATH] "Advertisement of Multiple Paths in BGP", D. Walton, A. Retana, E. Chen, J. Scudder, draft-ietf-idr-add-paths-09.txt, October 2013. [BESTEXT], "Advertisement of the Best External Route in BGP", P. Marques, R. Fernando, E. Chen, P. Mohapatra, H. Gredler, draft-ietf- idr-best-external-05.txt, January 2012. [BGP-ERROR] "Revised Error Handling for BGP UPDATE Messages", J. Scudder, E. Chen, P. Mohapatra, K. Patel, draft-ietf-idr-error- - handling-04.txt, June 2013. + handling-06.txt, February 2014. + + [LDP-IGP-SYNC] "LDP IGP Synchronization", M. Jork, A. Atlas, L. Fang, + RFC 5443, March 2009. [RFC2119] "Key words for use in RFCs to Indicate Requirement Levels.", S. Bradner, March 1997.