draft-ietf-idr-rfc4760bis-00.txt   draft-ietf-idr-rfc4760bis-01.txt 
Network Working Group Tony Bates (Skype) Network Working Group Tony Bates (Skype)
Internet Draft Ravi Chandra (Cisco Systems) Internet Draft Ravi Chandra (Cisco Systems)
Expiration Date: July 2011 Dave Katz (Juniper Networks) Expiration Date: September 2011 Dave Katz (Juniper Networks)
Yakov Rekhter (Juniper Networks) Yakov Rekhter (Juniper Networks)
January 11, 2011 March 28, 2011
Multiprotocol Extensions for BGP-4 Multiprotocol Extensions for BGP-4
draft-ietf-idr-rfc4760bis-00.txt draft-ietf-idr-rfc4760bis-01.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 other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 8, line 34 skipping to change at page 8, line 34
contains a valid MP_REACH_NLRI or MP_UNREACH_NLRI attribute, and if contains a valid MP_REACH_NLRI or MP_UNREACH_NLRI attribute, and if
the speaker determines that the attribute has no NLRI, the speaker the speaker determines that the attribute has no NLRI, the speaker
MUST NOT treat this UPDATE message as a BGP error, and specifically MUST NOT treat this UPDATE message as a BGP error, and specifically
MUST NOT terminate the BGP session over which the UPDATE was MUST NOT terminate the BGP session over which the UPDATE was
received, and MUST NOT ignore all the subsequent routes received over received, and MUST NOT ignore all the subsequent routes received over
that session with the AFI/SAFI carried in the attribute. This is that session with the AFI/SAFI carried in the attribute. This is
irrespective of whether the received message contains any non-empty irrespective of whether the received message contains any non-empty
Withdrawn Routes, and/or non-empty Network Layer Reachability Withdrawn Routes, and/or non-empty Network Layer Reachability
Information fields. Information fields.
8. Use of BGP Capability Advertisement 8. Redistribution from one <AFI, SAFI> to another
A router SHALL NOT redistribute routing information received over one
particular combination of <AFI, SAFI> into another <AFI, SAFI> unless
explicitly configured. The implications of doing such redistribution
are numerous and serious, but outside the scope of this document.
If a router is explicitly configured to redistribute routing
information received over one particular combination of <AFI, SAFI>
over another <AFI, SAFI>, then when redistributing the information
the router MUST set NEXT_HOP to self.
9. Use of BGP Capability Advertisement
A BGP speaker that uses Multiprotocol Extensions SHOULD use the A BGP speaker that uses Multiprotocol Extensions SHOULD use the
Capability Advertisement procedures [BGP-CAP] to determine whether Capability Advertisement procedures [BGP-CAP] to determine whether
the speaker could use Multiprotocol Extensions with a particular the speaker could use Multiprotocol Extensions with a particular
peer. 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. MUST be set to 0 by the sender Res. - Reserved (8 bit) field. MUST be set to 0 by the sender
and MUST be ignored by the receiver. and MUST be 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 Advertisement speaker MUST advertise to the other (via the Capability Advertisement
mechanism) the capability to support that particular <AFI, SAFI> mechanism) the capability to support that particular <AFI, SAFI>
routes. routes.
9. IANA Considerations 10. IANA Considerations
As specified in this document, the MP_REACH_NLRI and MP_UNREACH_NLRI As specified in this document, the MP_REACH_NLRI and MP_UNREACH_NLRI
attributes contain the Subsequence Address Family Identifier (SAFI) attributes contain the Subsequence Address Family Identifier (SAFI)
field. The SAFI name space is defined in this document. The IANA field. The SAFI name space is defined in this document. The IANA
registered and maintains values for the SAFI namespace as follows: registered and maintains values for the SAFI namespace as follows:
- SAFI values 1 and 2 are assigned in this document. - SAFI values 1 and 2 are assigned in this document.
- SAFI value 3 is reserved. It was assigned by RFC 2858 for a use - SAFI value 3 is reserved. It was assigned by RFC 2858 for a use
that was never fully implemented, so it is deprecated by this that was never fully implemented, so it is deprecated by this
skipping to change at page 10, line 12 skipping to change at page 10, line 36
- SAFI values 128 through 240 are part of the previous "private - SAFI values 128 through 240 are part of the previous "private
use" range. At the time of approval of this document, the unused use" range. At the time of approval of this document, the unused
values were provided to IANA by the Routing Area Director. These values were provided to IANA by the Routing Area Director. These
unused values, namely, 130, 131, 135 through 139, and 141 through unused values, namely, 130, 131, 135 through 139, and 141 through
240, are considered reserved in order to avoid conflicts. 240, are considered reserved in order to avoid conflicts.
- SAFI values 241 through 254 are for "private use", and values in - SAFI values 241 through 254 are for "private use", and values in
this range are not to be assigned by IANA. this range are not to be assigned by IANA.
10. Comparison with RFC4760 11. Comparison with RFC4760
This document explicitly spells out that receiving an UPDATE message This document explicitly spells out that receiving an UPDATE message
that carried MP_REACH_NLRI or MP_UNREACH_NLRI attribute, with the that carried MP_REACH_NLRI or MP_UNREACH_NLRI attribute, with the
attribute carrying no NLRI, must not be treated as an error. attribute carrying no NLRI, must not be treated as an error.
This document also recommends that that the MP_REACH_NLRI and This document also recommends that that the MP_REACH_NLRI and
MP_UNREACH_NLRI attributes be placed as the very first path MP_UNREACH_NLRI attributes be placed as the very first path
attributes in an UPDATE in this case. attributes in an UPDATE in this case.
11. Comparison with RFC2858 12. Comparison with RFC2858
This document makes the use of the next hop information consistent This document makes the use of the next hop information consistent
with the information carried in the NEXT_HOP BGP path attribute. with the information carried in the NEXT_HOP BGP path attribute.
This document removes the definition of SAFI 3, and deprecates SAFI This document removes the definition of SAFI 3, and deprecates SAFI
3. 3.
This document changes partitioning of the SAFI space. Specifically, This document changes partitioning of the SAFI space. Specifically,
in RFC 2858 SAFI values 128 through 240 were part of the "private in RFC 2858 SAFI values 128 through 240 were part of the "private
use" range. This document specifies that of this range, allocations use" range. This document specifies that of this range, allocations
that are currently in use are to be recognized by IANA, and that that are currently in use are to be recognized by IANA, and that
unused values, namely 130, 131, 135 through 139, and 141 through 240, unused values, namely 130, 131, 135 through 139, and 141 through 240,
should be considered reserved. should be considered reserved.
This document renames the Number of SNPAs field to Reserved, and This document renames the Number of SNPAs field to Reserved, and
removes the rest of the SNPA-related information from the removes the rest of the SNPA-related information from the
MP_REACH_NLRI attribute. MP_REACH_NLRI attribute.
12. Comparison with RFC 2283 13. Comparison with RFC 2283
This document restricts the MP_REACH_NLRI attribute to carry only a This document restricts the MP_REACH_NLRI attribute to carry only a
single instance of <AFI, SAFI, Next Hop Information, ...>. single instance of <AFI, SAFI, Next Hop Information, ...>.
This document restricts the MP_UNREACH_NLRI attribute to carry only a This document restricts the MP_UNREACH_NLRI attribute to carry only a
single instance of <AFI, SAFI, ...>. single instance of <AFI, SAFI, ...>.
This document clarifies handling of an UPDATE message that carries no This document clarifies handling of an UPDATE message that carries no
NLRI, other than the one encoded in the MP_REACH_NLRI attribute. NLRI, other than the one encoded in the MP_REACH_NLRI attribute.
This document clarifies error handling in the presence of This document clarifies error handling in the presence of
MP_REACH_NLRI or MP_UNREACH_NLRI attributes. MP_REACH_NLRI or MP_UNREACH_NLRI attributes.
This document specifies the use of BGP Capabilities Advertisements in This document specifies the use of BGP Capabilities Advertisements in
conjunction with multi-protocol extensions. conjunction with multi-protocol extensions.
Finally, this document includes the "IANA Consideration" section. Finally, this document includes the "IANA Consideration" section.
13. Security Considerations 14. Security Considerations
This extension to BGP does not change the underlying security issues This extension to BGP does not change the underlying security issues
inherent in the existing BGP. inherent in the existing BGP.
14. Acknowledgements 15. 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. We also acknowledge comments from Keyur their review and comments. We also acknowledge comments from Keyur
Patel. Patel.
15. Normative References 16. Normative References
[BGP-CAP] Chandra, R. and J. Scudder, "Capabilities Advertisement [BGP-CAP] Chandra, R. and J. Scudder, "Capabilities Advertisement
with BGP-4", RFC 3392, November 2002. with BGP-4", RFC 3392, November 2002.
[BGP-4] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway [BGP-4] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006. Protocol 4 (BGP-4)", RFC 4271, January 2006.
[IANA-AF] "Address Family Numbers", Reachable from [IANA-AF] "Address Family Numbers", Reachable from
http://www.iana.org/numbers.html http://www.iana.org/numbers.html
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC4020] Kompella, K. and A. Zinin, "Early IANA Allocation of [RFC4020] Kompella, K. and A. Zinin, "Early IANA Allocation of
Standards Track Code Points", BCP 100, RFC 4020, February 2005. Standards Track Code Points", BCP 100, RFC 4020, February 2005.
16. Authors' Addresses 17. Authors' Addresses
Tony Bates Tony Bates
Skype Skype
Ravi Chandra Ravi Chandra
Cisco Systems Cisco Systems
EMail: rchandra@cisco.com EMail: rchandra@cisco.com
Dave Katz Dave Katz
Juniper Networks, Inc. Juniper Networks, Inc.
 End of changes. 14 change blocks. 
14 lines changed or deleted 26 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/