--- 1/draft-ietf-idr-aigp-10.txt 2013-11-21 08:14:26.685536178 -0800 +++ 2/draft-ietf-idr-aigp-11.txt 2013-11-21 08:14:26.713536883 -0800 @@ -1,26 +1,26 @@ Network Working Group Pradosh Mohapatra Internet Draft Cumulus Networks Intended Status: Proposed Standard -Expires: November 23, 2013 Rex Fernando +Expires: May 21, 2014 Rex Fernando Eric C. Rosen Cisco Systems, Inc. James Uttaro ATT - May 23, 2013 + November 21, 2013 The Accumulated IGP Metric Attribute for BGP - draft-ietf-idr-aigp-10.txt + draft-ietf-idr-aigp-11.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 @@ -68,35 +68,36 @@ 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. Table of Contents 1 Specification of requirements ......................... 3 2 Introduction .......................................... 3 3 AIGP Attribute ........................................ 5 3.1 Applicability Restrictions and Cautions ............... 6 - 3.2 Restrictions on Sending/Receiving ..................... 6 - 3.3 Creating and Modifying the AIGP Attribute ............. 7 - 3.3.1 Originating the AIGP Attribute ........................ 7 - 3.3.2 Modifications by the Originator ....................... 8 - 3.3.3 Modifications by a Non-Originator ..................... 8 - 4 Decision Process ...................................... 10 - 4.1 When a Route has an AIGP Attribute .................... 10 - 4.2 When the Route to the Next Hop has an AIGP attribute .. 11 + 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 ............................. 12 - 6 IANA Considerations ................................... 12 - 7 Security Considerations ............................... 12 - 8 Acknowledgments ....................................... 12 + 6 IANA Considerations ................................... 13 + 7 Security Considerations ............................... 13 + 8 Acknowledgments ....................................... 13 9 Authors' Addresses .................................... 13 -10 Normative References .................................. 13 -11 Informative References ................................ 13 +10 Normative References .................................. 14 +11 Informative References ................................ 14 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 @@ -186,21 +187,22 @@ | Type | Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ~ ~ | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.......................... AIGP TLV Figure 1 - Type: A single octet encoding the TLV Type. Only type 1, "AIGP - TLV", is defined in this document. + TLV", is defined in this document. Use of other TLV types is + outside the scope of this document. - Length: Two octets encoding the length in octets of the TLV, including the type and length fields. The length is encoded as an unsigned binary integer. (Note that the minimum length is 3, indicating that no value field is present.) - A value field containing zero or more octets. This document defines only a single such TLV, the "AIGP TLV". The AIGP TLV is encoded as follows: @@ -209,56 +211,86 @@ - Length: 11 - Accumulated IGP Metric. The value field of the AIGP TLV is always 8 bytes long. IGP metrics are frequently expressed as 4-octet values, and this ensures that the AIGP attribute can be used to hold the sum of an arbitrary number of 4-octet values. + When an AIGP attribute is created, it SHOULD contain no more than one + AIGP TLV. However, if it contains more than one AIGP TLV, only the + first one is 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. 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. Restrictions on Sending/Receiving +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 + ignored and not passed along to other BGP peers". This is equivalent + to the "attribute discard" action specified in [BGP-ERROR]. + + Note that an AIGP attribute MUST NOT be considered to be malformed + because it contains more than one TLV of a given type, or because it + contains TLVs of unknown types. + + If a BGP Path Attribute is received that has the AIGP attribute + codepoint, but also has the transitive bit set, the attribute MUST be + considered to be a malformed AIGP attribute, and MUST be discarded as + specified in this section. + + If an AIGP attribute is received, and its first AIGP TLV contains the + maximum value 0xffffffffffffffff, the attribute SHOULD be considered + to be malformed, and discarded as specified in this section. (Since + the TLV value cannot be increased any further, it is not useful for + metric-based path selection.) + +3.3. Restrictions on Sending/Receiving 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. - The default value of AIGP_SESSION, for EBGP sessions, MUST be "disabled". - The default value of AIGP_SESSION, for IBGP and confederation- - EBGP sessions, MUST be "enabled." + EBGP sessions, SHOULD be "enabled." The AIGP attribute MUST NOT be sent on any BGP session for which AIGP_SESSION is disabled. If an AIGP attribute is received on a BGP session for which AIGP_SESSION is disabled, the attribute MUST be treated exactly as if it were an unrecognized non-transitive attribute. That is, "it MUST be quietly ignored and not passed along to other BGP peers" (see - [BGP], section 5). -3.3. Creating and Modifying the AIGP Attribute +3.4. Creating and Modifying the AIGP Attribute -3.3.1. Originating the AIGP Attribute +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 the following conditions: @@ -277,124 +309,129 @@ A BGP speaker R MUST NOT add the AIGP attribute to any route for which R does not set itself as the next hop. It SHOULD be possible to set AIGP_ORIGINATE to "enabled for the routes of a particular IGP that are redistributed into BGP" (where "a particular IGP" might be "OSPF" or "ISIS"). Other policies determining when and whether to originate an AIGP attribute are also possible, depending on the needs of a particular deployment scenario. When originating an AIGP attribute for a BGP route to address prefix - P, the value of the attribute is set according to policy. There are - a number of useful policies, some of which are in the following list: + P, the value of the AIGP TLV is set according to policy. There are a + number of useful policies, some of which are in the following list: - When a BGP speaker R is redistributing into BGP an IGP route to address prefix P, the IGP will have computed a "distance" from R - to P. This distance MAY be assigned as the value of AIGP - attribute. + to P. This distance MAY be assigned as the value of the AIGP + TLV. - A BGP speaker R may be redistributing into BGP a static route to address prefix P, for which a "distance" from R to P has been - configured. This distance MAY be assigned as the value of AIGP - attribute. + configured. This distance MAY be assigned as the value of the + AIGP TLV. - A BGP speaker R may have received and installed a BGP-learned route to prefix P, with next hop N. Or it may be redistributing a static route to P, with next hop N. Then: * If R has an IGP route to N, the IGP-computed distance from R - to N MAY be used as the AIGP attribute value of the route to + to N MAY be used as the value of the AIGP TLV of the route to P. - * If R has a BGP route to N, and an AIGP attribute value has - been computed for that route (see section 3.3.3), that value - MAY be used as the AIGP attribute value of the route to P. + * If R has a BGP route to N, and an AIGP TLV attribute value + has been computed for that route (see section 3.4.3), that + value MAY be used as the AIGP TLV value of the route to P. -3.3.2. Modifications by the Originator +3.4.2. Modifications by the Originator If BGP speaker R is the originator of the AIGP attribute of prefix P, and at some point the "distance" from R to P changes, R SHOULD issue - a new BGP update containing the new value of the AIGP attribute. - (Here we use the term "distance" to refer to whatever value the - originator assigns to the AIGP attribute, however it is computed; see - section 3.3.1.) However, if the difference between the new distance - and the distance advertised in the AIGP attribute is less than a + a new BGP update containing the new value of the AIGP TLV of the AIGP + attribute. (Here we use the term "distance" to refer to whatever + value the originator assigns to the AIGP TLV, however it is computed; + see section 3.4.1.) However, if the difference between the new + distance and the distance advertised in the AIGP TLV is less than a configurable threshold, the update MAY be suppressed. -3.3.3. Modifications by a Non-Originator +3.4.3. Modifications by a Non-Originator Suppose a BGP speaker R1 receives a route with an AIGP attribute whose value is A, and a Next Hop whose value is R2. Suppose also that R1 is about to redistribute that route on a BGP session that is enabled for sending/receiving the attribute. If R1 does not change the Next Hop of the route, then R1 MUST NOT change the AIGP attribute value of the route. + In all the computations discussed in this section, the AIGP value + MUST be capped at its maximum unsigned value 0xffffffffffffffff. + Increasing the AIGP value MUST NOT cause the value to wrap around. + If R1 changes the Next Hop of the route from R2 to R1, and if R1's route to R2 is an IGP-learned route, or a static route that does not - require recursive next hop resolution, then R1 must increase the - value of the AIGP attribute by adding to A the distance from R1 to - R2. This distance is either the IGP-computed distance from R1 to R2, - or some value determined by policy. However, A MUST be increased by - a non-zero amount. + require recursive next hop resolution, then R1 MUST increase the + value of the AIGP TLV by adding to A the distance from R1 to R2. + This distance is either the IGP-computed distance from R1 to R2, or + some value determined by policy. However, A MUST be increased by a + non-zero amount. Note that if R1 and R2 above are EBGP neighbors, and there is a direct link between them on which no IGP is running, then when R1 - changes the next hop of a route from R2 to R1, the AIGP metric value + changes the next hop of a route from R2 to R1, the AIGP TLV value MUST be increased by a non-zero amount. The amount of the increase SHOULD be such that it is properly comparable to the IGP metrics. E.g., if the IGP metric is a function of latency, then the amount of the increase should be a function of the latency from R1 to R2. If R1 changes the Next Hop of the route from R2 to R1, and if R1's route to R2 is a BGP-learned route, or a static route that requires - recursive next hop resolution, then the AIGP attribute value needs to - be increased in several steps, according to the following procedure. + recursive next hop resolution, then the AIGP TLV value needs to be + increased in several steps, according to the following procedure. (Note that this procedure is ONLY used when recursive next hop resolution is needed.) - - 1. Let Xattr be the new AIGP attribute value. + 1. Let Xattr be the new AIGP TLV value. 2. Initialize Xattr to A. 3. Set the XNH to R2. 4. Find the route to XNH. 5. If the route to XNH does not require recursive next hop resolution, get the distance D from R1 to XNH. (Note that this condition cannot be satisfied the first time through this procedure.) If D is above a configurable threshold, set the - AIGP attribute value to Xattr+D. If D is below a configurable - threshold, set the AIGP attribute value to Xattr. In either - case, exit this procedure. + AIGP TLV value to Xattr+D. If D is below a configurable + threshold, set the AIGP TLV value to Xattr. In either case, + exit this procedure. 6. If the route to XNH is a BGP-learned route, and the route does NOT have an AIGP attribute, then exit this procedure and do not - pass on any AIGP attribute. + pass on any AIGP attribute. If the route has an AIGP attribute + without an AIGP TLV, then the AIGP attribute MAY be passed + along unchanged. 7. If the route to XNH is a BGP-learned route, and the route has - an AIGP attribute value of Y, then set Xattr=Xattr+Y, and set - XNH to the next hop of this route. (The intention here is that - Y is the AIGP value of the route as it was received by R1, + an AIGP TLV value of Y, then set Xattr=Xattr+Y, and set XNH to + the next hop of this route. (The intention here is that Y is + the AIGP TLV value of the route as it was received by R1, without having been modified by R1.) 8. Go to step 4. - The AIGP value of a given route depends on (a) the AIGP values of all - the next hops that are recursively resolved during this procedure, - and (b) the IGP distance to any next hop that is not recursively - resolved. Any change due to (a) in any of these values MUST trigger - a new AIGP computation for that route. Whether a change due to (b) - triggers a new AIGP computation depends upon whether the change in - IGP distance exceeds a configurable threshold. + The AIGP TLV value of a given route depends on (a) the AIGP TLV + values of all the next hops that are recursively resolved during this + procedure, and (b) the IGP distance to any next hop that is not + recursively resolved. Any change due to (a) in any of these values + MUST trigger a new AIGP computation for that route. Whether a change + due to (b) triggers a new AIGP computation depends upon whether the + change in IGP distance exceeds a configurable threshold. If the AIGP attribute is carried across several ASes, each with its own IGP domain, it is clear that these procedures are unlikely to give a sensible result if the IGPs are different (e.g., some OSPF and some IS-IS), or if the meaning of the metrics is different in the different IGPs (e.g., if the metric represents bandwidth in some IGP domains but represents latency in others). These procedures also are unlikely to give a sensible result if the metric assigned to inter-AS BGP links (on which no IGP is running) or to static routes is not comparable to the IGP metrics. All such cases are outside the scope @@ -419,69 +456,74 @@ cases, the AIGP attributes of the eliminated routes are not considered. 4.1. When a Route has an AIGP Attribute Assuming that the BGP decision process invokes the tie breaking procedures, the procedures in this section MUST be executed BEFORE any of the tie breaking procedures described in [BGP] section 9.1.2.2 are executed. - If any routes have an AIGP attribute, remove from consideration all - routes that do not have an AIGP attribute. + If any routes have an AIGP attribute containing an AIGP TLV, remove + from consideration all routes that do not have an AIGP attribute + containing an AIGP TLV. + + If router R is considering route T, where T has an AIGP attribute + with an AIGP TLV, - If router R is considering route T, where T has an AIGP attribute, - then R must compute the value A, defined as follows: set A to the - sum of (a) T's AIGP attribute value and (b) the IGP distance from - R to T's next hop. + sum of (a) T's AIGP TLV value and (b) the IGP distance from R to + T's next hop. - remove from consideration all routes that are not tied for the lowest value of A. 4.2. When the Route to the Next Hop has an AIGP attribute Suppose that a given router R1 is comparing two BGP-learned routes, such that either: - - the two routes have equal AIGP attribute values, or else + - the two routes have equal AIGP TLV values, or else - - neither of the two routes has an AIGP attribute. + - neither of the two routes has an AIGP attribute containing an + AIGP TLV. The BGP decision process as specified in [BGP] makes use, in its tie breaker procedures, of "interior cost", defined as follows: "interior cost of a route is determined by calculating the metric to the NEXT_HOP for the route using the Routing Table." Suppose route T has a next hop of N. We modify the notion of the "interior cost" from node R1 to node N as follows: - Let R2 be the BGP next hop of the route to N, after all recursive resolution of the next hop is done. Let m be the IGP distance (or in the case of a static route, the configured distance) from R1 to R2. - - If the installed route to N has an AIGP attribute, set A to the - AIGP value of the route to N, computing the AIGP value of the - route according to the procedure of section 3.3.3. + - If the installed route to N has an AIGP attribute with an AIGP + TLV, set A to the AIGP value of the route to N, computing the + AIGP value of the route according to the procedure of section + 3.4.3. - If the installed route to N does not have an AIGP value, set A to 0. - The "interior cost" of route T is the quantity A+m. 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 [ADDPATH] be used in conjunction with the AIGP + [BESTEXT] and [CONN-REST] 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. 6. IANA Considerations IANA has assigned the codepoint 26 in the "BGP Path Attributes" @@ -498,23 +540,24 @@ 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, Clarence - Filsfils, Robert Raszuk, Yakov Rekhter, Eric Rosenberg, Samir Saad, - John Scudder, and Shyam Sethuram for their input. + The authors would like to thank Waqas Alam, Rajiv Asati, Brian + Dickson, Clarence Filsfils, Pratima Kini, 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 @@ -533,20 +575,24 @@ Middletown, NJ 07748 Email: uttaro@att.com 10. Normative References [BGP], "A Border Gateway Protocol 4 (BGP-4)", Y. Rekhter, T. Li, S. Hares, RFC 4271, January 2006. 11. Informative References - [ADDPATH] "Fast Connectivity Restoration Using BGP Add-Path", P. + [CONN-REST] "Fast Connectivity Restoration Using BGP Add-Path", P. Mohapatra, R. Fernando, C. Filsfils, R. Raszuk, draft-pmohapat-idr- fast-conn-restore-03.txt, January 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. + [RFC2119] "Key words for use in RFCs to Indicate Requirement Levels.", S. Bradner, March 1997.