GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc8050

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc8050.txt · Last modified: 2017/05/20 04:13 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki