doc: Add RFC documents

1 files changed, 339 insertions, 0 deletions

diff --git a/doc/rfc/rfc8050.txt b/doc/rfc/rfc8050.txt
new file mode 100644
index 0000000..0ba2ebb
--- /dev/null
+++ b/doc/rfc/rfc8050.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                         C. Petrie
+Request for Comments: 8050                                      RIPE NCC
+Category: Standards Track                                        T. King
+ISSN: 2070-1721                                                   DE-CIX
+                                                                May 2017
+
+
+ Multi-Threaded Routing Toolkit (MRT) Routing Information Export Format
+                  with BGP Additional Path Extensions
+
+Abstract
+
+   This document extends the Multi-threaded Routing Toolkit (MRT) export
+   format for Border Gateway Protocol (BGP) routing information by
+   supporting the advertisement of multiple paths in BGP extensions.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc8050.
+
+Copyright Notice
+
+   Copyright (c) 2017 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+
+
+
+
+Petrie & King                Standards Track                    [Page 1]
+
+RFC 8050            Additional Path Extensions in MRT           May 2017
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
+   2.  Rationale . . . . . . . . . . . . . . . . . . . . . . . . . .   2
+   3.  MRT Subtypes for Types BGP4MP/BGP4MP_ET . . . . . . . . . . .   3
+   4.  MRT Subtypes for Type TABLE_DUMP_V2 . . . . . . . . . . . . .   3
+     4.1.  AFI/SAFI-Specific RIB Subtypes  . . . . . . . . . . . . .   4
+     4.2.  RIB_GENERIC_ADDPATH Subtype . . . . . . . . . . . . . . .   4
+   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
+     5.1.  BGP4MP/BGP4MP_ET Subtype Codes  . . . . . . . . . . . . .   5
+     5.2.  TABLE_DUMP_V2 Subtype Codes . . . . . . . . . . . . . . .   5
+   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
+   7.  Normative References  . . . . . . . . . . . . . . . . . . . .   6
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6
+
+1.  Introduction
+
+   The MRT record format [RFC6396] was developed to provide researchers
+   and engineers a means to encapsulate, export, and archive routing
+   protocol transactions and RIB snapshots.
+
+   The Advertisement of Multiple Paths in BGP [RFC7911] defines a BGP
+   extension to allow the advertisement of multiple paths for the same
+   address prefix without the new paths implicitly replacing any
+   previous ones.
+
+   This document contains an optional extension to the MRT format
+   [RFC6396] and introduces additional definitions of MRT subtype fields
+   to permit representation of multiple path advertisements [RFC7911].
+
+2.  Rationale
+
+   MRT parsers are usually stateless.  In order to parse BGP messages
+   that contain data structures that depend on the capabilities
+   negotiated during the BGP session setup, the MRT subtypes are
+   utilized.  The Advertisement of Multiple Paths [RFC7911] extension
+   for BGP alters the encoding of the BGP Network Layer Reachability
+   Information (NLRI) format for withdraws and announcements.
+   Therefore, new BGP4MP/BGP4MP_ET subtypes as defined in [RFC6396] are
+   required to signal to an MRT parser how to parse the NLRI.
+
+   In Section 4.3 of the MRT specification [RFC6396], RIB subtypes are
+   specified.  Prefix length and prefix fields are encoded in the same
+   manner as the BGP NLRI encoding.  In order to support Path Identifier
+   information as defined in [RFC7911], new subtypes need to be added.
+
+   The following two sections define the required subtypes.
+
+
+
+
+Petrie & King                Standards Track                    [Page 2]
+
+RFC 8050            Additional Path Extensions in MRT           May 2017
+
+
+3.  MRT Subtypes for Types BGP4MP/BGP4MP_ET
+
+   This document defines the following new subtypes:
+
+   o  BGP4MP_MESSAGE_ADDPATH
+
+   o  BGP4MP_MESSAGE_AS4_ADDPATH
+
+   o  BGP4MP_MESSAGE_LOCAL_ADDPATH
+
+   o  BGP4MP_MESSAGE_AS4_LOCAL_ADDPATH
+
+   The fields of these message types are identical to the equivalent
+   non-additional-path versions specified in Section 4.4 of [RFC6396].
+   These enhancements continue to encapsulate the entire BGP message in
+   the BGP message field.
+
+4.  MRT Subtypes for Type TABLE_DUMP_V2
+
+   This document defines the following new subtypes:
+
+   o  RIB_IPV4_UNICAST_ADDPATH
+
+   o  RIB_IPV4_MULTICAST_ADDPATH
+
+   o  RIB_IPV6_UNICAST_ADDPATH
+
+   o  RIB_IPV6_MULTICAST_ADDPATH
+
+   o  RIB_GENERIC_ADDPATH
+
+   The fields of these message types are identical to the equivalent
+   non-additional-path versions specified in Section 4.3 of [RFC6396].
+   However, for the case of the 4 AFI/SAFI-specific RIB subtypes, the
+   existing RIB Entries field is redefined as detailed in the sections
+   below.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Petrie & King                Standards Track                    [Page 3]
+
+RFC 8050            Additional Path Extensions in MRT           May 2017
+
+
+4.1.  AFI/SAFI-Specific RIB Subtypes
+
+   In order to preserve the record compaction achieved by using the most
+   common subtypes and allow multiple RIB Entries to be stored in a
+   single TABLE_DUMP_V2 record, the existing RIB Entries field is
+   redefined for use within the new AFI/SAFI-specific RIB subtypes
+   defined by this document as follows:
+
+        0                   1                   2                   3
+        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |         Peer Index            |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |                         Originated Time                       |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |                         Path Identifier                       |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |      Attribute Length         |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |                    BGP Attributes... (variable)
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+       Figure 1: RIB Entries for AFI/SAFI-Specific RIB Subtypes with
+                       Support for Additional Paths
+
+   This adds a field to the RIB Entries record to store the Path
+   Identifier when used with the RIB_IPV4_UNICAST_ADDPATH,
+   RIB_IPV4_MULTICAST_ADDPATH, RIB_IPV6_UNICAST_ADDPATH, and
+   RIB_IPV6_MULTICAST_ADDPATH subtypes.
+
+4.2.  RIB_GENERIC_ADDPATH Subtype
+
+   The fields of this subtype are identical to the equivalent non-
+   additional-path versions specified in Section 4.3.3 of [RFC6396].
+   These fields continue to encapsulate the raw and additional-path-
+   enabled AFI/SAFI/NLRI in the record, and the raw attributes in the
+   RIB Entries.
+
+   For clarity, the RIB Entries in this subtype are not redefined.
+
+
+
+
+
+
+
+
+
+
+
+
+Petrie & King                Standards Track                    [Page 4]
+
+RFC 8050            Additional Path Extensions in MRT           May 2017
+
+
+5.  IANA Considerations
+
+   IANA has assigned the subtype codes defined below in the "Multi-
+   threaded Routing Toolkit (MRT)" registry
+   <https://www.iana.org/assignments/mrt>.
+
+5.1.  BGP4MP/BGP4MP_ET Subtype Codes
+
+   The following have been registered in the "BGP4MP Subtype Codes" and
+   "BGP4MP_ET Subtype Codes" registries:
+
+      8 BGP4MP_MESSAGE_ADDPATH (RFC 8050)
+
+      9 BGP4MP_MESSAGE_AS4_ADDPATH (RFC 8050)
+
+      10 BGP4MP_MESSAGE_LOCAL_ADDPATH (RFC 8050)
+
+      11 BGP4MP_MESSAGE_AS4_LOCAL_ADDPATH (RFC 8050)
+
+5.2.  TABLE_DUMP_V2 Subtype Codes
+
+   The following have been registered in the "TABLE_DUMP_V2 Subtype
+   Codes" registry:
+
+      8 RIB_IPV4_UNICAST_ADDPATH (RFC 8050)
+
+      9 RIB_IPV4_MULTICAST_ADDPATH (RFC 8050)
+
+      10 RIB_IPV6_UNICAST_ADDPATH (RFC 8050)
+
+      11 RIB_IPV6_MULTICAST_ADDPATH (RFC 8050)
+
+      12 RIB_GENERIC_ADDPATH (RFC 8050)
+
+6.  Security Considerations
+
+   It is not believed that this document adds any additional security
+   considerations.  However, the security considerations of [RFC6396]
+   are equally applicable to this document, because this document
+   permits the export of more detailed routing data.
+
+   An organization that uses the MRT format to store their BGP routing
+   information should be aware that supporting these extensions permits
+   more detailed network path information to be stored and should
+   consider the implications of this within their environment.
+
+
+
+
+
+
+Petrie & King                Standards Track                    [Page 5]
+
+RFC 8050            Additional Path Extensions in MRT           May 2017
+
+
+   An organization that peers with public BGP collectors and enables the
+   capability for additional paths on a peering session should be aware
+   that it is exporting not only its best paths, but potentially other
+   paths within its networks.  The BGP peer should consider any and all
+   implications of exposing this additional data.
+
+7.  Normative References
+
+   [RFC6396]  Blunk, L., Karir, M., and C. Labovitz, "Multi-Threaded
+              Routing Toolkit (MRT) Routing Information Export Format",
+              RFC 6396, DOI 10.17487/RFC6396, October 2011,
+              <http://www.rfc-editor.org/info/rfc6396>.
+
+   [RFC7911]  Walton, D., Retana, A., Chen, E., and J. Scudder,
+              "Advertisement of Multiple Paths in BGP", RFC 7911,
+              DOI 10.17487/RFC7911, July 2016,
+              <http://www.rfc-editor.org/info/rfc7911>.
+
+Authors' Addresses
+
+   Colin Petrie
+   RIPE NCC
+   Stationsplein 11
+   Amsterdam  1012 AB
+   The Netherlands
+
+   Email: cpetrie@ripe.net
+
+
+   Thomas King
+   DE-CIX Management GmbH
+   Lichtstrasse 43i
+   Cologne  50825
+   Germany
+
+   Email: thomas.king@de-cix.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Petrie & King                Standards Track                    [Page 6]
+