draft-ietf-idr-add-paths-05.txt   draft-ietf-idr-add-paths-06.txt 
Network Working Group D. Walton Network Working Group D. Walton
Internet Draft E. Chen Internet Draft E. Chen
Intended Status: Standards Track Cisco Systems Intended Status: Standards Track Cisco Systems
Expiration Date: January 28, 2012 A. Retana Expiration Date: March 16, 2012 A. Retana
Hewlett-Packard Co. Hewlett-Packard Co.
J. Scudder J. Scudder
Juniper Networks Juniper Networks
July 27, 2011 September 15, 2011
Advertisement of Multiple Paths in BGP Advertisement of Multiple Paths in BGP
draft-ietf-idr-add-paths-05.txt draft-ietf-idr-add-paths-06.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on January 28, 2012. This Internet-Draft will expire on March 16, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 5, line 36 skipping to change at page 5, line 36
speaker advertises the ADD-PATH Capability to the peer indicating its speaker advertises the ADD-PATH Capability to the peer indicating its
desire to send multiple paths for the <AFI, SAFI>, and also receives desire to send multiple paths for the <AFI, SAFI>, and also receives
the ADD-PATH Capability from the peer indicating its willingness to the ADD-PATH Capability from the peer indicating its willingness to
receive multiple paths for the <AFI, SAFI>, in which case the speaker receive multiple paths for the <AFI, SAFI>, in which case the speaker
MUST generate a route update for the <AFI, SAFI> based on the MUST generate a route update for the <AFI, SAFI> based on the
combination of the address prefix and the Path Identifier, and use combination of the address prefix and the Path Identifier, and use
the extended NLRI encodings specified in this document. The peer the extended NLRI encodings specified in this document. The peer
SHALL act accordingly in processing an UPDATE message related to a SHALL act accordingly in processing an UPDATE message related to a
particular <AFI, SAFI>. particular <AFI, SAFI>.
A BGP speaker SHOULD include the bestpath when more than one path are
advertised to a neighbor unless the bestpath is a path received from
that neighbor.
When deployed as a provider edge router or a peering router that
interacts with external neighbors, a BGP speaker usually advertises
at most one path to the internal neighbors in a network. In the case
the speaker is configured to advertise multiple paths to the internal
neighbors, it should include the Edge_Discriminator attribute defined
in [FAST-CONV] in order to make the route selection consistent inside
the network.
As the Path Identifiers are locally assigned, and may or may not be As the Path Identifiers are locally assigned, and may or may not be
persistent across a control plane restart of a BGP speaker, an persistent across a control plane restart of a BGP speaker, an
implementation SHOULD take special care so that the underlying implementation SHOULD take special care so that the underlying
forwarding plane of a "Receiving Speaker" as described in [RFC4724] forwarding plane of a "Receiving Speaker" as described in [RFC4724]
is not affected during the graceful restart of a BGP session. is not affected during the graceful restart of a BGP session.
6. Applications 6. Applications
The BGP extension specified in this document can be used by a BGP The BGP extension specified in this document can be used by a BGP
speaker to advertise multiple paths in certain applications. The speaker to advertise multiple paths in certain applications. The
skipping to change at page 7, line 28 skipping to change at page 7, line 28
[RFC3107] Rekhter, R. and E. Rosen, "Carrying Label Information in [RFC3107] Rekhter, R. and E. Rosen, "Carrying Label Information in
BGP-4," RFC 3107, May 2001. BGP-4," RFC 3107, May 2001.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels," RFC 2119, BCP 14, March 1997. Requirement Levels," RFC 2119, BCP 14, March 1997.
[RFC4724] Sangli, S., E. Chen, R. Fernando, J. Scudder, and Y. [RFC4724] Sangli, S., E. Chen, R. Fernando, J. Scudder, and Y.
Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724, January Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724, January
2007. 2007.
[FAST-CONV] Mohapatra, P., R. Fernando, C. Filsfils, R. Raszuk, "Fast
Connectivity Restoration Using BGP Add-path", Work in Progress, March
2011.
11.2. Informative References 11.2. Informative References
[RFC3345] McPherson, D., V. Gill, D. Walton, and A. Retana, "Border [RFC3345] McPherson, D., V. Gill, D. Walton, and A. Retana, "Border
Gateway Protocol (BGP) Persistent Route Oscillation Condition", RFC Gateway Protocol (BGP) Persistent Route Oscillation Condition", RFC
3345, August 2002. 3345, August 2002.
12. Authors' Addresses 12. Authors' Addresses
Daniel Walton Daniel Walton
Cisco Systems, Inc. Cisco Systems, Inc.
 End of changes. 6 change blocks. 
4 lines changed or deleted 20 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/