draft-ietf-idr-aigp-11.txt   draft-ietf-idr-aigp-12.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 21, 2014 Rex Fernando Expires: May 22, 2014 Rex Fernando
Eric C. Rosen Eric C. Rosen
Cisco Systems, Inc. Cisco Systems, Inc.
James Uttaro James Uttaro
ATT ATT
November 21, 2013 November 22, 2013
The Accumulated IGP Metric Attribute for BGP The Accumulated IGP Metric Attribute for BGP
draft-ietf-idr-aigp-11.txt draft-ietf-idr-aigp-12.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 13, line 29 skipping to change at page 13, line 29
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, Brian
Dickson, Clarence Filsfils, Pratima Kini, Thomas Mangin, Robert Dickson, Clarence Filsfils, Anoop Kapoor, Pratima Kini, Thomas
Raszuk, Yakov Rekhter, Eric Rosenberg, Samir Saad, John Scudder, Mangin, Robert Raszuk, Yakov Rekhter, Eric Rosenberg, Samir Saad,
Shyam Sethuram, and Ilya Varlashkin for their input. 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
 End of changes. 4 change blocks. 
6 lines changed or deleted 6 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/