draft-ietf-idr-aigp-12.txt   draft-ietf-idr-aigp-13.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: May 22, 2014 Rex Fernando Expires: June 3, 2014 Rex Fernando
Eric C. Rosen Eric C. Rosen
Cisco Systems, Inc. Cisco Systems, Inc.
James Uttaro James Uttaro
ATT ATT
November 22, 2013 December 3, 2013
The Accumulated IGP Metric Attribute for BGP The Accumulated IGP Metric Attribute for BGP
draft-ietf-idr-aigp-12.txt draft-ietf-idr-aigp-13.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 12, line 44 skipping to change at page 12, line 44
- If the installed route to N does not have an AIGP value, set A to - If the installed route to N does not have an AIGP value, set A to
0. 0.
- The "interior cost" of route T is the quantity A+m. - The "interior cost" of route T is the quantity A+m.
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 be
more effective if each BGP speaker can use it to choose from among more effective if each BGP speaker can use it to choose from among
multiple routes. Thus is it highly recommended that the procedures of multiple routes. Thus is it highly recommended that the procedures of
[BESTEXT] and [CONN-REST] be used in conjunction with the AIGP [BESTEXT] and [ADD-PATH] be used in conjunction with the AIGP
Attribute. 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 it
will tend to pass the paths for which the IGP distance from the Route 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 Reflector itself to the next hop is smallest. This may result in a
non-optimal choice by the clients. non-optimal choice by the clients.
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"
skipping to change at page 13, line 28 skipping to change at page 13, 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, Brian The authors would like to thank Waqas Alam, Rajiv Asati, Bruno
Dickson, Clarence Filsfils, Anoop Kapoor, Pratima Kini, Thomas Decraene, Brian Dickson, Clarence Filsfils, Anoop Kapoor, Pratima
Mangin, Robert Raszuk, Yakov Rekhter, Eric Rosenberg, Samir Saad, Kini, Thomas Mangin, Robert Raszuk, Yakov Rekhter, Eric Rosenberg,
John Scudder, Shyam Sethuram, and Ilya Varlashkin for their input. Samir Saad, John Scudder, Shyam Sethuram, 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 14, line 23 skipping to change at page 14, line 23
Middletown, NJ 07748 Middletown, NJ 07748
Email: uttaro@att.com Email: uttaro@att.com
10. Normative References 10. Normative References
[BGP], "A Border Gateway Protocol 4 (BGP-4)", Y. Rekhter, T. Li, S. [BGP], "A Border Gateway Protocol 4 (BGP-4)", Y. Rekhter, T. Li, S.
Hares, RFC 4271, January 2006. Hares, RFC 4271, January 2006.
11. Informative References 11. Informative References
[CONN-REST] "Fast Connectivity Restoration Using BGP Add-Path", P. [ADD-PATH] "Advertisement of Multiple Paths in BGP", D. Walton, A.
Mohapatra, R. Fernando, C. Filsfils, R. Raszuk, draft-pmohapat-idr- Retana, E. Chen, J. Scudder, draft-ietf-idr-add-paths-09.txt, October
fast-conn-restore-03.txt, January 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-04.txt, June 2013.
[RFC2119] "Key words for use in RFCs to Indicate Requirement [RFC2119] "Key words for use in RFCs to Indicate Requirement
 End of changes. 6 change blocks. 
11 lines changed or deleted 12 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/