Internet DRAFT - draft-raszuk-lsr-imp
draft-raszuk-lsr-imp
LSR Working Group R. Raszuk, Ed.
Internet-Draft NTT NI
Intended status: Standards Track 8 July 2022
Expires: 9 January 2023
IGP Monitoring Protocol (IMP)
draft-raszuk-lsr-imp-00
Abstract
This document defines a new point to point protocol to carry
information present in link state database of OSPF and ISIS Interior
Gateway Protocols (IGPs) as well as in Traffic Engineering Database
(TED).
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on 9 January 2023.
Copyright Notice
Copyright (c) 2022 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 (https://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
Raszuk Expires 9 January 2023 [Page 1]
Internet-Draft IMP July 2022
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3
3. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Common Header . . . . . . . . . . . . . . . . . . . . . . . . 4
5. DATA Message . . . . . . . . . . . . . . . . . . . . . . . . 5
6. REQUEST Message . . . . . . . . . . . . . . . . . . . . . . . 7
7. FILTER Message . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. FILTER TLVs . . . . . . . . . . . . . . . . . . . . . . . 8
8. Handling multiple IGP instances . . . . . . . . . . . . . . . 9
9. Deployment and operational considerations . . . . . . . . . . 10
10. Capability Advertisement . . . . . . . . . . . . . . . . . . 10
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
11.1. IMP Message Types . . . . . . . . . . . . . . . . . . . 10
11.2. DATA Types . . . . . . . . . . . . . . . . . . . . . . . 11
11.3. FILTER TLV Types . . . . . . . . . . . . . . . . . . . . 11
12. Security Considerations . . . . . . . . . . . . . . . . . . . 12
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
14. Normative References . . . . . . . . . . . . . . . . . . . . 12
15. Informative References . . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction
With the growing number of network programmability and central
control there is an increased need to share topology, link and node
information from each IGP area. Such requirements traditionally were
fulfilled by establishing an IGP adjacency between such central
entities and selected nodes in each area. Often that adjacency was
established over a tunnel interface.
In recent years selected link state and TE information have been
carried by BGP4 extension called BGP-LS [RFC7752]. However with the
growing number of IGP extensions, application aware networking (APN),
new per node network actions and ongoing link state protocols
extensions load of BGP-LS on BGP protocol development, testing and
deployments keeps increasing. Moreover BGP is a point-to-multipoint
protocol which does not make it a good fit to propagate point-to-
point information.
Raszuk Expires 9 January 2023 [Page 2]
Internet-Draft IMP July 2022
In addition to the above requirements IGP Monitoring Protocol should
provide ability to simplify operations of the network and assist when
enhanced troubleshooting is required. The below proposal addresses
that requirement as well.
The primary inspiration for this work has been based on the success
of BGP Monitoring Protocol (BMP) [RFC7854] which in a number of
aspects shares the same high level requirements - point to point
routing information distribution, protocol observability and enhanced
operations. It also needs to be highlighted that BMP (while it
technically could) does not use native BGP sessions to propagate such
information, but is running a separate transport. IMP authors have
chosen to reuse selected BMP building blocks and BMP operational and
deployment experience.
2. Terminology
2.1. Abbreviations
* IGP - Interior Gateway Protocol
* LSDB - Links State Database
* TED - Traffic Engineering Database
* OSPF - Open Shortest Path First
* ISIS - Intermediate System to Intermediate System Protocol
* SPAN - Switched Port Analyzer
* YANG - Yet Another Next Generation
* DBD - Database Description
* CSNP - Complete Sequence Number PDU
* PSNP - Partial Sequence Number PDU
* TLV - Type Length Value
* LSA - Link State Advertisement
* LSP - Link State PDU
* PDU - Protocol Data Unit
* QUIC - Quick UDP Internet Connections
3. Transport
IGP Monitoring Protocol messages can be transported over either TCP
session or UDP based QUIC transport [RFC9000]. The use of QUIC
protocol is recommended however for backwards compatibility with
existing deployments of BGP-LS [RFC7752] use of TCP session can also
be leveraged.
Irrespective of the choice of transport layer the IMP messages would
remain identical.
TCP session SHOULD be configured with TCP AO and QUIC SHOULD be used
with its native security.
Raszuk Expires 9 January 2023 [Page 3]
Internet-Draft IMP July 2022
IMP operates in point-to-point mode. What information is sent can be
either configured statically or learned dynamically in a PUB-SUB
fashion.
IMP protocol operates between two nodes: Producer and Receiver. The
ultimate destination can be many Producer-Receiver hops away. The
following modes of operations are independently permitted for each
data type:
* MODE "A" - PUSH - Only IMP DATA messages containing given data
type(s) are sent only from Producer to Receiver(s). What is being
sent is subject to local configuration on the Producer. No
filtering is permitted on the Producer.
* MODE "B" - F_PUSH - IMP DATA messages are sent from Producer to
Receiver. Receiver may request a subset of data types by sending
FILTER message(s) to the Producer. Producer may honor that filter
or drop it.
* MODE "C" - PUB-SUB - Before any DATA messages are sent from
Producer, Receiver MUST register interest in specific data type(s)
by sending REQUEST messages.
* MODE "D" F_PUB-SUB - MODE "C" with subset of data as communicated
by Receiver in sending FILTER message(s).
4. Common Header
The below common header will appear in all IMP messages.
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
+-+-+-+-+-+-+-+-+
| Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Msg. Type |
+---------------+
Figure 1: IMP Common Header
* o Version (1 byte): Indicates the IMP version. This is set to '1'
for all messages defined in this specification. Versions 0 and
255 are reserved and MUST NOT be used.
Raszuk Expires 9 January 2023 [Page 4]
Internet-Draft IMP July 2022
* o Message Length (4 bytes): Length of the message in bytes
(including common header, data, and encapsulated messages, if
any).
* o Message Type (1 byte): This identifies the type of the IMP
message. An IMP implementation MUST ignore unrecognized message
types upon receipt. This document defines the following type
codes:
* 1 - DATA
* 2 - REQUEST
* 3 - FILTER
5. DATA Message
IMP can carry different types of protocol and local system data. All
types of DATA Messages are propagated from Producer to Receiver(s).
Except DATA Type 1 all other DATA Types are optional. All DATA Types
are subject to both implementation exposure and operator's
permission.
The following figure illustrates DATA Message Header:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DATA Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Data (variable) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: IMP DATA Message Header
Router Identifier - Producer's 4 octet Router ID to uniquly identify
the sender data. For ISIS if 4 octet Router ID is not configured
IPv4 address of lowest loopback interface SHOULD be used.
DATA Type - The below list of DATA Types are defined by this
specification. DATA Type 0x0000 and 0xFFFF are reserved for special
use.
Raszuk Expires 9 January 2023 [Page 5]
Internet-Draft IMP July 2022
IMP specification focuses on propagating information carried in link
state protocols along with any extensions. The base specifications
for protocols are: OSPFv2 [RFC2328], OSPFv3 [RFC5340] and ISIS
[RFC1195].
* DATA Type 1 - BGP-LS NLRI of AFI 16388 SAFI 71
* DATA Type 2 - BGP-LS NLRI of AFI 16388 SAFI 72
* DATA Type 3 - OSPFv2 native LSDB Synchronization using DBDs
* DATA Type 4 - OSPFv3 native LSDB Synchronization using DBDs
* DATA Type 5 - ISIS native LSDB Synchronization using CSNPs
* DATA Type 6 - ISIS native LSDB Synchronization using PSNPs
* DATA Type 7 - OSPFv2 LSDB Content - YANG model
* DATA Type 8 - OSPFv3 LSDB Content- YANG model
* DATA Type 9 - ISIS LSDB Content - YANG model
* DATA Type 10 - OSPFv2 and OSPFv3 packets inbound mirroring
* DATA Type 11 - OSPFv2 and OSPFv3 packets onbound mirroring
* DATA Type 12 - ISIS PDUs inbound mirroring
* DATA Type 13 - ISIS PDUs outbound mirroring
* DATA Type 14 - OSPFv2 configuration - XML format
* DATA Type 15 - OSPFv2 configuration - JSON format
* DATA Type 16 - OSPFv3 configuration - XML format
* DATA Type 17 - OSPFv3 configuration - JSON format
* DATA Type 18 - ISIS configuration - XML format
* DATA Type 19 - ISIS configuration - JSON format
An implementation MAY provide means to apply additional filtering to
send only subset of DATA Types or fields within specific DATA Type.
An implementation MAY provide facilities to define thresholds where a
given type of information may be sent immediately or could be sent
with predefined delay only when the absolute value contained exceeds
threshold.
For DATA Types containing BGP-LS data the encoding is identical to
what is defined in the main BGP-LS specification [RFC7752] and all
extensions. The nature of data is incremental and only changes are
propagated.
Native LSBD synchronization the data block follows frequency of
identical data sent to any neighbour.
Structured DATA Types using YANG, XML or JSON encoding first data
block should contain the entire dataset followed by incremental
updates only when changes occur.
Raszuk Expires 9 January 2023 [Page 6]
Internet-Draft IMP July 2022
Raw DATA Types are asynchronous by design and reflect what protocol
communication takes place on a given interface(es).
6. REQUEST Message
REQUEST Message is an optional IMP message allowing Receiver to list
what DATA Types it is interested in receving. The following figure
illustrates REQUEST Message type:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1-N DATA Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: IMP REQUEST Message Header
Receiver Identifier - Receiver's domain wide unique 4 octet
identifier.
Enumerated DATA Types included in REQUEST Message payload indicate to
the Producer which DATA Types Receiver is subscribing to.
REQUEST Message containing DATA Type 0x0000 indicates unsubscription
from any DATA Types.
Each non-empty consecutive REQUEST Message received from a given
Receiver is an implicit withdrawal of any previously received
subscription. It is also an explicit overwrite of any locally
configured permit policy.
The size of valid REQUEST Message including Common Header is 10+(N*2)
octets where N >= 1.
7. FILTER Message
FILTER Message is an optional IMP message allowing Receiver to send
additional set of filters to what subset of specific protocol
messages within DATA Types it is interested in receiving. The
following figure illustrates FILTER Message type:
Raszuk Expires 9 January 2023 [Page 7]
Internet-Draft IMP July 2022
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DATA Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1-N FILTER TLVs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: IMP FILTER Message Header
Receiver Identifier - Receiver's domain wide unique 4 octet
identifier.
DATA Types included in FILTER Message indicate to which DATA Types
enclosed filter TLVs apply.
Minimal FILTER Message size including Common Header is 12 octets (no
FILTER TLVs is included). Meaning of such message is removal of all
previously advertised filters for a given DATA Type.
Each non-empty consecutive FILTER Message received from a given
Receiver is an implicit withdrawal of any previously received
subscription. TLVs sent are replacing any previously sent FILTERS
for a given DATA Type.
Filter TLVs are scoped and their structure depends on the DATA Type
they are to filter. Presence of multiple TLVs in a FILTER Message is
a logical AND. A single FILTER message may contain Filter TLVs of
multiple types.
7.1. FILTER TLVs
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value (Variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: IMP FILTER TLV
* TLV Type: Fixed two octet number indicating name of the defined
TLV
Raszuk Expires 9 January 2023 [Page 8]
Internet-Draft IMP July 2022
* Length: Fixed two octet length of the TLV including its header in
octets
* Value: Variable size in multiplication of octets containing the
filter value
The following Filter TLVs are defined in this document. Definition
of more Filter TLVs may be added in this or any future
specificiations.
* Type 1: BGP-LS NLRI Type
* Length: 5 octets
* Value: 1 octet - IANA Registry: BGP-LS NLRI-Types
* Applicability: DATA Type 1, DATA Type 2
* Type 2: BGP-LS Descriptors
* Length: 6 octets
* Value: 2 octet - IANA Registry: BGP-LS Node Descriptor, Link
Descriptor, Prefix Descriptor, and Attribute TLVs
* Applicability: DATA Type 1, DATA Type 2
* Type 3: OSPFv2 DBD LS Type
* Length: 5 octets
* Value: 1 octet - IANA Registry: OSPFv2 Link State (LS) Type
* Applicability: DATA Types: 3, 7, 10, 11
* Type 4: OSPFv3 DBD LSA Function Codes
* Length: 6 octets
* Value: 2 octet - IANA Registry: OSPFv3 LSA Function Codes
* Applicability: DATA Types: 4, 8, 10, 11
* Type 5: ISIS Top-Level TLV Codepoints
* Length: 6 octets
* Value: 2 octet - IANA Registry: IS-IS Top-Level TLV Codepoints
* Applicability: DATA Types: 5, 6, 9, 12, 13
8. Handling multiple IGP instances
Network elements may support multiple instances of IGP protocols.
The IMP Messages as defined in this specification are applicable to a
single IGP instance. When multiple IGP instances are enabled each
should maintain a separate IMP session. In such cases each instance
also should identify itself with a different 4 octet Router-ID.
Raszuk Expires 9 January 2023 [Page 9]
Internet-Draft IMP July 2022
9. Deployment and operational considerations
While the specification defines protocol to operate between two nodes
a given deployment may operate across more then two nodes. An IMP
node may act as Producer's proxy. In such a scenario the same node
can act as Receiver on one side and as Producer for other Receiver(s)
on the other one. Different TCP ports MAY be used on a per session
basis.
The focus of IMP is to feed operational data to network controllers
and assist in network monitoring, analysis and debugging. But is it
also directly possible to share information about the state of nodes
and/or links from a given area to other areas in a form of unicast
instead of using native IGP flooding. This is especially interesting
when information shared is required by a subset of routers in other
areas. For example, indication of node down events can be propagated
using IMP to any other interested nodes. For scalability use of one
or more Producer's proxies is recommended.
When an IMP Producer receives an unrecognized message or unrecognized
type such message SHOULD be ignored and error notification sent to
system log. Currently authors purposely did not extend the protocol
with a separate ERROR Message to communicate back to the Receiver the
unrecognized part of the REQUEST or FILTER Message.
When an IMP Receiver detects an unrecognized part of DATA Message it
should log it locally and if possible continue parsing the remaining
data.
10. Capability Advertisement
This document does not require any new capability to be defined.
11. IANA Considerations
This document defines a new IGP Monitoring Protocol (IMP) and it is
expected that IANA creates a new group as well as a number of
following registries to maintain its parameters.
11.1. IMP Message Types
This document defines 1 octet IMP message types to be tracked by IMP
Message Type Registry. Currently three values are defined:
* 1 - DATA
* 2 - REQUEST
* 3 - FILTER
Raszuk Expires 9 January 2023 [Page 10]
Internet-Draft IMP July 2022
Values 0 and 255 are to be marked as Reserved. Type values 1 through
127 MUST be assigned using the "Standards Action" policy, and values
128 through 250 using the "Specification Required" policy defined in
[RFC5226]. Values 251 through 254 are Experimental.
11.2. DATA Types
This document defines two octet DATA Types to be tracked by IMP DATA
Types Registry. Currently nighteen values are defined:
* DATA Type 1 - BGP-LS NLRI of AFI 16388 SAFI 71
* DATA Type 2 - BGP-LS NLRI of AFI 16388 SAFI 72
* DATA Type 3 - OSPFv2 native LSDB Synchronization using DBDs
* DATA Type 4 - OSPFv3 native LSDB Synchronization using DBDs
* DATA Type 5 - ISIS native LSDB Synchronization using CSNPs
* DATA Type 6 - ISIS native LSDB Synchronization using PSNPs
* DATA Type 7 - OSPFv2 LSDB Content - YANG model
* DATA Type 8 - OSPFv3 LSDB Content- YANG model
* DATA Type 9 - ISIS LSDB Content - YANG model
* DATA Type 10 - OSPFv2 and OSPFv3 packets inbound mirroring
* DATA Type 11 - OSPFv2 and OSPFv3 packets onbound mirroring
* DATA Type 12 - ISIS PDUs inbound mirroring
* DATA Type 13 - ISIS PDUs outbound mirroring
* DATA Type 14 - OSPFv2 configuration - XML format
* DATA Type 15 - OSPFv2 configuration - JSON format
* DATA Type 16 - OSPFv3 configuration - XML format
* DATA Type 17 - OSPFv3 configuration - JSON format
* DATA Type 18 - ISIS configuration - XML format
* DATA Type 19 - ISIS configuration - JSON format
Values 0 and 65535 are to be marked as Reserved. Type values 1
through 32767 MUST be assigned using the "Standards Action" policy,
and values 32768 through 65530 using the "Specification Required"
policy defined in [RFC5226]. Values 65531 through 65534 are
Experimental.
11.3. FILTER TLV Types
IANA is to allocate FILTER TLV Types Registry.
This document defines two octet FILTER TLV Types to be tracked by IMP
FILTER TLV Types Registry. Currently five values are defined:
* Type 1: BGP-LS NLRI Type
* Type 2: BGP-LS Descriptors
* Type 3: OSPFv2 DBD LS Type
* Type 4: OSPFv3 DBD LSA Function Codes
* Type 5: ISIS Top-Level TLV Codepoints
Raszuk Expires 9 January 2023 [Page 11]
Internet-Draft IMP July 2022
Values 0 and 65535 are to be marked as Reserved. Type values 1
through 32767 MUST be assigned using the "Standards Action" policy,
and values 32768 through 65530 using the "Specification Required"
policy defined in [RFC5226]. Values 65531 through 65534 are
Experimental.
12. Security Considerations
This document defines a new method to obtain link state protocol data
from network elements. The protocol defines a number of deployment
scenarios, however critical network infrastructure is not expected to
support all of them. Their role should be limited to export
information to a minimal number of Receivers. It is the Receiver
which can further filter the available information (acting as
Producer's proxies) and share further optionally in PUB-SUB mode to
interested parties.
Due to the very sensitive nature of the link state data IMP sessions
MUST either be authenticated (TCP-A0) or native protocol security
enabled (QUIC).
The allowed peers to exchange IMP messages SHOULD be explicitly
configured.
In cases where TCP is used the listening port is subject to a local
configuration by the operator to even further make it not a well
known attack target.
In deployments where the security considerations outlined above are
still a concern, users of this protocol should use IPsec [RFC4303] in
tunnel mode with pre-shared keys.
13. Acknowledgements
....
14. Normative References
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", RFC 1195, DOI 10.17487/RFC1195,
December 1990, <https://www.rfc-editor.org/info/rfc1195>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
Raszuk Expires 9 January 2023 [Page 12]
Internet-Draft IMP July 2022
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,
DOI 10.17487/RFC2328, April 1998,
<https://www.rfc-editor.org/info/rfc2328>.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
<https://www.rfc-editor.org/info/rfc5340>.
[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and
S. Ray, "North-Bound Distribution of Link-State and
Traffic Engineering (TE) Information Using BGP", RFC 7752,
DOI 10.17487/RFC7752, March 2016,
<https://www.rfc-editor.org/info/rfc7752>.
15. Informative References
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005,
<https://www.rfc-editor.org/info/rfc4303>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<https://www.rfc-editor.org/info/rfc5226>.
[RFC7854] Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP
Monitoring Protocol (BMP)", RFC 7854,
DOI 10.17487/RFC7854, June 2016,
<https://www.rfc-editor.org/info/rfc7854>.
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/info/rfc9000>.
Author's Address
Robert Raszuk (editor)
NTT NI
Email: robert@raszuk.net
Raszuk Expires 9 January 2023 [Page 13]
