draft-ietf-idr-bgp4-multiprotocol-v2-01.txt   draft-ietf-idr-bgp4-multiprotocol-v2-02.txt 
Network Working Group Tony Bates Network Working Group Tony Bates
Internet Draft Cisco Systems Internet Draft Cisco Systems
Expiration Date: February 1999 Ravi Chandra Expiration Date: August 1999 Ravi Chandra
Cisco Systems Cisco 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-01.txt draft-ietf-idr-bgp4-multiprotocol-v2-02.txt
1. Status of this Memo 1. Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft and is in full conformance with
documents of the Internet Engineering Task Force (IETF), its areas, all provisions of Section 10 of RFC2026.
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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.''
To view the entire list of current Internet-Drafts, please check the The list of current Internet-Drafts can be accessed at
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow http://www.ietf.org/ietf/1id-abstracts.txt
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific The list of Internet-Draft Shadow Directories can be accessed at
Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). http://www.ietf.org/shadow.html.
2. Abstract 2. Abstract
Currently BGP-4 [BGP-4] is capable of carrying routing information Currently BGP-4 [BGP-4] is capable of carrying routing information
only for IPv4 [IPv4]. This document defines extensions to BGP-4 to only for IPv4 [IPv4]. This document defines extensions to BGP-4 to
enable it to carry routing information for multiple Network Layer enable it to carry routing information for multiple Network Layer
protocols (e.g., IPv6, IPX, etc...). The extensions are backward protocols (e.g., IPv6, IPX, etc...). The extensions are backward
compatible - a router that supports the extensions can interoperate compatible - a router that supports the extensions can interoperate
with a router that doesn't support the extensions. with a router that doesn't support the extensions.
skipping to change at page 7, line 39 skipping to change at page 7, line 37
a) Length: a) Length:
The Length field indicates the length in bits of the address The Length field indicates the length in bits of the address
prefix. A length of zero indicates a prefix that matches all prefix. A length of zero indicates a prefix that matches all
(as specified by the address family) addresses (with prefix, (as specified by the address family) addresses (with prefix,
itself, of zero octets). itself, of zero octets).
b) Prefix: b) Prefix:
The Prefix field contains address prefixes followed by enough The Prefix field contains an address prefix followed by enough
trailing bits to make the end of the field fall on an octet trailing bits to make the end of the field fall on an octet
boundary. Note that the value of trailing bits is irrelevant. boundary. Note that the value of trailing bits is irrelevant.
7. Subsequent Address Family Identifier 7. Subsequent Address Family Identifier
This document defines the following values for the Subsequent Address This document defines the following values for the Subsequent Address
Family Identifier field carried in the MP_REACH_NLRI and Family Identifier field carried in the MP_REACH_NLRI and
MP_UNREACH_NLRI attributes: MP_UNREACH_NLRI attributes:
1 - Network Layer Reachability Information used for unicast 1 - Network Layer Reachability Information used for unicast
skipping to change at page 9, line 14 skipping to change at page 9, line 12
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, Sub-AFI> tuples includes them A speaker that supports multiple <AFI, SAFI> tuples includes them as
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, Sub-AFI> 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, Sub-AFI> mechanism) the capability to support that particular <AFI, SAFI>
routes. routes.
9. Security Considerations 9. Security Considerations
This extension to BGP does not change the underlying security issues. This extension to BGP does not change the underlying security issues.
10. Acknowledgements 10. 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 11. 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-01.txt, April 1988 Scudder, draft-ietf-idr-bgp4-cap-neg-03.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
[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 12. 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. Cisco Systems, Inc.
 End of changes. 

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