Movatterモバイル変換

Internet Engineering Task Force (IETF)                         C. PetrieRequest for Comments: 8050                                      RIPE NCCCategory: Standards Track                                        T. KingISSN: 2070-1721                                                   DE-CIX                                                                May 2017Multi-Threaded Routing Toolkit (MRT) Routing Information Export Formatwith BGP Additional Path ExtensionsAbstract   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 inSection 2 of RFC 7841.   Information about the current status of this document, any errata,   and how to provide feedback on it may be obtained athttp://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 toBCP 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 2017Table of Contents1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .22.  Rationale . . . . . . . . . . . . . . . . . . . . . . . . . .23.  MRT Subtypes for Types BGP4MP/BGP4MP_ET . . . . . . . . . . .34.  MRT Subtypes for Type TABLE_DUMP_V2 . . . . . . . . . . . . .34.1.  AFI/SAFI-Specific RIB Subtypes  . . . . . . . . . . . . .44.2.  RIB_GENERIC_ADDPATH Subtype . . . . . . . . . . . . . . .45.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .55.1.  BGP4MP/BGP4MP_ET Subtype Codes  . . . . . . . . . . . . .55.2.  TABLE_DUMP_V2 Subtype Codes . . . . . . . . . . . . . . .56.  Security Considerations . . . . . . . . . . . . . . . . . . .57.  Normative References  . . . . . . . . . . . . . . . . . . . .6   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .61.  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.   InSection 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 20173.  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 inSection 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 inSection 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 20174.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 inSection 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 20175.  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.netPetrie & King                Standards Track                    [Page 6]