draft-ietf-idr-bgp4-multiprotocol-v2-03.txt   draft-ietf-idr-bgp4-multiprotocol-v2-04.txt 
Network Working Group Tony Bates Network Working Group Tony Bates
Internet Draft Cisco Systems Internet Draft Cisco Systems
Expiration Date: March 2000 Ravi Chandra Expiration Date: August 2000 Ravi Chandra
Cisco Systems Siara Systems
Dave Katz Dave Katz
Juniper Networks Juniper Networks
Yakov Rekhter Yakov Rekhter
Cisco Systems Cisco Systems
Multiprotocol Extensions for BGP-4 Multiprotocol Extensions for BGP-4
draft-ietf-idr-bgp4-multiprotocol-v2-03.txt draft-ietf-idr-bgp4-multiprotocol-v2-04.txt
1. Status of this Memo 1. Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
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 8, line 20 skipping to change at page 8, line 20
1 - Network Layer Reachability Information used for unicast 1 - Network Layer Reachability Information used for unicast
forwarding forwarding
2 - Network Layer Reachability Information used for multicast 2 - Network Layer Reachability Information used for multicast
forwarding forwarding
3 - Network Layer Reachability Information used for both unicast 3 - Network Layer Reachability Information used for both unicast
and multicast forwarding and multicast forwarding
This document reserves values 128-255 for vendor-specific 8. Error Handling
applications.
This document reserves value 0. If a BGP speaker receives from a neighbor an Update message that
contains the MP_REACH_NLRI or MP_UNREACH_NLRI attribute, and the
speaker determines that the attribute is incorrect, the speaker must
delete all the BGP routes received from that neighbor whose AFI/SAFI
is the same as the one carried in the incorrect MP_REACH_NLRI or
MP_UNREACH_NLRI attribute. For the duration of the BGP session over
which the Update message was received, the speaker then should ignore
all the subsequent routes with that AFI/SAFI received over that
session.
Subsequent Address Family Identifiers (other than those reserved for In addition, the speaker may terminate the BGP session over which the
vendor specific use) are assigned only by the IETF consensus process Update message was received. The session should be terminated with
and IESG approval. the Notification message code/subcode indicating "Update Message
Error"/"Optional Attribute Error".
8. Use of BGP Capability Negotiation 9. Use of BGP Capability Negotiation
A BGP speaker that uses Multiprotocol Extensions should use the A BGP speaker that uses Multiprotocol Extensions should use the
Capability Negotiation procedures [BGP-CAP] to determine whether the Capability Negotiation procedures [BGP-CAP] to determine whether the
speaker could use Multiprotocol Extensions with a particular peer. speaker could use Multiprotocol Extensions with a particular peer.
The fields in the Capabilities Optional Parameter are set as follows. The fields in the Capabilities Optional Parameter are set as follows.
The Capability Code field is set to 1 (which indicates Multiprotocol The Capability Code field is set to 1 (which indicates Multiprotocol
Extensions capabilities). The Capability Length field is set to 4. Extensions capabilities). The Capability Length field is set to 4.
The Capability Value field is defined as: The Capability Value field is defined as:
The use and meaning of this field is as follow:
0 7 15 23 31 0 7 15 23 31
+-------+-------+-------+-------+ +-------+-------+-------+-------+
| AFI | Res. | SAFI | | AFI | Res. | SAFI |
+-------+-------+-------+-------+ +-------+-------+-------+-------+
The use and meaning of this field is as follow:
AFI - Address Family Identifier (16 bit), encoded the same way AFI - Address Family Identifier (16 bit), encoded the same way
as in the Multiprotocol Extensions as in the Multiprotocol Extensions
Res. - Reserved (8 bit) field. Should be set to 0 by the sender Res. - Reserved (8 bit) field. Should be set to 0 by the sender
and ignored by the receiver. and ignored by the receiver.
SAFI - Subsequent Address Family Identifier (8 bit), encoded SAFI - Subsequent Address Family Identifier (8 bit), encoded
the same way as in the Multiprotocol Extensions. the same way as in the Multiprotocol Extensions.
A speaker that supports multiple <AFI, SAFI> tuples includes them as A speaker that supports multiple <AFI, SAFI> tuples includes them as
multiple Capabilities in the Capabilities Optional Parameter. multiple Capabilities in the Capabilities Optional Parameter.
To have a bi-directional exchange of routing information for a To have a bi-directional exchange of routing information for a
particular <AFI, SAFI> between a pair of BGP speakers, each such particular <AFI, SAFI> between a pair of BGP speakers, each such
speaker must advertise to the other (via the Capability Negotiation speaker must advertise to the other (via the Capability Negotiation
mechanism) the capability to support that particular <AFI, SAFI> mechanism) the capability to support that particular <AFI, SAFI>
routes. routes.
9. Security Considerations 10. IANA Considerations
This extension to BGP does not change the underlying security issues. As specified in this document, the MPL_REACH_NLRI and MP_UNREACH_NLRI
attributes contain the Subsequence Address Family Identifier (SAFI)
field. SAFI value 0 is reserved. SAFI values 1, 2, and 3 are
assigned in this document. SAFI values 4 through 63 are to be
assigned by IANA using the "IETF Consensus" policy defined in
RFC2434. SAFI values 64 through 127 are to be assigned by IANA, using
the "First Come First Served" policy defined in RFC2434. SAFI values
128 through 255 are vendor-specific, and values in this range are not
to be assigned by IANA.
10. Acknowledgements 11. Security Considerations
This extension to BGP does not change the underlying security issues
inherent in the existing BGP [Heffernan].
12. Acknowledgements
The authors would like to thank members of the IDR Working Group for The authors would like to thank members of the IDR Working Group for
their review and comments. their review and comments.
11. References 13. References
[BGP-CAP] "Capabilities Negotiation with BGP-4", R. Chandra, J. [BGP-CAP] "Capabilities Negotiation with BGP-4", R. Chandra, J.
Scudder, draft-ietf-idr-bgp4-cap-neg-03.txt, February 1999 Scudder, draft-ietf-idr-bgp4-cap-neg-05.txt, February 1999
[BGP-4] "A Border Gateway Protocol 4 (BGP-4)", Y. Rekhter & T. Li, [BGP-4] "A Border Gateway Protocol 4 (BGP-4)", Y. Rekhter & T. Li,
RFC1771, March 1995 RFC1771, March 1995
[Heffernan] Heffernan, A., "Protection of BGP Sessions via the TCP
MD5 Signature Option", RFC2385, August 1998.
[IPv4] "Internet Protocol", J. Postel, September 1981 [IPv4] "Internet Protocol", J. Postel, September 1981
[RFC1700] "Assigned Numbers", J. Reynolds, J. Postel, RFC1700, [RFC1700] "Assigned Numbers", J. Reynolds, J. Postel, RFC1700,
October 1994 (see also http://www.iana.org/iana/assignments.html) October 1994 (see also http://www.iana.org/iana/assignments.html)
12. Author Information 14. Author Information
Tony Bates Tony Bates
Cisco Systems, Inc. Cisco Systems, Inc.
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
email: tbates@cisco.com email: tbates@cisco.com
Ravi Chandra Ravi Chandra
Cisco Systems, Inc. Siara Systems Incorporated
170 West Tasman Drive 1195 Borregas Avenue
San Jose, CA 95134 Sunnyvale, CA 94089
email: rchandra@cisco.com e-mail: rchandra@siara.com
Dave Katz Dave Katz
Juniper Networks, Inc. Juniper Networks, Inc.
3260 Jay St. 3260 Jay St.
Santa Clara, CA 95054 Santa Clara, CA 95054
email: dkatz@jnx.com email: dkatz@jnx.com
Yakov Rekhter Yakov Rekhter
Cisco Systems, Inc. Cisco Systems, Inc.
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
email: yakov@cisco.com email: yakov@cisco.com
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/