Network Working Group Gargi Nalawade
Internet Draft Himanshu Shah
Expires: February 2004
Cisco Systems
BGPv4 Update-v2 Message
draft-nalawade-bgp-update-v2-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document defines a new BGP message type, the BGP UPDATE-v2
message that organizes the attribute encodings and the NLRI sections
in a better manner. This is especially useful in light of the many
new AFI/SAFIs that have been proposed in the recent years and the
reliability and robustness of the BGP Protocol.
1. Introduction
The current version of the BGP UPDATE Message has evolved from its
original definition for IPv4 Unicast AFI/SAFI. The use of new
AFI/SAFIs in BGP has caused the MP_REACH and MP_UNREACH attributes to
draft-nalawade-bgp-update-v2-00.txt [Page 1]
Internet Draft draft-nalawade-bgp-update-v2-00.txt August 2003
be defined. But the attributes such as NEXTHOP still continued to
apply only to IPv4 Unicast. It is only defined to carry an IPv4
address. This has forced several workarounds over the years such as
carrying the Nexthop corresponding to the AFI/SAFI inside the
MP_REACH/MP_UNREACH attribute.
Carrying non-IPv4 NLRIs in the MP_REACH/MP_UNREACH attribute itself
is a workaround to the fact that the NLRI section only applies to
IPv4 Unicast routes.
Also, the current BGP UPDATE Message starts out as being generic such
that it could apply to any AFI/SAFI - until an MP_REACH/MP_UNREACH
section is encountered. Only then can it be decided whether to use
the NEXTHOP attribute or the NEXTHOP encoded in the MP_REACH
attribute as the applicable NEXTHOP.
The MP_REACH/MP_UNREACH attribute needs to be successfully parsed to
identify the AFI/SAFI to which the UPDATE Message applies. Thus, if
there is an error in the section preceding the MP_REACH attribute,
the whole BGP session and other AFI/SAFIs running on the same
saession are impacted. This does not protect one AFI/SAFI from being
impacted by the other AFI/SAFIs on the same session - in case of
AFI/SAFI specific errors that make it impossible to parse the
MP_REACH/ MP_UNREACH section.
The proposed BGP UPDATE-v2 message proposes solving all of the
above-mentioned problems. BGP UPDATE-v2 will enable separation of
updates belonging to different AFI/SAFI and an error in attribute can
be isolated to a particular AFI/SAFI.
2. Definition of the BGP UPDATE-v2 Message
The BGP UPDATE-v2 message is a BGP message with type TBD. In
addition to the fixed-size BGP header, the UPDATE-v2 message contains
the following fields:
+-----------------------------------------------------+
| AFI (2 octets) |
+-----------------------------------------------------+
| SAFI (2 octets) |
+-----------------------------------------------------+
| Reserved (2 octets) |
+-----------------------------------------------------+
| Withdrawn Routes Length (2 octets) |
draft-nalawade-bgp-update-v2-00.txt [Page 2]
Internet Draft draft-nalawade-bgp-update-v2-00.txt August 2003
+-----------------------------------------------------+
| Withdrawn Routes (variable) |
+-----------------------------------------------------+
| Total Path Attribute Length (2 octets) |
+-----------------------------------------------------+
| Path Attributes (variable) |
+-----------------------------------------------------+
| Network Layer Reachability Information (variable) |
+-----------------------------------------------------+
where :
AFI : as defined in [IANA-AFI] [IANA-SAFI]
SAFI : a 2-octet long field, where the second of the 2 octets,
contains the SAFI as defined in [IANA-AFI] [IANA-SAFI]
Withdrawn Routes Length : as defined in [BGP-4]
Withdrawn Routes : would contain NLRIS that need to be withdrawn and
which belong to the AFI/SAFI as specified in the AFI/SAFI field in
the message.
Total Path Attribute Length : as defined in [BGP-4]
Path Attributes : as defined in [BGP-4] except for the attributes
NEXTHOP, MP_REACH, MP_UNREACH
Network Layer Reachability Information : would contain NLRI
information for the AFI/SAFI as specified in the Update-v2 Message
2.1. BGP Attributes
The BGP Attributes used by UPDATE-v2 remain the same as the BGP
UPDATE Message, with the following exceptions :
THE MP_REACH and MP_UNREACH Attributes will get deprecated.
The NEXTHOP attribute will have the format as defined by [BGP-MP-
NHOP].
3. Operation
draft-nalawade-bgp-update-v2-00.txt [Page 3]
Internet Draft draft-nalawade-bgp-update-v2-00.txt August 2003
The Operation remains the same as the Update Message as defined in
[BGP-4]
If a BGP speaker that has successfully negotiated a Capability for
exchanging UPDATE-v2 for an AFI/SAFI and receives an Update Message
for that AFI/SAFI it MUST signal an error condition to that peer.
For peers that support [BGP-SOFT], a BGPv4 Soft-Notification Message
should be sent back to the peer with a Error Code Update and sub-code
Invalid Message Type. For peers that dont support [BGP-SOFT] the BGP
SPeaker may reset the session with the peer with Error Code Update
Message Error and a new Error Sub-code Invalid Message Type.
4. Capability
A new capability [BGP-CAP] code (TBD) is defined for the BGP UPDATE-
v2 messages. A BGP UPDATE-v2 message can only be sent to peers that
have advertised this capability.
The Capability will have the following format :
+-----------------------------------------------------+
| NLRI AFI (2 octets) |
+-----------------------------------------------------+
| NLRI SAFI (2 octets) |
+-----------------------------------------------------+
| Reserved Field (2 octets) |
+-----------------------------------------------------+
| Nexthop AFI - 1 (2 octets) |
+-----------------------------------------------------+
| Nexthop SAFI - 1 (2 octets) |
+-----------------------------------------------------+
| ..... |
+-----------------------------------------------------+
| Nexthop AFI - n (2 octets) |
+-----------------------------------------------------+
| Nexthop SAFI - n (2 octets) |
+-----------------------------------------------------+
| |
| ..... |
+-----------------------------------------------------+
| NLRI AFI (2 octets) |
+-----------------------------------------------------+
| NLRI SAFI (2 octet) |
+-----------------------------------------------------+
| Reserved Field (2 octets) |
+-----------------------------------------------------+
| Nexthop AFI - 1 (2 octets) |
draft-nalawade-bgp-update-v2-00.txt [Page 4]
Internet Draft draft-nalawade-bgp-update-v2-00.txt August 2003
+-----------------------------------------------------+
| Nexthop SAFI - 1 (2 octets) |
+-----------------------------------------------------+
| ..... |
+-----------------------------------------------------+
| Nexthop AFI - n (2 octets) |
+-----------------------------------------------------+
| Nexthop SAFI - n (2 octets) |
+-----------------------------------------------------+
NLRI AFI/SAFI indicates the NLRIs to be expected in UPDATE-v2
message, followed by a list of nexthop AFI/SAFI indicating the
nexthop type supported by the NLRI AFI/SAFI.
Once peers exchange UPDATE-v2 capability, they should use UPDATE-v2
to exchange BGP updates. If, after exchanging UPDATE-v2 capability, a
peer receives the older UPDATE message, then it should signal an
error notification to the peer.
For peers that support [BGP-SOFT], a BGPv4 Soft-Notification Message
should be sent back to the peer with a Error Code Update and sub-code
Invalid Message Type. For peers that dont support [BGP-SOFT] the BGP
Speaker may reset the session with the peer with Error Code Update
Message Error and a new Error Sub-code Invalid Message Type.
5. Future Directions
There is a potential opportunity to cleanup encodings and add more
flexibility and robustness to BGPv4. There is an opportunity to
redefine the encodings for BGP attributes that contain or depend upon
IPv4 Unicast addresses, and to make them SAFI-aware. There is also an
opportunity to create a SAFI-specific attribute-space for attributes
that are specific to a SAFI.
6. Deployment considerations
This draft does not affect the deployment considerations for BGP.
7. Intellectual Property Considerations
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
draft-nalawade-bgp-update-v2-00.txt [Page 5]
Internet Draft draft-nalawade-bgp-update-v2-00.txt August 2003
standards- related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementers or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
8. Security Considerations
This extension to BGP does not change the underlying security issues.
9. Acknowledgements
The authors would like to thank Keyur Patel, Bob Albrightson, Barry
Friedman and Arjun Sreekantiah for their inputs and feedback.
10. Normative References
[IANA-AFI] http://www.iana.org/assignments/address-family-numbers
[IANA-SAFI] http://www.iana.org/assignments/safi-namespace
[BGP-4] Rekhter, Y. and T. Li (editors), "A Border Gateway Protocol
4 (BGP-4)", Internet Draft draft-ietf-idr-bgp4-21.txt, March 2004.
[BGP-CAP] Chandra, R., Scudder, J., "Capabilities Advertisement with
BGP-4", draft-ietf-idr-rfc2842bis-02.txt, April 2002.
[BGP-MP_NHOP] LeFausher, F., Tappan D., Nalawade, G., "BGPv4
Multiprotocol NEXTHOP", draft-lefaucher-bgp-mp-nexthop-01.txt, August
2002.
[BGP-SOFT] Nalawade, G., Patel, K., Scudder, J., Ward, D., "BGPv4
SOFT-NOTIFICATION Message", draft-nalawade-bgp-soft-notify-00.txt,
April 2004.
11. Author's Addresses
Gargi Nalawade mailto:gargi@cisco.com
Himanshu Shah mailto:hhshah@cisco.com
draft-nalawade-bgp-update-v2-00.txt [Page 6]
Internet Draft draft-nalawade-bgp-update-v2-00.txt August 2003
Cisco Systems, Inc 170 West Tasman Drive San Jose, CA 95134
12. Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this doc-
ument itself may not be modified in any way, such as by removing the
copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of develop-
ing Internet standards in which case the procedures for copyrights
defined in the Internet Standards process must be followed, or as
required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER-
CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
draft-nalawade-bgp-update-v2-00.txt [Page 7]