RFC 9533
One-Way and Two-Way Active Measurement Protocol Extensions for Performance Measurement on a Link Aggregation Group
📜 RFC 9533: One-Way and Two-Way Active Measurement Protocol Extensions for Performance Measurement on a Link Aggregation Group
okay bestie, this one is a Standards Track doc from the IETF (Internet Engineering Task Force) 🎀 It was published in January 2024 and it's RFC 9533, with ISSN 2070-1721. The authors are Z. Li (China Mobile), T. Zhou (Huawei), J. Guo (ZTE Corp.), G. Mirsky (Ericsson), and R. Gandhi (Cisco Systems, Inc.) 🫶 The header doesn't list anything it obsoletes or updates, so no drama there 💅
Abstract ✨
okay so this doc adds extensions to OWAMP (One-Way Active Measurement Protocol) and TWAMP (Two-Way Active Measurement Protocol) so you can measure performance on every single member link of a Link Aggregation Group (LAG) 🦋 Why is that iconic? Because once you know the metrics for each member link, operators can actually enforce performance-based traffic steering across those links. main character energy 👑
Status of This Memo
this is an Internet Standards Track document 🌸
it's a product of the IETF, so it represents the consensus of the IETF community. it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). if you want more info on Internet Standards, check Section 2 of RFC 7841 📚
for the current status, any errata, and where to send feedback, go to https://www.rfc-editor.org/info/rfc9533 🧚
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. 💜
this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they were in effect on the publication date. read those carefully, bestie, because they explain your rights and restrictions 🙈 and if you pull Code Components out of this doc, they have to include the Revised BSD License text described in Section 4.e of the Trust Legal Provisions. they come with no warranty, per the Revised BSD License ✨
Table of Contents 🌈
1. Introduction
1.1. Requirements Language
2. Micro Sessions on a LAG
3. Micro OWAMP Session
3.1. Micro OWAMP-Control
3.2. Micro OWAMP-Test
4. Micro TWAMP Session
4.1. Micro TWAMP-Control
4.2. Micro TWAMP-Test
4.2.1. Sender Packet Format and Content
4.2.2. Sender Behavior
4.2.3. Reflector Packet Format and Content
4.2.4. Reflector Behavior
5. Applicability
6. IANA Considerations
6.1. Micro OWAMP-Control Command
6.2. Micro TWAMP-Control Command
7. Security Considerations
8. References
8.1. Normative References
8.2. Informative References
Acknowledgements
Authors' Addresses1. Introduction ✨
okay so a Link Aggregation Group (LAG), as defined in [IEEE802.1AX], lets you bundle multiple physical links into one logical link 🔗 The payoff is higher bandwidth and better resiliency, because if one physical member link dies, the logical link keeps forwarding traffic over the rest of the working ones 💖
usually, when traffic goes over a LAG, a hash-based mechanism load balances it across the member links. but the link delay can differ between member links because they take different transport paths, especially when a LAG runs across a wide area network 🌍 so if you want low-latency service for time-sensitive traffic, you need to steer traffic across the member links based on link delay, loss, and so on 😭 that means you need a way to measure the performance metrics of every member link in the LAG. and the measured metrics can work together with Layer 2 bundle member link attributes advertisement [RFC8668] for traffic steering 🎀
according to the classifications in [RFC7799], OWAMP [RFC4656] and TWAMP [RFC5357] are active measurement methods, and they can complement passive and hybrid methods 🦋 with either one, a single test session over the LAG can measure a member link's performance using a specially built 5-tuple. you can also vary one or more elements of that 5-tuple to get an average across some or all of the member links 🧚 but here's the catch: without knowing about each member link, a test session can't measure every physical member link on its own 🙈
this doc extends OWAMP and TWAMP to measure performance on every member link of a LAG 💅 it can provide the same metrics that OWAMP and TWAMP already measure, like delay, jitter, and packet loss ✨
1.1. Requirements Language 💜
the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be read as described in BCP 14 [RFC2119] [RFC8174], but only when they appear in all capitals, exactly as shown here 🫶
2. Micro Sessions on a LAG 🌸
this doc covers the case where a LAG directly connects two nodes 🔗 Figure 1 shows an example: a LAG made of four links connecting nodes A and B. the goal is to measure the performance of each link in that LAG 🎀
+---+ +---+
| |-----------------------| |
| A |-----------------------| B |
| |-----------------------| |
| |-----------------------| |
+---+ +---+
Figure 1: Performance Measurement on a LAGso to measure the performance metrics of every member link, you need multiple sessions, one for each member link, set up between the two endpoints the LAG connects 🦋 this doc calls these "micro sessions." technically they're just OWAMP or TWAMP sessions running on the LAG's member links, but test packets of micro TWAMP sessions MUST carry member link information so they can be validated 💖
all micro sessions in a LAG share the same Sender IP Address and Receiver IP Address 🌈 for the UDP port, they can either all share one Sender Port and Receiver Port pair, or each micro session can get its own pair. operationally, the first option is simpler, so it's RECOMMENDED 💅
test packets of a micro session MUST carry the member link information for validation checks 🙈 for example, when a micro TWAMP Session-Sender gets a reflected test packet, it checks whether that packet came from the expected member link 🔍
3. Micro OWAMP Session 🧚
3.1. Micro OWAMP-Control 🎀
to support micro OWAMP sessions, this doc defines a new command, Request-OW-Micro-Sessions (5) ✨ It's based on the OWAMP Request-Session command and uses the message format described in Section 3.5 of [RFC4656]. creating micro OWAMP sessions follows the same procedure as Section 3.5 of [RFC4656], with the following additions 📚
when an OWAMP Server receives a Request-OW-Micro-Sessions command and the request is accepted, the OWAMP Server MUST build a set of micro sessions for all the member links of the LAG that the Request-OW-Micro-Sessions message came in on 🦋
3.2. Micro OWAMP-Test 💜
micro OWAMP-Test reuses the OWAMP-Test packet format and procedures from Section 4 of [RFC4656], plus the additions below 🌸
the micro OWAMP Session-Sender MUST send micro OWAMP-Test packets over the member link the session is associated with 💅 when the micro OWAMP Session-Receiver gets a test packet, it MUST use the member link that packet arrived on to correlate it to the micro OWAMP session 🫶 if there's no such session, the test packet MUST be discarded 😭
4. Micro TWAMP Session 👑
4.1. Micro TWAMP-Control 🌈
to support micro TWAMP sessions, this doc defines a new command, Request-TW-Micro-Sessions (11) 💖 It's based on the TWAMP Request-Session command and uses the message format described in Section 3.5 of [RFC5357]. creating micro TWAMP sessions follows the same procedure as Section 3.5 of [RFC5357], with the following additions 🧚
when a TWAMP Server receives a Request-TW-Micro-Sessions command and the request is accepted, the TWAMP Server MUST build a set of micro sessions for all the member links of the LAG that the Request-TW-Micro-Sessions message came in on 🎀
4.2. Micro TWAMP-Test 🦋
the micro TWAMP-Test protocol is based on the TWAMP-Test protocol [RFC5357], with the extensions described in the following subsections 🌸
4.2.1. Sender Packet Format and Content ✨
Okay bestie, the micro TWAMP Session-Sender packet is basically the TWAMP Session-Sender packet from Section 4.1.2 of [RFC5357] with a glow-up 💅 It gets two new fields, Sender Micro-session ID and Reflector Micro-session ID, and those carry the LAG member link identifiers 🔥
For unauthenticated mode, the layout looks like this:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Estimate | MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Micro-session ID | Reflector Micro-session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Packet Padding .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 2: Micro Session-Sender Packet Format in Unauthenticated Mode
For authenticated and encrypted mode, it looks like this:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| MBZ (12 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Estimate | MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Micro-session ID | Reflector Micro-session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| HMAC (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Packet Padding .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 3: Micro Session-Sender Packet Format in Authenticated Mode
Apart from the Sender Micro-session ID and Reflector Micro-session ID fields, every other field is the same as in Section 4.1.2 of [RFC5357]. Those fields follow the procedure and guidelines defined there too, so no new drama 🫶
Sender Micro-session ID (2 octets in length): This field carries the LAG member link identifier of the Sender side. In the future it may be used generically for use cases beyond LAGs 🌈 The value of this field MUST be unique within a TWAMP session at the Session-Sender.
Reflector Micro-session ID (2 octets in length): This field carries the LAG member link identifier of the Reflector side. In the future it may be used generically for use cases beyond LAGs 🌸 The value of this field MUST be unique within a TWAMP session at the Session-Reflector.
4.2.2. Sender Behavior
Okay so the micro TWAMP Session-Sender inherits all the behaviors of the TWAMP Session-Sender from Section 4.1 of [RFC5357] 🦋 On top of that, the micro TWAMP Session-Sender MUST send the micro Session-Sender test packets over the member link the session is associated with. Main character energy, but make it link-specific 💖
When it sends a test packet, the micro TWAMP Session-Sender MUST put the Sender member link identifier associated with the micro TWAMP session into the Sender Micro-session ID. If the Session-Sender knows the Reflector member link identifier, the Reflector Micro-session ID field (see Figures 2 and 3) MUST be set. Otherwise, the Reflector Micro-session ID field MUST be zero.
A test packet carrying a Sender member link identifier goes to the Session-Reflector and then gets reflected with that same identifier. So the Session-Sender can use the Sender member link identifier to check whether a reflected test packet came in over the member link tied to the correct micro TWAMP session 👑
The Reflector member link identifier in the Reflector Micro-session ID field is what the Session-Reflector uses to check whether a test packet came in over the member link tied to the correct micro TWAMP session. That means the Session-Sender has to learn the Reflector member link identifier. Once the Session-Sender knows it, the Session-Sender MUST put it into the Reflector Micro-session ID field (see Figures 2 or 3) of the test packets it sends to the Session-Reflector 🧚 The Reflector member link identifier can be obtained from preconfiguration or learned from the data plane (e.g., the reflected test packet). This document does not specify how to obtain the Reflector member link identifier 🙈
When a reflected test packet comes back, the micro TWAMP Session-Sender MUST use the receiving member link to correlate that packet to a micro TWAMP session. If there is no such session, the reflected test packet MUST be discarded. If a matched session exists, the micro Session-Sender MUST use the Sender Micro-session ID to validate whether the reflected test packet was correctly received from the expected member link. If the validation fails, the test packet MUST be discarded. The micro Session-Sender MUST use the Reflector Micro-session ID to validate the Reflector's behavior. If the validation fails, the test packet MUST be discarded. These checks are literally the bouncer at the door of the club 💀✨
4.2.3. Reflector Packet Format and Content ✨
okay so the micro TWAMP Session-Reflector packet is basically a copy of the regular TWAMP Session-Reflector packet from Section 4.2.1 of [RFC5357] 🎀. the only glow-up is two brand new fields, Sender Micro-session ID and Reflector Micro-session ID, which carry the LAG member link identifiers 🦋
there are two versions, one for unauthenticated mode and one for authenticated and encrypted mode.
Unauthenticated mode looks like this:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Estimate | MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receive Timestamp |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Timestamp |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Error Estimate | Sender Micro-session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender TTL | MBZ | Reflector Micro-session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Packet Padding .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Micro Session-Reflector Packet Format in
Unauthenticated ModeAuthenticated and encrypted mode looks like this 🔐:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ (12 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Estimate | MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Micro-session ID | Reflector Micro-session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receive Timestamp |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ (8 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ (12 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Timestamp |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Error Estimate | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| MBZ (6 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender TTL | |
+-+-+-+-+-+-+-+-+ +
| |
| |
| MBZ (15 octets) |
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
| HMAC (16 octets) |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Packet Padding .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Micro Session-Reflector Packet Format in Authenticated ModeEverything else in these packets is exactly the same as Section 4.2.1 of [RFC5357], so it follows the same procedures and guidelines defined there 🌸. Only the two Micro-session ID fields are new:
Sender Micro-session ID(2 octets in length): this field carries the LAG member link identifier on the Sender side 🦋. Later on it may get used for stuff beyond LAGs too. The value of this field MUST be unique within a TWAMP session at the Session-Sender. no duplicates allowed, bestie 🙅♀️Reflector Micro-session ID(2 octets in length): this one carries the LAG member link identifier on the Reflector side 💜. Same vibe as above, it may be used beyond LAGs in the future. The value MUST be unique within a TWAMP session at the Session-Reflector.
4.2.4. Reflector Behavior 👑
The micro TWAMP Session-Reflector gets all the behaviors of a regular TWAMP Session-Reflector from Section 4.2 of [RFC5357]. so it's already built different 💅
It also has some extra moves. When a test packet shows up, the micro TWAMP Session-Reflector MUST use the receiving member link to match that packet to a micro TWAMP session. If there is no such session, the test packet MUST be discarded 🗑️. If the Reflector Micro-session ID is not zero, the Reflector MUST use that ID to check that it's associated with the receiving member link. If the ID is zero, it doesn't get checked at all. And if the validation fails, the test packet MUST be discarded 💀.
When it's time to reply to a test packet, the micro TWAMP Session-Reflector MUST copy the Sender member link identifier from the incoming test packet and put it in the Sender Micro-session ID field of the reflected packet (see Figures 4 and 5) 🪞. It also MUST fill the Reflector Micro-session ID field (see Figures 4 and 5) with the member link identifier that's tied to the micro TWAMP session. iconic teamwork ✨
5. Applicability 🧚
okay so to set up the micro OWAMP sessions, the Control-Client sends the Request-OW-Micro-Sessions command to the OWAMP Server. the OWAMP Server accepts the request and builds a set of micro sessions for all the member links of the LAG 🎀
micro TWAMP sessions follow a similar setup procedure 🌈. after that, the micro TWAMP Session-Sender sends micro Session-Sender packets carrying the Sender Micro-session ID and the Reflector Micro-session ID. if the Reflector Micro-session ID field is set, the micro Session-Reflector checks whether a test packet came in from the member link tied to the correct micro TWAMP session 🔍.
when reflecting, the micro TWAMP Session-Reflector copies the Sender Micro-session ID from the received micro Session-Sender packet over to the micro Session-Reflector packet. then it sets the Reflector Micro-session ID field to the member link identifier tied to the micro TWAMP session 🦋.
when the micro Session-Sender gets a micro TWAMP Session-Reflector packet back, it uses the Sender Micro-session ID to check that the packet came from the member link tied to the correct micro TWAMP session. it also uses the Reflector Micro-session ID to validate the Reflector's behavior 🫶. full accountability, periodt 💅
6. IANA Considerations 📋
6.1. Micro OWAMP-Control Command 💖
IANA has allocated the following command type from the "OWAMP-Control Command Numbers" registry 🎀:
+=======+===========================+===============+
| Value | Description | Reference |
+=======+===========================+===============+
| 5 | Request-OW-Micro-Sessions | This document |
+-------+---------------------------+---------------+
Table 1: Request-OW-Micro-Sessions Command Number6.2. Micro TWAMP-Control Command 🌸
IANA has allocated the following command type from the "TWAMP-Control Command Numbers" registry 🦋:
+=======+===========================+===============+
| Value | Description | Reference |
+=======+===========================+===============+
| 11 | Request-TW-Micro-Sessions | This document |
+-------+---------------------------+---------------+
Table 2: Request-TW-Micro-Sessions Command Number7. Security Considerations 🔐
⚠️ bestie, this part is serious. This document does not introduce additional security requirements and mechanisms other than those described in [RFC4656] and [RFC5357]. so the security stuff comes from those two docs, no extra locks added here 🔒.
8. References 📚
8.1. Normative References
Okay so these are the references the spec needs you to have read, no skipping bestie 📚
[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>.
[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M.
Zekauskas, "A One-way Active Measurement Protocol
(OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006,
<https://www.rfc-editor.org/info/rfc4656>.
[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J.
Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)",
RFC 5357, DOI 10.17487/RFC5357, October 2008,
<https://www.rfc-editor.org/info/rfc5357>.
[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>.
[RFC8668] Ginsberg, L., Ed., Bashandy, A., Filsfils, C., Nanduri,
M., and E. Aries, "Advertising Layer 2 Bundle Member Link
Attributes in IS-IS", RFC 8668, DOI 10.17487/RFC8668,
December 2019, <https://www.rfc-editor.org/info/rfc8668>.8.2. Informative References
These ones are the extra reading 🤓 good for context, but the spec doesn't need you to know them to implement it.
[IEEE802.1AX]
IEEE, "IEEE Standard for Local and Metropolitan Area
Networks -- Link Aggregation", IEEE Std 802.1AX-2020,
DOI 10.1109/IEEESTD.2020.9105034, May 2020,
<https://ieeexplore.ieee.org/document/9105034>.
[RFC7799] Morton, A., "Active and Passive Metrics and Methods (with
Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799,
May 2016, <https://www.rfc-editor.org/info/rfc7799>.Acknowledgements 🫶
The authors wanna give a huge shoutout to Fang Xin, Henrik Nydell, Mach Chen, Min Xiao, Jeff Tantsura, Marcus Ihlar, and Richard Foote for their valuable comments on this work. Literally the MVPs 👑
Authors' Addresses 💌
Zhenqiang Li
China Mobile
No. 29 Finance Avenue
Xicheng District
Beijing
China
Email: li_zhenqiang@hotmail.com
Tianran Zhou
Huawei
China
Email: zhoutianran@huawei.com
Jun Guo
ZTE Corp.
China
Email: guo.jun2@zte.com.cn
Greg Mirsky
Ericsson
United States of America
Email: gregimirsky@gmail.com
Rakesh Gandhi
Cisco Systems, Inc.
Canada
Email: rgandhi@cisco.com📦 where this page comes from
- ietf: rfc9533 2024-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms