draft-ietf-idr-aigp-15.txt   draft-ietf-idr-aigp-16.txt 
Network Working Group Pradosh Mohapatra Network Working Group Pradosh Mohapatra
Internet Draft Cumulus Networks Internet Draft Cumulus Networks
Intended Status: Proposed Standard Intended Status: Proposed Standard
Expires: July 31, 2014 Rex Fernando Expires: September 25, 2014 Rex Fernando
Eric C. Rosen Eric C. Rosen
Cisco Systems, Inc. Cisco Systems, Inc.
James Uttaro James Uttaro
ATT ATT
January 31, 2014 March 25, 2014
The Accumulated IGP Metric Attribute for BGP The Accumulated IGP Metric Attribute for BGP
draft-ietf-idr-aigp-15.txt draft-ietf-idr-aigp-16.txt
Abstract Abstract
Routing protocols that have been designed to run within a single Routing protocols that have been designed to run within a single
administrative domain ("IGPs") generally do so by assigning a metric administrative domain ("IGPs") generally do so by assigning a metric
to each link, and then choosing as the installed path between two 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 nodes the path for which the total distance (sum of the metric of
each link along the path) is minimized. BGP, designed to provide each link along the path) is minimized. BGP, designed to provide
routing over a large number of independent administrative domains routing over a large number of independent administrative domains
("autonomous systems"), does not make its path selection decisions ("autonomous systems"), does not make its path selection decisions
skipping to change at page 3, line 21 skipping to change at page 3, line 21
3.2 Handling a Malformed AIGP Attribute ................... 6 3.2 Handling a Malformed AIGP Attribute ................... 6
3.3 Restrictions on Sending/Receiving ..................... 7 3.3 Restrictions on Sending/Receiving ..................... 7
3.4 Creating and Modifying the AIGP Attribute ............. 7 3.4 Creating and Modifying the AIGP Attribute ............. 7
3.4.1 Originating the AIGP Attribute ........................ 7 3.4.1 Originating the AIGP Attribute ........................ 7
3.4.2 Modifications by the Originator ....................... 9 3.4.2 Modifications by the Originator ....................... 9
3.4.3 Modifications by a Non-Originator ..................... 9 3.4.3 Modifications by a Non-Originator ..................... 9
4 Decision Process ...................................... 11 4 Decision Process ...................................... 11
4.1 When a Route has an AIGP Attribute .................... 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 4.2 When the Route to the Next Hop has an AIGP attribute .. 12
5 Deployment Considerations ............................. 13 5 Deployment Considerations ............................. 13
6 IANA Considerations ................................... 13 6 IANA Considerations ................................... 14
7 Security Considerations ............................... 13 7 Security Considerations ............................... 14
8 Acknowledgments ....................................... 14 8 Acknowledgments ....................................... 14
9 Authors' Addresses .................................... 14 9 Authors' Addresses .................................... 14
10 Normative References .................................. 15 10 Normative References .................................. 15
11 Informative References ................................ 15 11 Informative References ................................ 15
1. Specification of requirements 1. Specification of requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
skipping to change at page 6, line 33 skipping to change at page 6, line 33
first one is used as described in Section 3.4 and Section 4. In the 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 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. 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 Any other AIGP TLVs in the AIGP attribute MUST be passed along
unchanged if the AIGP attribute is passed along. unchanged if the AIGP attribute is passed along.
3.1. Applicability Restrictions and Cautions 3.1. Applicability Restrictions and Cautions
This document only considers the use of the AIGP attribute in This document only considers the use of the AIGP attribute in
networks where each router uses tunneling of some sort to deliver a 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 packet to its BGP next hop. Use of the AIGP attribute in other
that do not use tunneling is outside the scope of this document. scenarios is outside the scope of this document.
If a Route Reflector supports the AIGP attribute, but some of its If a Route Reflector supports the AIGP attribute, but some of its
clients do not, then the routing choices that result may not all clients do not, then the routing choices that result may not all
reflect the intended routing policy. reflect the intended routing policy.
3.2. Handling a Malformed AIGP Attribute 3.2. Handling a Malformed AIGP Attribute
When receiving a BGP Update message containing a malformed AIGP When receiving a BGP Update message containing a malformed AIGP
attribute, the attribute MUST be treated exactly as if it were an attribute, the attribute MUST be treated exactly as if it were an
unrecognized non-transitive attribute. That is, "it MUST be quietly unrecognized non-transitive attribute. That is, "it MUST be quietly
skipping to change at page 13, line 8 skipping to change at page 13, line 8
an AIGP TLV, set A to 0. an AIGP TLV, set A to 0.
- The "AIGP-enhanced interior cost" of route T is the quantity A+m. - 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 "interior cost" tie breaker of [BGP] is then applied, but using
the "AIGP-enhanced interior cost" instead of the "interior cost" as the "AIGP-enhanced interior cost" instead of the "interior cost" as
defined in [BGP]. defined in [BGP].
5. Deployment Considerations 5. Deployment Considerations
Using the AIGP attribute to achieve a desired routing policy will be - Using the AIGP attribute to achieve a desired routing policy will
more effective if each BGP speaker can use it to choose from among be more effective if each BGP speaker can use it to choose from
multiple routes. Thus is it highly recommended that the procedures of among multiple routes. Thus is it highly recommended that the
[BESTEXT] and [ADD-PATH] be used in conjunction with the AIGP procedures of [BESTEXT] and [ADD-PATH] be used in conjunction
Attribute. with the AIGP Attribute.
If a Route Reflector does not pass all paths to its clients, then it - If a Route Reflector does not pass all paths to its clients, then
will tend to pass the paths for which the IGP distance from the Route it will tend to pass the paths for which the IGP distance from
Reflector itself to the next hop is smallest. This may result in a the Route Reflector itself to the next hop is smallest. This may
non-optimal choice by the clients. 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 6. IANA Considerations
IANA has assigned the codepoint 26 in the "BGP Path Attributes" IANA has assigned the codepoint 26 in the "BGP Path Attributes"
registry to the AIGP attribute. registry to the AIGP attribute.
IANA shall create a registry for "BGP AIGP Attribute Types". The IANA shall create a registry for "BGP AIGP Attribute Types". The
type field consists of a single octet, with possible values from 1 to type field consists of a single octet, with possible values from 1 to
255. (The value 0 is "reserved".) The allocation policy for this 255. (The value 0 is "reserved".) The allocation policy for this
field is to be "Standards Action". Type 1 should be defined as field is to be "Standards Action". Type 1 should be defined as
skipping to change at page 14, line 7 skipping to change at page 14, line 28
The spurious introduction, though error or malfeasance, of an AIGP The spurious introduction, though error or malfeasance, of an AIGP
attribute, could result in the selection of paths other than those attribute, could result in the selection of paths other than those
desired. desired.
Improper configuration on both ends of an EBGP connection could Improper configuration on both ends of an EBGP connection could
result in an AIGP attribute being passed from one service provider to result in an AIGP attribute being passed from one service provider to
another. This would likely result in an unsound selection of paths. another. This would likely result in an unsound selection of paths.
8. Acknowledgments 8. Acknowledgments
The authors would like to thank Waqas Alam, Rajiv Asati, Ron Bonica, The authors would like to thank Waqas Alam, Rajiv Asati, Alia Atlas,
Bruno Decraene, Brian Dickson, Clarence Filsfils, Anoop Kapoor, Ron Bonica, Bruno Decraene, Brian Dickson, Clarence Filsfils, Anoop
Pratima Kini, Sue Hares, Thomas Mangin, Robert Raszuk, Yakov Rekhter, Kapoor, Pratima Kini, Sue Hares, Thomas Mangin, Robert Raszuk, Yakov
Eric Rosenberg, Samir Saad, John Scudder, Shyam Sethuram, and Ilya Rekhter, Eric Rosenberg, Samir Saad, John Scudder, Shyam Sethuram,
Varlashkin for their input. and Ilya Varlashkin for their input.
9. Authors' Addresses 9. Authors' Addresses
Rex Fernando Rex Fernando
Cisco Systems, Inc. Cisco Systems, Inc.
170 Tasman Drive 170 Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
Email: rex@cisco.com Email: rex@cisco.com
Pradosh Mohapatra Pradosh Mohapatra
skipping to change at page 15, line 22 skipping to change at page 15, line 33
[ADD-PATH] "Advertisement of Multiple Paths in BGP", D. Walton, A. [ADD-PATH] "Advertisement of Multiple Paths in BGP", D. Walton, A.
Retana, E. Chen, J. Scudder, draft-ietf-idr-add-paths-09.txt, October Retana, E. Chen, J. Scudder, draft-ietf-idr-add-paths-09.txt, October
2013. 2013.
[BESTEXT], "Advertisement of the Best External Route in BGP", P. [BESTEXT], "Advertisement of the Best External Route in BGP", P.
Marques, R. Fernando, E. Chen, P. Mohapatra, H. Gredler, draft-ietf- Marques, R. Fernando, E. Chen, P. Mohapatra, H. Gredler, draft-ietf-
idr-best-external-05.txt, January 2012. idr-best-external-05.txt, January 2012.
[BGP-ERROR] "Revised Error Handling for BGP UPDATE Messages", J. [BGP-ERROR] "Revised Error Handling for BGP UPDATE Messages", J.
Scudder, E. Chen, P. Mohapatra, K. Patel, draft-ietf-idr-error- 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 [RFC2119] "Key words for use in RFCs to Indicate Requirement
Levels.", S. Bradner, March 1997. Levels.", S. Bradner, March 1997.
 End of changes. 9 change blocks. 
22 lines changed or deleted 54 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/