RFC 9069
Support for Local RIB in the BGP Monitoring Protocol (BMP)
RFC 9069: Support for Local RIB in the BGP Monitoring Protocol (BMP) 🦋
okay bestie, this is RFC 9069 💅 It's from the IETF, dated February 2022, and its ISSN is 2070-1721. It's a Standards Track document, so it's an actual Internet standard, not just a suggestion 👑 It updates RFC 7854, which is BMP itself. The authors are T. Evens (Cisco Systems), S. Bayraktar (Menlo Security), M. Bhardwaj (Cisco Systems), and P. Lucente (NTT Communications). Whole squad 🫶
Abstract 💖
BMP defines access to local Routing Information Bases (RIBs). This document updates BMP (RFC 7854) by adding access to the Local Routing Information Base (Loc-RIB), as defined in RFC 4271. The Loc-RIB contains the routes that have been selected by the local BGP speaker's Decision Process ✨
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 https://www.rfc-editor.org/info/rfc9069.
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 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
1.1. Alternative Method to Monitor Loc-RIB
2. Terminology
3. Definitions
4. Per-Peer Header
4.1. Peer Type
4.2. Peer Flags
5. Loc-RIB Monitoring
5.1. Per-Peer Header
5.2. Peer Up Notification
5.2.1. Peer Up Information
5.3. Peer Down Notification
5.4. Route Monitoring
5.4.1. ASN Encoding
5.4.2. Granularity
5.5. Route Mirroring
5.6. Statistics Report
6. Other Considerations
6.1. Loc-RIB Implementation
6.1.1. Multiple Loc-RIB Peers
6.1.2. Filtering Loc-RIB to BMP Receivers
6.1.3. Changes to Existing BMP Sessions
7. Security Considerations
8. IANA Considerations
8.1. BMP Peer Type
8.2. BMP Loc-RIB Instance Peer Flags
8.3. Peer Up Information TLV
8.4. Peer Down Reason Code
8.5. Deprecated Entries
9. References
9.1. Normative References
9.2. Informative References
Acknowledgements
Authors' Addresses1. Introduction ✨
okay so this doc is all about monitoring the BGP Loc-RIB state of remote BGP instances, and the big win is that you don't have to set up BGP peering sessions to do it 🙌 BMP [RFC7854] doesn't have a way to send the BGP instance's Loc-RIB. It does talk about locally originated routes in Section 8.2 of [RFC7854], but those are defined as the routes that originated into BGP (e.g., Section 9.4 of [RFC4271]). The Loc-RIB is way more than that, though. It includes all the selected received routes from BGP peers, plus the locally originated routes too 💅
Here's a little picture of how routes flow from one or more BGP peers into the Loc-RIB 🦋
+------------------+ +------------------+
| Peer-A | | Peer-B |
/-- | | ---- | | --\
| | Adj-RIB-In (Pre) | | Adj-RIB-In (Pre) | |
| +------------------+ +------------------+ |
| | | |
| Filters/Policy -| Filters/Policy -| |
| V V |
| +------------------+ +------------------+ |
| | Adj-RIB-In (Post)| | Adj-RIB-In (Post)| |
| +------------------+ +------------------+ |
| | | |
| Selected -| Selected -| |
| V V |
| +-----------------------------------------+ |
| | Loc-RIB | |
| +-----------------------------------------+ |
| |
| ROUTER/BGP Instance |
\----------------------------------------------------/Figure 1: BGP Peering Adj-RIBs-In into Loc-RIB
okay, so why would anyone even want this? Here are some really good use cases for Loc-RIB access 👀
- The Adj-RIB-In for a given peer post-policy may contain hundreds of thousands of routes, with only a handful of routes selected and installed in the Loc-RIB after best-path selection. Some monitoring applications, such as those that need only to correlate flow records to Loc-RIB entries, only need to collect and monitor the routes that are actually selected and used.
Requiring the applications to collect all Adj-RIB-In post-policy data forces the applications to receive a potentially large unwanted data set and to perform the BGP decision process selection, which includes having access to the interior gateway protocol (IGP) next-hop metrics. While it is possible to obtain the IGP topology information using BGP - Link State (BGP-LS), it requires the application to implement Shortest Path First (SPF) and possibly Constrained Shortest Path First (CSPF) based on additional policies. This is overly complex for such a simple application that only needs to have access to the Loc-RIB 🙄
- It is common to see frequent changes over many BGP peers, but those changes do not always result in the router's Loc-RIB changing. The change in the Loc-RIB can have a direct impact on the forwarding state. It can greatly reduce the time to troubleshoot and resolve issues if operators have the history of Loc-RIB changes. For example, a performance issue might have been seen for only a duration of 5 minutes. Post-facto troubleshooting this issue without Loc-RIB history hides any decision-based routing changes that might have happened during those 5 minutes 😭
- Operators may wish to validate the impact of policies applied to the Adj-RIB-In by analyzing the final decision made by the router when installing into the Loc-RIB. For example, in order to validate if multipath prefixes are installed as expected for all advertising peers, the Adj-RIB-In post-policy and Loc-RIB need to be compared. This is only possible if the Loc-RIB is available. Monitoring the Adj-RIB-In for this router from another router to derive the Loc-RIB is likely to not show the same installed prefixes. For example, the received Adj-RIB-In will be different if ADD-PATH [RFC7911] is not enabled or if the maximum supported number of equal paths is different between Loc-RIB and advertised routes 🧚
so the whole point of this document is that it adds Loc-RIB to the BGP Monitoring Protocol and replaces Section 8.2 of [RFC7854] ("Locally Originated Routes") ✨💖
1.1. Alternative Method to Monitor Loc-RIB ✨
okay so Loc-RIB is the thing a router uses to build its Adj-RIB-Out when it's advertising routes to a peer 💅 which means you could figure out a router's Loc-RIB by watching the Adj-RIB-In pre-policy coming from another router 🧚 but bestie, that gets so messy so fast once you're tracking a bunch of peers per router 😭
/------------------------------------------------------\
| ROUTER1 BGP Instance |
| |
| +--------------------------------------------+ |
| | Loc-RIB | |
| +--------------------------------------------+ |
| | | |
| +------------------+ +------------------+ |
| | Peer-ROUTER2 | | Peer-ROUTER3 | |
| | Adj-RIB-Out (Pre)| | Adj-RIB-Out (Pre)| |
| +------------------+ +------------------+ |
| Filters/Policy -| Filters/Policy -| |
| V V |
| +-------------------+ +-------------------+ |
| | Adj-RIB-Out (Post)| | Adj-RIB-Out (Post)| |
| +-------------------+ +-------------------+ |
| | | |
\------------- | ------------------------ | -----------/
BGP | BGP |
Peer | Peer |
+------------------+ +------------------+
| Peer-ROUTER1 | | Peer-ROUTER1 |
/--| |--\ /--| | --\
| | Adj-RIB-In (Pre) | | | | Adj-RIB-In (Pre) | |
| +------------------+ | | +------------------+ |
| | | |
| ROUTER2/BGP Instance | | ROUTER3/BGP Instance |
\------------------------/ \-------------------------/
| |
v v
ROUTER2 BMP Feed ROUTER3 BMP Feed
Figure 2: Alternative Method to Monitor Loc-RIBso the setup for monitoring a router's Loc-RIB needs another router that has a peering session with the target router 🦋 like in Figure 2, the target's Loc-RIB gets advertised through its Adj-RIB-Out to the BMP router over a normal BGP peering session 🌸 then the BMP router passes the Adj-RIB-In pre-policy along to the BMP receiver 💜
but a BMP setup that can't get at Loc-RIB directly needs extra resources, and that's a whole mood:
- It needs at least two routers when only one router was supposed to be monitored 😭
- It needs extra BGP peering just to collect the received updates, even when peering wouldn't have been needed in the first place 💀 for example, VRF tables with no peers, redistributed BGP-LS with no peers, and segment routing egress peer engineering where no peers have the link-state address family enabled are all situations with zero preexisting BGP peers 🙈
and using a received Adj-RIB-In to infer a router's Loc-RIB is honestly so complicated 🌈
- The Adj-RIB-Out you receive as an Adj-RIB-In from another router might have a policy applied that makes aggregates, suppresses more specific prefixes, manipulates attributes, or filters routes 💅 which doesn't just break the Loc-RIB view, it also adds drama when several BMP routers have peering sessions with the same router 🫶 now the BMP receiver user is stuck with the error-prone job of figuring out which peering session best represents the Loc-RIB 😭
- BGP peering is built to work between administrative domains, so it doesn't need to include internal system-level info about each peering router, like the system name or version 💅 but to derive a router's Loc-RIB, you do need the router name or other system info 🔥 so the BMP receiver and user have to do some kind of correlation using whatever's in the peering session (like peering addresses, autonomous system numbers, and BGP identifiers) 🙈 and that leads to error-prone correlations, periodt 💀
- Correlating BGP identifiers (BGP-ID) and session addresses to a router takes extra data, like router inventory 👑 that extra data is what lets the BMP receiver map and correlate BGP-IDs and/or session addresses, but the BMP receiver has to somehow get it from outside of BMP 😭 how that data is obtained, and how accurate it is, directly affects how solid the correlation is 🧚
2. Terminology 🎀
okay this part is the boilerplate, but it's the important boilerplate 🤓 the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document should be read as described in BCP 14 RFC 2119 [RFC2119] RFC 8174 [RFC8174] — but only when they show up in all capitals, like they do here ✨
3. Definitions 📚
BGP Instance: this refers to an instance of BGP-4 [RFC4271], and the considerations in Section 8.1 of [RFC7854] apply to it 🦋
Adj-RIB-In: as defined in [RFC4271], "The Adj-RIBs-In contains unprocessed routing information that has been advertised to the local BGP speaker by its peers." 💅 this one is also called the "pre-policy Adj-RIB-In" in this document 🌸
Adj-RIB-Out: as defined in [RFC4271], "The Adj-RIBs-Out contains the routes for advertisement to specific peers by means of the local speaker's UPDATE messages." 🫶
Loc-RIB: as defined in Section 1.1 of [RFC4271], "The Loc-RIB contains the routes that have been selected by the local BGP speaker's Decision Process." 👑 the thing to know is that the Loc-RIB state you monitor through BMP might also include routes imported from other routing protocols, like an IGP or local static routes 🌈
Pre-Policy Adj-RIB-Out: this is the result before the outbound policy gets applied to an Adj-RIB-Out 🧚 it normally shows a similar view of the Loc-RIB, but it might have extra routes based on the BGP peering configuration 💜
Post-Policy Adj-RIB-Out: this is the result of applying the outbound policy to an Adj-RIB-Out 💀 this MUST be what is actually sent to the peer, no exceptions, bestie 🔥
4. Per-Peer Header 🧁
4.1. Peer Type 💖
a new peer type is defined for Loc-RIB, to show that it represents the router's Loc-RIB, which may have a route distinguisher (RD) ✨ Section 4.2 of [RFC7854] defines a Local Instance Peer type, and that one's for non-RD peers that have an instance identifier 🦋
this document defines the following new peer type:
Peer Type = 3: Loc-RIB Instance Peer🎀
4.2. Peer Flags 🚩
if locally sourced routes get communicated using BMP, they MUST be conveyed using the Loc-RIB Instance Peer Type 💅
the per-peer header flags for the Loc-RIB Instance Peer Type look like this:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|F| | | | | | | |
+-+-+-+-+-+-+-+-+- The F flag says the Loc-RIB is filtered 🌸 it MUST be set when a filter gets applied to Loc-RIB routes sent to the BMP collector 🫶
the unused bits are reserved for future use 🧚 they MUST be transmitted as 0, and their values MUST be ignored on receipt 💀 no drama, just zeros 🙈
5. Loc-RIB Monitoring 🌈
the Loc-RIB contains all routes selected by the BGP Decision Process, as described in Section 9.1 of [RFC4271] 👑 those routes include the ones learned from BGP peers through their Adj-RIBs-In post-policy, plus routes learned by other means, as per Section 9.4 of [RFC4271] 🦋 examples are routes redistributed from other protocols into BGP, or ones that were locally originated (like aggregate routes) 💜
as described in Section 6.1.2, a subset of Loc-RIB routes MAY be sent to a BMP collector by setting the F flag 🧁 so it's optional, but it's a whole vibe ✨
5.1. Per-Peer Header 🎀
all peer messages that include a per-peer header, as defined in Section 4.2 of [RFC7854], MUST use the following values:
- Peer Type: set this to 3 to indicate a Loc-RIB Instance Peer 💅
- Peer Distinguisher: zero-filled if the Loc-RIB represents the global instance 🌸 otherwise, set it to the route distinguisher or unique locally defined value of the particular instance the Loc-RIB belongs to 🫶
- Peer Address: zero-filled, because the remote peer address isn't applicable 🙈 the V flag isn't applicable with the Loc-RIB Instance Peer Type either, since the addresses are zero-filled anyway 💀
- Peer Autonomous System (AS): set this to the primary router BGP autonomous system number (ASN) 👑
- Peer BGP ID: set the ID to the router-id of the VRF instance if VRF is used 🧚 otherwise, set it to the global instance router-id 💜
- Timestamp: the time when the encapsulated routes were installed in the Loc-RIB, expressed in seconds and microseconds since midnight (zero hour), January 1, 1970 (UTC) ⏰ if it's zero, the time is unavailable 🥺 and the precision of the timestamp is implementation dependent 🌈
5.2. Peer Up Notification 🦋
Peer Up notifications follow Section 4.10 of [RFC7854], with these clarifications:
- Local Address: zero-filled, since the local address isn't applicable 🌸
- Local Port: set to 0, because the local port isn't applicable 🧁
- Remote Port: set to 0, because the remote port isn't applicable 🎀
- Sent OPEN Message: this is a fabricated BGP OPEN message 🧚 its capabilities MUST include the 4-octet ASN and all the necessary capabilities to represent the Loc-RIB Route Monitoring messages 💅 only include capabilities that will actually be used for Loc-RIB monitoring messages 🙈 for example, if ADD-PATH is enabled for IPv6 and Loc-RIB has additional paths, the ADD-PATH capability should be included for IPv6 ✨ with ADD-PATH, the capability intent of advertise, receive, or both can be ignored, since the capability being present is enough to show that additional paths will be used for IPv6 🫶
- Received OPEN Message: this is a repeat of the same sent OPEN message 🌈 the duplication lets the BMP receiver parse the expected received OPEN message, as defined in Section 4.10 of [RFC7854] 👑
5.2.1. Peer Up Information ✨
okay so the new Peer Up Information TLV type is here, and it's giving organised 🎀
- Type = 3: VRF/Table Name. The Information field holds a UTF-8 string, and its value MUST be equal to the VRF or table name (e.g., RD instance name) being conveyed 💅. The string size MUST be within the range of 1 to 255 bytes 🌸.
The VRF/Table Name TLV is optional, bestie 🦋, so it's there for implementations that haven't defined a name yet. If a name IS configured, it MUST be included ✨. The default value of "global" MUST be used for the default Loc-RIB instance with a zero-filled distinguisher 👑. And if the TLV shows up in the Peer Up, it MUST also show up in the Peer Down notification 💖.
The Information field contains a UTF-8 string whose value MUST be equal to the value of the VRF or table name (e.g., RD instance name) being conveyed. The string size MUST be within the range of 1 to 255 bytes. (Yes, I'm repeating this, because it's just that important 😭.)
The VRF/Table Name TLV is optionally included to support implementations that may not have defined a name. If a name is configured, it MUST be included. The default value of "global" MUST be used for the default Loc-RIB instance with a zero-filled distinguisher. If the TLV is included, then it MUST also be included in the Peer Down notification.
Multiple TLVs of the same type can be repeated in the same message, which is super handy for conveying a filtered view of a VRF 🧚. A BMP receiver SHOULD append multiple TLVs of the same type to a set so it can support alternate or additional names for the same peer 🍓. If multiple strings are included, their ordering MUST be preserved when they are reported 🫶.
5.3. Peer Down Notification
The Peer Down notification MUST use reason code 6 💀. After the reason, you get data in TLV format. The following Peer Down Information TLV type is defined:
- Type = 3: VRF/Table Name. The Information field contains a UTF-8 string whose value MUST be equal to the value of the VRF or table name (e.g., RD instance name) being conveyed. The string size MUST be within the range of 1 to 255 bytes. The VRF/Table Name informational TLV MUST be included if it was in the Peer Up 🌈.
5.4. Route Monitoring
Route Monitoring messages are used for the initial sync of the Loc-RIB 🔥. They're also how incremental Loc-RIB changes get conveyed ✨.
As described in Section 4.6 of [RFC7854], "Following the common BMP header and per-peer header is a BGP Update PDU." 🦋
5.4.1. ASN Encoding
Loc-RIB Route Monitoring messages MUST use a 4-byte ASN encoding as indicated in the Peer Up sent OPEN message (Section 5.2) capability 💜.
5.4.2. Granularity
State compression and throttling SHOULD be used by a BMP sender to reduce the amount of Route Monitoring messages that get transmitted to BMP receivers 🌸. With state compression, only the final resultant updates are sent. Lowkey genius 🧠.
For example, prefix 192.0.2.0/24 is updated in the Loc-RIB 5 times within 1 second 😭. State compression of BMP Route Monitoring messages results in only the final change being transmitted. The other 4 changes are suppressed because they fall within the compression interval. If no compression was being used, all 5 updates would have been transmitted 💀.
A BMP receiver SHOULD expect that the granularity of Loc-RIB Route Monitoring can vary depending on the BMP sender implementation 🙈.
5.5. Route Mirroring
Section 4.7 of [RFC7854] defines Route Mirroring for verbatim duplication of messages received. This is NOT applicable to Loc-RIB, as PDUs are originated by the router 🙅. Any received Route Mirroring messages SHOULD be ignored.
5.6. Statistics Report
Not all Stat Types are relevant to Loc-RIB, so here are the ones that are 🎀:
- Stat Type = 8: (64-bit Gauge) Number of routes in Loc-RIB.
- Stat Type = 10: Number of routes in per-AFI/SAFI Loc-RIB. The value is structured as: 2-byte AFI, 1-byte SAFI, followed by a 64-bit Gauge 💅.
6. Other Considerations 🧚
6.1. Loc-RIB Implementation
There are several methods for a BGP speaker to implement Loc-RIB efficiently 🦋. In all methods, the implementation emulates a peer with Peer Up and Down messages to convey capabilities, as well as Route Monitor messages to convey Loc-RIB. In this sense, the peer that conveys the Loc-RIB is a locally emulated peer 🫶.
6.1.1. Multiple Loc-RIB Peers
There MUST be at least one emulated peer for each Loc-RIB instance, such as with VRFs 👑. The BMP receiver identifies the Loc-RIB by the peer header distinguisher and BGP ID. The BMP receiver uses the VRF/Table Name from the Peer Up information to associate a name with the Loc-RIB 🎀.
In some implementations, it might be required to have more than one emulated peer for Loc-RIB to convey different address families for the same Loc-RIB. In this case, the peer distinguisher and BGP ID SHOULD be the same, since they represent the same Loc-RIB instance 🌈. Each emulated peer instance MUST send a Peer Up with the OPEN message indicating the address family capabilities. A BMP receiver MUST process these capabilities to know which peer belongs to which address family 💖.
6.1.2. Filtering Loc-RIB to BMP Receivers
There may be use cases where BMP receivers should only receive specific routes from Loc-RIB 🔥. For example, IPv4 unicast routes may include internal BGP (IBGP), external BGP (EBGP), and IGP, but only routes from EBGP should be sent to the BMP receiver. Alternatively, it may be that only IBGP and EBGP should be sent and IGP redistributed routes excluded 🍓. In these cases where the Loc-RIB is filtered, the F flag is set to 1 to indicate to the BMP receiver that the Loc-RIB is filtered 🧠. If multiple filters are associated with the same Loc-RIB, a table name MUST be used so a BMP receiver can make the right associations 💅.
6.1.3. Changes to Existing BMP Sessions
In case of any change that results in the alteration of behavior of an existing BMP session, i.e., changes to filtering and table names, the session MUST be bounced with a Peer Down / Peer Up sequence 🙈.
7. Security Considerations 💀
The same considerations as in Section 11 of [RFC7854] apply to this document. Implementations of this protocol SHOULD require that sessions only be established with authorized and trusted monitoring devices 🔒. It is also believed that this document does not introduce any additional security considerations. (Bestie, lock down your monitoring sessions, no cap 😭🫶.)
8. IANA Considerations 🌸
IANA has assigned new parameters to the "BGP Monitoring Protocol (BMP) Parameters" registry (https://www.iana.org/assignments/bmp-parameters/).
8.1. BMP Peer Type
IANA has registered the following new peer type (Section 4.1):
+===========+=======================+
| Peer Type | Description |
+===========+=======================+
| 3 | Loc-RIB Instance Peer |
+-----------+-----------------------+
Table 1: BMP Peer Type8.2. BMP Loc-RIB Instance Peer Flags
IANA has renamed "BMP Peer Flags" to "BMP Peer Flags for Peer Types 0 through 2" and created a new registry named "BMP Peer Flags for Loc-RIB Instance Peer Type 3" 🎀.
This document defines peer flags that are specific to the Loc-RIB Instance Peer Type. IANA has registered the following in the "BMP Peer Flags for Loc-RIB Instance Peer Type 3" registry:
+======+=============+
| Flag | Description |
+======+=============+
| 0 | F flag |
+------+-------------+
Table 2: Loc-RIB
Instance Peer TypeAs noted in Section 4.2, the F flag indicates that the Loc-RIB is filtered. This indicates that the Loc-RIB does not represent the complete routing table 🦋.
Flags 1 through 7 are unassigned. The registration procedure for the registry is Standards Action 👑.
8.3. Peer Up Information TLV
IANA has renamed the "BMP Initiation Message TLVs" registry to "BMP Initiation and Peer Up Information TLVs". Section 4.4 of [RFC7854] indicates that both Initiation and Peer Up share the same information TLVs. This document defines the following new BMP Peer Up Information TLV type (Section 5.2.1) ✨:
+======+================+
| Type | Description |
+======+================+
| 3 | VRF/Table Name |
+------+----------------+
Table 3: BMP Peer Up
Information TLV TypeThe Information field contains a UTF-8 string whose value MUST be equal to the value of the VRF or table name (e.g., RD instance name) being conveyed. The string size MUST be within the range of 1 to 255 bytes 💖.
8.4. Peer Down Reason Code
IANA has registered the following new BMP Peer Down reason code (Section 5.3) 🌈:
+======+=======================================+
| Type | Description |
+======+=======================================+
| 6 | Local system closed, TLV data follows |
+------+---------------------------------------+
Table 4: BMP Peer Down Reason Code8.5. Deprecated Entries
Per this document, IANA has marked the F Flag entry in the "BMP Peer Flags for Peer Types 0 through 2" registry as "deprecated" 🥀.
9. References
9.1. Normative References
[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>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>.
[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>.
[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>.9.2. Informative References
[RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder,
"Advertisement of Multiple Paths in BGP", RFC 7911,
DOI 10.17487/RFC7911, July 2016,
<https://www.rfc-editor.org/info/rfc7911>.Acknowledgements 🫶
The authors would like to thank John Scudder, Jeff Haas, and Mukul Srivastava for their valuable input 💜.
Authors' Addresses 💌
Tim Evens
Cisco Systems
2901 Third Avenue, Suite 600
Seattle, WA 98121
United States of America
Email: tievens@cisco.com
Serpil Bayraktar
Menlo Security
800 W El Camino Real, Suite 250
Mountain View, CA 94040
United States of America
Email: serpil.bayraktar@menlosecurity.com
Manish Bhardwaj
Cisco Systems
3700 Cisco Way
San Jose, CA 95134
United States of America
Email: manbhard@cisco.com
Paolo Lucente
NTT Communications
Siriusdreef 70-72
2132 Hoofddorp
Netherlands
Email: paolo@ntt.net📦 where this page comes from
- ietf: rfc9069 2022-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms