< draft-ietf-grow-bmp-adj-rib-out-05.txt.orig | draft-ietf-grow-bmp-adj-rib-out-05.txt > | |||
---|---|---|---|---|
skipping to change at page 2, line 31 ¶ | skipping to change at page 2, line 31 ¶ | |||
6.1. Route Monitoring and Route Mirroring . . . . . . . . . . 5 | 6.1. Route Monitoring and Route Mirroring . . . . . . . . . . 5 | |||
6.2. Statistics Report . . . . . . . . . . . . . . . . . . . . 5 | 6.2. Statistics Report . . . . . . . . . . . . . . . . . . . . 5 | |||
6.3. Peer Down and Up Notifications . . . . . . . . . . . . . 6 | 6.3. Peer Down and Up Notifications . . . . . . . . . . . . . 6 | |||
6.3.1. Peer Up Information . . . . . . . . . . . . . . . . . 6 | 6.3.1. Peer Up Information . . . . . . . . . . . . . . . . . 6 | |||
7. Other Considerations . . . . . . . . . . . . . . . . . . . . 6 | 7. Other Considerations . . . . . . . . . . . . . . . . . . . . 6 | |||
7.1. Peer and Update Groups . . . . . . . . . . . . . . . . . 6 | 7.1. Peer and Update Groups . . . . . . . . . . . . . . . . . 6 | |||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 | |||
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 | 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 | |||
9.1. BMP Peer Flags . . . . . . . . . . . . . . . . . . . . . 7 | 9.1. BMP Peer Flags . . . . . . . . . . . . . . . . . . . . . 7 | |||
9.2. BMP Statistics Types . . . . . . . . . . . . . . . . . . 7 | 9.2. BMP Statistics Types . . . . . . . . . . . . . . . . . . 7 | |||
9.3. Peer UP Information TLV . . . . . . . . . . . . . . . . . 8 | 9.3. Peer Up Information TLV . . . . . . . . . . . . . . . . . 8 | |||
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
10.1. Normative References . . . . . . . . . . . . . . . . . . 8 | 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 | |||
10.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 8 | 10.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 9 | Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 9 | Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
1. Introduction | 1. Introduction | |||
BGP Monitoring Protocol (BMP) defines monitoring of the received | BGP Monitoring Protocol (BMP) defines monitoring of the received | |||
(e.g. Adj-RIB-In) Routing Information Bases (RIBs) per peer. The | (e.g., Adj-RIB-In) Routing Information Bases (RIBs) per peer. The | |||
Adj-RIB-In pre-policy conveys to a BMP receiver all RIB data before | Adj-RIB-In pre-policy conveys to a BMP receiver all RIB data before | |||
any policy has been applied. The Adj-RIB-In post-policy conveys to a | any policy has been applied. The Adj-RIB-In post-policy conveys to a | |||
BMP receiver all RIB data after policy filters and/or modifications | BMP receiver all RIB data after policy filters and/or modifications | |||
have been applied. An example of pre-policy verses post-policy is | have been applied. An example of pre-policy verses post-policy is | |||
when an inbound policy applies attribute modification or filters. | when an inbound policy applies attribute modification or filters. | |||
Pre-policy would contain information prior to the inbound policy | Pre-policy would contain information prior to the inbound policy | |||
changes or filters of data. Post policy would convey the changed | changes or filters of data. Post policy would convey the changed | |||
data or would not contain the filtered data. | data or would not contain the filtered data. | |||
Monitoring the received updates that the router received before any | Monitoring the received updates that the router received before any | |||
policy has been applied is the primary level of monitoring for most | policy has been applied is the primary level of monitoring for most | |||
use-cases. Inbound policy validation and auditing is the primary | use-cases. Inbound policy validation and auditing is the primary | |||
use-case for enabling post-policy monitoring. | use-case for enabling post-policy monitoring. | |||
In order for a BMP receiver to receive any BGP data, the BMP sender | In order for a BMP receiver to receive any BGP data, the BMP sender | |||
(e.g. router) needs to have an established BGP peering session and | (e.g., router) needs to have an established BGP peering session and | |||
actively be receiving updates for an Adj-RIB-In. | actively be receiving updates for an Adj-RIB-In. | |||
Being able to only monitor the Adj-RIB-In puts a restriction on what | Being able to only monitor the Adj-RIB-In puts a restriction on what | |||
data is available to BMP receivers via BMP senders (e.g. routers). | data is available to BMP receivers via BMP senders (e.g., routers). | |||
This is an issue when the receiving end of the BGP peer is not | This is an issue when the receiving end of the BGP peer is not | |||
enabled for BMP or when it is not accessible for administrative | enabled for BMP or when it is not accessible for administrative | |||
reasons. For example, a service provider advertises prefixes to a | reasons. For example, a service provider advertises prefixes to a | |||
customer, but the service provider cannot see what it advertises via | customer, but the service provider cannot see what it advertises via | |||
BMP. Asking the customer to enable BMP and monitoring of the Adj- | BMP. Asking the customer to enable BMP and monitoring of the Adj- | |||
RIB- In is not feasible. | RIB-In is not feasible. | |||
This document updates the BGP Monitoring Protocol (BMP) RFC 7854 | This document updates the BGP Monitoring Protocol (BMP) RFC 7854 | |||
[RFC7854] peer header by adding a new flag to distinguish Adj-RIB-In | [RFC7854] peer header by adding a new flag to distinguish Adj-RIB-In | |||
verses Adj-RIB-Out. | verses Adj-RIB-Out. | |||
Adding Adj-RIB-Out provides the ability for a BMP sender to send to a | Adding Adj-RIB-Out provides the ability for a BMP sender to send to a | |||
BMP receiver what it advertises to BGP peers, which can be used for | BMP receiver what it advertises to BGP peers, which can be used for | |||
outbound policy validation and to monitor RIBs that were advertised. | outbound policy validation and to monitor routes that were advertised. | |||
2. Terminology | 2. Terminology | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
document are to be interpreted as described in RFC 2119 [RFC2119]. | "OPTIONAL" in this document are to be interpreted as described in BCP | |||
14 [RFC2119] [RFC8174] when, and only when, they appear in all | ||||
capitals, as shown here. | ||||
3. Definitions | 3. Definitions | |||
o Adj-RIB-Out: As defined in [RFC4271], "The Adj-RIBs-Out contains | o Adj-RIB-Out: As defined in [RFC4271], "The Adj-RIBs-Out contains | |||
the routes for advertisement to specific peers by means of the | the routes for advertisement to specific peers by means of the | |||
local speaker's UPDATE messages." | local speaker's UPDATE messages." | |||
o Pre-Policy Adj-RIB-Out: The result before applying the outbound | o Pre-Policy Adj-RIB-Out: The result before applying the outbound | |||
policy to an Adj-RIB-Out. This normally would match what is in the | policy to an Adj-RIB-Out. This normally would match what is in the | |||
local RIB. | local RIB. | |||
skipping to change at page 4, line 21 ¶ | skipping to change at page 4, line 21 ¶ | |||
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ | |||
|V|L|A|O| Resv | | |V|L|A|O| Resv | | |||
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ | |||
o The O flag indicates Adj-RIB-In if set to 0 and Adj-RIB-Out if set | o The O flag indicates Adj-RIB-In if set to 0 and Adj-RIB-Out if set | |||
to 1. | to 1. | |||
The existing flags are defined in section 4.2 [RFC7854] and the | The existing flags are defined in section 4.2 [RFC7854] and the | |||
remaining bits are reserved for future use. They SHOULD be | remaining bits are reserved for future use. They SHOULD be | |||
transmitted as 0 and their values MUST be ignored on receipt. The | transmitted as 0 and their values MUST be ignored on receipt. The | |||
following fields in Per-Peer Header are redefined: | following fields in the Per-Peer Header are redefined: | |||
o Peer Address: The remote IP address associated with the TCP | o Peer Address: The remote IP address associated with the TCP | |||
session over which the encapsulated PDU is sent. | session over which the encapsulated PDU is sent. | |||
o Peer AS: The Autonomous System number of the peer from which the | o Peer AS: The Autonomous System number of the peer from which the | |||
encapsulated PDU was sent. | encapsulated PDU was sent. | |||
o Peer BGP ID: The BGP Identifier of the peer from which the | o Peer BGP ID: The BGP Identifier of the peer from which the | |||
encapsulated PDU was sent. | encapsulated PDU was sent. | |||
5. Adj-RIB-Out | 5. Adj-RIB-Out | |||
5.1. Post-Policy | 5.1. Post-Policy | |||
The primary use-case in monitoring Adj-RIB-Out is to monitor the | The primary use-case in monitoring Adj-RIB-Out is to monitor the | |||
updates transmitted to the BGP peer after outbound policy has been | updates transmitted to a BGP peer after outbound policy has been | |||
applied. These updates reflect the result after modifications and | applied. These updates reflect the result after modifications and | |||
filters have been applied (e.g. Adj-RIB-Out Post-Policy). Some | filters have been applied (e.g., Adj-RIB-Out Post-Policy). Some | |||
attributes are set when the BGP message is transmitted, such as next- | attributes are set when the BGP message is transmitted, such as next- | |||
hop. Adj-RIB-Out Post-Policy MUST convey what is actually | hop. Adj-RIB-Out Post-Policy MUST convey what is actually | |||
transmitted to the peer, next-hop and any attribute set during | transmitted to the peer, next-hop and any attributes set during | |||
transmission should also be set and transmitted to the BMP receiver. | transmission should also be set and transmitted to the BMP receiver. | |||
The L flag MUST be set to 1 to indicate post-policy. | The L flag MUST be set to 1 to indicate post-policy. | |||
5.2. Pre-Policy | 5.2. Pre-Policy | |||
Similarly to Adj-RIB-In policy validation, pre-policy Adj-RIB-Out can | Similarly to Adj-RIB-In policy validation, pre-policy Adj-RIB-Out can | |||
be used to validate and audit outbound policies. For example, a | be used to validate and audit outbound policies. For example, a | |||
comparison between pre-policy and post-policy can be used to validate | comparison between pre-policy and post-policy can be used to validate | |||
the outbound policy. | the outbound policy. | |||
Depending on BGP peering session type (IBGP, IBGP route reflector | Depending on BGP peering session type (IBGP, IBGP route reflector | |||
client, EBGP, BGP confederations, Route Server Client) the candidate | client, EBGP, BGP confederation, Route Server Client) the candidate | |||
routes that make up the Pre-Policy Adj-RIB-Out do not contain all | routes that make up the Pre-Policy Adj-RIB-Out do not contain all | |||
local-rib routes. Pre-Policy Adj-RIB-Out conveys only routes that | local-rib routes. Pre-Policy Adj-RIB-Out conveys only routes that | |||
are available based on the peering type. Post-Policy represents the | are available based on the peering type. Post-Policy represents the | |||
filtered/changed routes from the available routes. | filtered/changed routes from the available routes. | |||
Some attributes are set only during transmission of the BGP message, | Some attributes are set only during transmission of the BGP message, | |||
ie. Post-Policy. It is common that next-hop may be null, loopback, | i.e., Post-Policy. It is common that next-hop may be null, loopback, | |||
or similar during this phase. All mandatory attributes, such as | or similar during this phase. All mandatory attributes, such as | |||
next-hop, MUST be either ZERO or have an empty length if they are | next-hop, MUST be either ZERO or have an empty length if they are | |||
unknown at the Pre-Policy phase. The BMP receiver will treat zero or | unknown at the Pre-Policy phase completion. The BMP receiver will | |||
empty mandatory attributes as self originated. | treat zero or empty mandatory attributes as self-originated. | |||
The L flag MUST be set to 0 to indicate pre-policy. | The L flag MUST be set to 0 to indicate pre-policy. | |||
6. BMP Messages | 6. BMP Messages | |||
Many BMP messages have a per-peer header but some are not applicable | Many BMP messages have a per-peer header but some are not applicable | |||
to Adj-RIB-In or Adj-RIB-Out monitoring. Unless otherwise defined, | to Adj-RIB-In or Adj-RIB-Out monitoring. Unless otherwise defined, | |||
the O flag should be set to 0 in the per-peer header in BMP messages. | the O flag should be set to 0 in the per-peer header in BMP messages. | |||
6.1. Route Monitoring and Route Mirroring | 6.1. Route Monitoring and Route Mirroring | |||
The O flag MUST be set accordingly to indicate if the route monitor | The O flag MUST be set accordingly to indicate if the route monitor | |||
or route mirroring message conveys Adj-RIB-In or Adj-RIB-Out. | or route mirroring message conveys Adj-RIB-In or Adj-RIB-Out. | |||
6.2. Statistics Report | 6.2. Statistics Report | |||
Statistics report message has Stat Type field to indicate the | The Statistics report message has a Stat Type field to indicate the | |||
statistic carried in the Stat Data field. Statistics report messages | statistic carried in the Stat Data field. Statistics report messages | |||
are not specific to Adj-RIB-In or Adj-RIB-Out and MUST have the O | are not specific to Adj-RIB-In or Adj-RIB-Out and MUST have the O | |||
flag set to zero. The O flag SHOULD be ignored by the BMP receiver. | flag set to zero. The O flag SHOULD be ignored by the BMP receiver. | |||
The following new statistic types are added: | The following new statistic types are added: | |||
o Stat Type = 14: (64-bit Gauge) Number of routes in Adj-RIBs-Out | o Stat Type = 14: (64-bit Gauge) Number of routes in Adj-RIBs-Out | |||
Pre-Policy. | Pre-Policy. | |||
o Stat Type = 15: (64-bit Gauge) Number of routes in Adj-RIBs-Out | o Stat Type = 15: (64-bit Gauge) Number of routes in Adj-RIBs-Out | |||
skipping to change at page 6, line 12 ¶ | skipping to change at page 6, line 12 ¶ | |||
Identifier (AFI), 1-byte Subsequent Address Family Identifier | Identifier (AFI), 1-byte Subsequent Address Family Identifier | |||
(SAFI), followed by a 64-bit Gauge. | (SAFI), followed by a 64-bit Gauge. | |||
o Stat Type = 17: Number of routes in per-AFI/SAFI Adj-RIB-Out Post- | o Stat Type = 17: Number of routes in per-AFI/SAFI Adj-RIB-Out Post- | |||
Policy. The value is structured as: 2-byte Address Family | Policy. The value is structured as: 2-byte Address Family | |||
Identifier (AFI), 1-byte Subsequent Address Family Identifier | Identifier (AFI), 1-byte Subsequent Address Family Identifier | |||
(SAFI), followed by a 64-bit Gauge. | (SAFI), followed by a 64-bit Gauge. | |||
6.3. Peer Down and Up Notifications | 6.3. Peer Down and Up Notifications | |||
PEER UP and DOWN notifications convey BGP peering session state to | Peer Up and Down notifications convey BGP peering session state to | |||
BMP receivers. The state is independent of whether or not route | BMP receivers. The state is independent of whether or not route | |||
monitoring or route mirroring messages will be sent for Adj-RIB-In, | monitoring or route mirroring messages will be sent for Adj-RIB-In, | |||
Adj-RIB-Out, or both. BMP receiver implementations SHOULD ignore the | Adj-RIB-Out, or both. BMP receiver implementations SHOULD ignore the | |||
O flag in PEER UP and DOWN notifications. BMP receiver | O flag in Peer Up and Down notifications. BMP receiver | |||
implementations MUST use the per-peer header O flag in route | implementations MUST use the per-peer header O flag in route | |||
monitoring and mirroring messages in order to identify if the message | monitoring and mirroring messages to identify if the message | |||
is for Adj-RIB-In or Adj-RIB-Out. | is for Adj-RIB-In or Adj-RIB-Out. | |||
6.3.1. Peer Up Information | 6.3.1. Peer Up Information | |||
The following peer UP information TLV types are added: | The following Peer Up message Information TLV type is added: | |||
o Type = 4: Admin Label. The Information field contains a free-form | o Type = 4: Admin Label. The Information field contains a free-form | |||
UTF-8 string whose length is given by the Information Length | UTF-8 string whose length is given by the Information Length | |||
field. The value is administratively assigned. There is no | field. The value is administratively assigned. There is no | |||
requirement to terminate the string with null or any other | requirement to terminate the string with null or any other | |||
character. | character. | |||
Multiple admin labels can be included in the Peer UP. When | Multiple admin labels can be included in the Peer Up notification. When | |||
multiple admin labels are included the BMP receiver MUST preserve | multiple admin labels are included the BMP receiver MUST preserve | |||
the order. | their order. | |||
The TLV is optional. | The TLV is optional. | |||
7. Other Considerations | 7. Other Considerations | |||
7.1. Peer and Update Groups | 7.1. Peer and Update Groups | |||
Peer and update groups are used to group updates shared by many | Peer and update groups are used to group updates shared by many | |||
peers. This is a level of efficiency in the implementation, not a | peers. This is a level of efficiency in implementations, not a | |||
true representation of what is conveyed to a peer in either Pre- | true representation of what is conveyed to a peer in either Pre- | |||
Policy or Post-Policy. | Policy or Post-Policy. | |||
One of the use-cases to monitor Adj-RIB-Out Post-Policy is to | One of the use-cases to monitor Adj-RIB-Out Post-Policy is to | |||
validate and continually ensure the egress updates match what is | validate and continually ensure the egress updates match what is | |||
expected. For example, wholesale peers should never have routes with | expected. For example, wholesale peers should never have routes with | |||
community X:Y sent to them. In this use-case, there may be hundreds | community X:Y sent to them. In this use-case, there may be hundreds | |||
of wholesale peers but a single peer could have represented the | of wholesale peers but a single peer could have represented the | |||
group. | group. | |||
From a BMP perspective, this should be simple to include a group name | From a BMP perspective, this should be simple to include a group name | |||
in the PEER UP, but it is more complex than that. BGP | in the Peer Up, but it is more complex than that. BGP | |||
implementations have evolved to provide comprehensive and structured | implementations have evolved to provide comprehensive and structured | |||
policy grouping, such as session, afi/safi, and template based group | policy grouping, such as session, AFI/SAFI, and template-based group | |||
policy inheritances. | policy inheritances. | |||
This level of structure and inheritance of polices does not provide a | This level of structure and inheritance of polices does not provide a | |||
simple peer group name or ID, such as wholesale peer. | simple peer group name or ID, such as wholesale peer. | |||
Instead of requiring a group name to be used, a new administrative | Instead of requiring a group name to be used, a new administrative | |||
label informational TLV (Section 6.3.1) is added to the Peer UP | label informational TLV (Section 6.3.1) is added to the Peer Up | |||
message. These labels have administrative scope relevance. For | message. These labels have administrative scope relevance. For | |||
example, labels "type=wholesale" and "region=west" could be used to | example, labels "type=wholesale" and "region=west" could be used to | |||
monitor expected policies. | monitor expected policies. | |||
Configuration and assignment of labels to peers is BGP implementation | Configuration and assignment of labels to peers is BGP implementation | |||
specific. | specific. | |||
8. Security Considerations | 8. Security Considerations | |||
It is not believed that this document adds any additional security | It is not believed that this document adds any additional security | |||
considerations. | considerations. | |||
9. IANA Considerations | 9. IANA Considerations | |||
This document requests that IANA assign the following new parameters | This document requests that IANA assign the following new parameters | |||
to the BMP parameters name space [1]. | to the BMP parameters name space [1]. | |||
9.1. BMP Peer Flags | 9.1. BMP Peer Flags | |||
This document defines the following new per-peer header flags | This document defines the following per-peer header flags | |||
(Section 4): | (Section 4): | |||
o Flag 3 as O flag: The O flag indicates Adj-RIB-In if set to 0 and | o Flag 3 as O flag: The O flag indicates Adj-RIB-In if set to 0 and | |||
Adj-RIB-Out if set to 1. | Adj-RIB-Out if set to 1. | |||
9.2. BMP Statistics Types | 9.2. BMP Statistics Types | |||
This document defines four new statistic types for statistics | This document defines four statistic types for statistics | |||
reporting (Section 6.2): | reporting (Section 6.2): | |||
o Stat Type = 14: (64-bit Gauge) Number of routes in Adj-RIBs-Out | o Stat Type = 14: (64-bit Gauge) Number of routes in Adj-RIBs-Out | |||
Pre-Policy. | Pre-Policy. | |||
o Stat Type = 15: (64-bit Gauge) Number of routes in Adj-RIBs-Out | o Stat Type = 15: (64-bit Gauge) Number of routes in Adj-RIBs-Out | |||
Post-Policy. | Post-Policy. | |||
o Stat Type = 16: Number of routes in per-AFI/SAFI Adj-RIB-Out Pre- | o Stat Type = 16: Number of routes in per-AFI/SAFI Adj-RIB-Out Pre- | |||
Policy. The value is structured as: 2-byte Address Family | Policy. The value is structured as: 2-byte Address Family | |||
Identifier (AFI), 1-byte Subsequent Address Family Identifier | Identifier (AFI), 1-byte Subsequent Address Family Identifier | |||
(SAFI), followed by a 64-bit Gauge. | (SAFI), followed by a 64-bit Gauge. | |||
o Stat Type = 17: Number of routes in per-AFI/SAFI Adj-RIB-Out Post- | o Stat Type = 17: Number of routes in per-AFI/SAFI Adj-RIB-Out Post- | |||
Policy. The value is structured as: 2-byte Address Family | Policy. The value is structured as: 2-byte Address Family | |||
Identifier (AFI), 1-byte Subsequent Address Family Identifier | Identifier (AFI), 1-byte Subsequent Address Family Identifier | |||
(SAFI), followed by a 64-bit Gauge. | (SAFI), followed by a 64-bit Gauge. | |||
9.3. Peer UP Information TLV | 9.3. Peer Up Information TLV | |||
This document defines the following new BMP PEER UP informational | This document defines the following BMP Peer Up Information | |||
message TLV types (Section 6.3.1): | TLV type (Section 6.3.1): | |||
o Type = 4: Admin Label. The Information field contains a free-form | o Type = 4: Admin Label. The Information field contains a free-form | |||
UTF-8 string whose length is given by the Information Length | UTF-8 string whose length is given by the Information Length | |||
field. The value is administratively given by the Information | field. The value is administratively given by the Information | |||
Length field. The value is administratively assigned. There is | Length field. The value is administratively assigned. There is | |||
no requirement to terminate the string with null or any other | no requirement to terminate the string with null or any other | |||
character. | character. | |||
10. References | 10. References | |||
skipping to change at page 8, line 46 ¶ | skipping to change at page 8, line 46 ¶ | |||
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A | [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A | |||
Border Gateway Protocol 4 (BGP-4)", RFC 4271, | Border Gateway Protocol 4 (BGP-4)", RFC 4271, | |||
DOI 10.17487/RFC4271, January 2006, | DOI 10.17487/RFC4271, January 2006, | |||
<https://www.rfc-editor.org/info/rfc4271>. | <https://www.rfc-editor.org/info/rfc4271>. | |||
[RFC7854] Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP | [RFC7854] Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP | |||
Monitoring Protocol (BMP)", RFC 7854, | Monitoring Protocol (BMP)", RFC 7854, | |||
DOI 10.17487/RFC7854, June 2016, | DOI 10.17487/RFC7854, June 2016, | |||
<https://www.rfc-editor.org/info/rfc7854>. | <https://www.rfc-editor.org/info/rfc7854>. | |||
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | ||||
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | ||||
May 2017, <https://www.rfc-editor.org/info/rfc8174>. | ||||
10.2. URIs | 10.2. URIs | |||
[1] https://www.iana.org/assignments/bmp-parameters/bmp- | [1] https://www.iana.org/assignments/bmp-parameters/bmp- | |||
parameters.xhtml | parameters.xhtml | |||
Acknowledgements | Acknowledgements | |||
The authors would like to thank John Scudder for his valuable input. | The authors would like to thank John Scudder for his valuable input. | |||
Contributors | Contributors | |||
End of changes. 30 change blocks. | ||||
32 lines changed or deleted | 38 lines changed or added | |||
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |