idnits 2.17.00 (12 Aug 2021) /tmp/idnits42994/draft-li-ippm-stamp-on-lag-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (January 24, 2022) is 117 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 7799 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-14 Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Z. Li 3 Internet-Draft China Mobile 4 Intended status: Standards Track T. Zhou 5 Expires: July 28, 2022 Huawei 6 J. Guo 7 ZTE Corp. 8 G. Mirsky 9 Ericsson 10 R. Gandhi 11 Cisco 12 January 24, 2022 14 Simple Two-Way Active Measurement Protocol Extensions for Performance 15 Measurement on LAG 16 draft-li-ippm-stamp-on-lag-01 18 Abstract 20 This document extends Simple Two-Way Active Measurement Protocol 21 (STAMP) to implement performance measurement on every member link of 22 a Link Aggregation Group (LAG). Knowing the measured metrics of each 23 member link of a LAG enables operators to enforce a performance based 24 traffic steering policy across the member links. 26 Requirements Language 28 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 29 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 30 "OPTIONAL" in this document are to be interpreted as described in 31 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, 32 as shown here. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on July 28, 2022. 50 Copyright Notice 52 Copyright (c) 2022 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Micro Session on LAG . . . . . . . . . . . . . . . . . . . . 3 69 3. Member Link Validation . . . . . . . . . . . . . . . . . . . 4 70 3.1. LAG Member Link ID TLV . . . . . . . . . . . . . . . . . 4 71 3.2. Micro STAMP-Test Procedures . . . . . . . . . . . . . . . 5 72 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 73 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 74 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 75 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 76 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 77 7.2. Informative References . . . . . . . . . . . . . . . . . 7 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 80 1. Introduction 82 Link Aggregation Group (LAG), as defined in [IEEE802.1AX], provides 83 mechanisms to combine multiple physical links into a single logical 84 link. This logical link offers higher bandwidth and better 85 resiliency, because if one of the physical member links fails, the 86 aggregate logical link can continue to forward traffic over the 87 remaining operational physical member links. 89 Usually, when forwarding traffic over LAG, the hash-based mechanism 90 is used to load balance the traffic across the LAG member links. 91 Link delay of each member link varies because of different transport 92 paths. To provide low latency service for time sensitive traffic, we 93 need to explicitly steer the traffic across the LAG member links 94 based on the link delay, loss and so on. That requires a solution to 95 measure the performance metrics of each member link of a LAG. 97 Simple Two-Way Active Measurement Protocol (STAMP) [RFC8762] is an 98 active measurement method according to the classification given in 99 RFC7799 [RFC7799]. It provides a mechanism to measure both one-way 100 and round-trip performance metrics, like delay, delay variation, and 101 packet loss. Running a single STAMP test session over the 102 aggregation without the knowledge of each member link would make it 103 impossible to measure the performance of a given physical member 104 link. The measured metrics can only reflect the performance of one 105 member link or an average of some/all member links of the LAG. 107 This document extends STAMP to implement performance measurement on 108 every member link of a LAG. The proposed method could also 109 potentially apply to layer 3 ECMP (Equal Cost Multi-Path), e.g., with 110 SR-Policy [I-D.ietf-spring-segment-routing-policy]. 112 2. Micro Session on LAG 114 This document intends to address the scenario (e.g., Figure 1) where 115 a LAG (e.g., the LAG includes three member links) directly connects 116 two nodes (A and B) . The goal is to measure the performance of each 117 link of the LAG. 119 +---+ +---+ 120 | |-----------------------| | 121 | A |-----------------------| B | 122 | |-----------------------| | 123 | |-----------------------| | 124 +---+ +---+ 126 Figure 1: PM for LAG 128 To measure the performance metrics of every member link of a LAG, 129 multiple sessions (one session for each member link) need to be 130 established between the two end points that are connected by the LAG. 131 These sessions are called micro sessions in the remainder of this 132 document. 134 All micro sessions of a LAG share the same Sender IP Address and 135 Receiver IP Address. As for the UDP Port, the micro sessions may 136 share the same Sender Port and Receiver Port pair, or each micro 137 session is configured with a different Sender Port and Receiver Port 138 pair. But from the operational point of view, the former is simpler 139 and is recommended. 141 At the Sender side, each micro STAMP session MUST be assgined with a 142 unique SSID [RFC8972]. Both the micro STAMP Session Sender and 143 Reflector MUST use SSID to correlate the Test packet to a micro 144 session. If there is no such a session, or the SSID is not correct, 145 the Test packet MUST be discarded. 147 Test packets MAY carry the member link information for validation 148 check. For example, when a micro STAMP Session-Sender receives a 149 reflected Test packet, it may need to check whether the Test packet 150 is from the expected member link. The detailed description about the 151 member link validation is in section 3. 153 A micro STAMP Session-Sender MAY include the Follow-Up Telemetry TLV 154 [RFC8972] to request information from the micro Session-Reflector. 155 This timestamp might be important for the micro Session-Sender, as it 156 improves the accuracy of network delay measurement by minimizing the 157 impact of egress queuing delays on the measurement. 159 3. Member Link Validation 161 Test packets MAY carry the member link information for validation 162 check. The micro Session Sender can verify whether the test packet 163 is reveived from the expected member link. It can also verify 164 whether the packet is sent from the expected member link at the 165 Reflector side. The micro Session Reflector can verify whether the 166 test packet is received from the expected member link. 168 3.1. LAG Member Link ID TLV 170 STAMP TLV [RFC8972] mechanism extends STAMP Test packets with one or 171 more optional TLVs. This document defines the TLV Type (value TBA1) 172 for the LAG Member Link ID TLV that carries the micro STAMP Session- 173 Sender member link identifier and Session-Reflector member link 174 identifier. The format of the LAG Member Link ID TLV is shown as 175 follows: 177 0 1 2 3 178 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 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 |STAMP TLV Flags| Type = TBA1 | Length | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | Sender Member Link ID | Reflector Member Link ID | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 Figure 2: LAG Member Link ID TLV 187 o Type: A one-octet field. Value TBA1 is allocated by IANA 188 (Section 5). 190 o Length: A two-octet field equal to the length of the Value field 191 in octets. The Length field value MUST be 4 octets. 193 o Sender Member Link ID (2-octets in length): it is defined to carry 194 the LAG member link identifier of the Sender side. The value of 195 the Sender Member Link ID MUST be unique at the Session-Sender. 197 o Reflector Member Link ID (2-octets in length): it is defined to 198 carry the LAG member link identifier of the Reflector side. The 199 value of the Reflector Member ID MUST be unique at the Session- 200 Reflector. 202 3.2. Micro STAMP-Test Procedures 204 The micro STAMP-Test reuses the procedures as defined in Section 4 of 205 STAMP [RFC8762] with the following additions. 207 The micro STAMP Session-Sender MUST send the micro STAMP-Test packets 208 over the member link with which the session is associated. The 209 configuration and management of the mapping between a micro STAMP 210 session and the Sender/Reflector member link identifiers are outside 211 the scope of this document. 213 When sending a Test packet, the micro STAMP Session-Sender MUST set 214 the Sender Member Link ID field with the member link identifier 215 associated with the micro STAMP session. If the Session-Sender knows 216 the Reflector member link identifier, the Reflector Member Link ID 217 field MUST be set. Otherwise, the Reflector Member Link ID field 218 MUST be zero. The Reflector member link identifier can be obtained 219 from pre-configuration or learned through data plane (e.g., learned 220 from a reflected Test packet). How to obtain/learn the Reflector 221 member link identifier is outside of this document's scope. 223 When the micro STAMP Session-Reflector receives a Test packet, if the 224 Reflector Member Link ID is not zero, the micro STAMP Session- 225 Reflector MUST use the Reflector member link identifier to check 226 whether it is associated with the micro STAMP session. If the 227 validation fails, the Test packet MUST be discarded. If all 228 validations passed, the Session-Reflector sends a reflected Test 229 packet to the Session-Sender. The micro STAMP Session-Reflector MUST 230 put the Sender and Reflector member link identifiers that are 231 associated with the micro STAMP session in the Sender Member Link ID 232 and Reflector Member Link ID fields respectively. The Sender member 233 link identifier is copied from the received Test packet. 235 When receiving a reflected Test packet, the micro Session-Sender MUST 236 use the Sender Member Link ID to validate whether the reflected Test 237 packet is correctly transmitted over the expected member link. If 238 the validation fails, the Test packet MUST be discarded. The micro 239 Session-Sender MUST use the Reflector Member Link ID to validate the 240 Reflector's behavior. If the validation fails, the Test packet MUST 241 be discarded. 243 4. IANA Considerations 245 In the "STAMP TLV Types" registry created for [RFC8972], a new STAMP 246 TLV Type for LAG Member Link ID TLV is requested from IANA as 247 follows: 249 +----------------+-------------------+-----------------+------------+ 250 | STAMP TLV Type | Description | Semantics | Reference | 251 | Value | | Definition | | 252 +----------------+-------------------+-----------------+------------+ 253 | TBA1 | LAG Member Link | Section 3 | This | 254 | | ID TLV | | Document | 255 +----------------+-------------------+-----------------+------------+ 257 New STAMP TLV Type 259 5. Security Considerations 261 The STAMP extension defined in this document is intended for 262 deployment in LAG scenario where Session-Sender and Session-Reflector 263 are directly connnected. As such, it's assumed that a node involved 264 in STAMP protocol operation has previously verified the integrity of 265 the LAG connection and the identity of its one-hop-away peer node. 267 This document does not introduce any additional security issues and 268 the security mechanisms defined in [RFC8762] and [RFC8972] apply in 269 this document. 271 6. Acknowledgements 273 The authors would like to thank Mach Chen, Min Xiao, Fang Xin for the 274 valuable comments to this work. 276 7. References 278 7.1. Normative References 280 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 281 Requirement Levels", BCP 14, RFC 2119, 282 DOI 10.17487/RFC2119, March 1997, 283 . 285 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 286 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 287 May 2016, . 289 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 290 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 291 May 2017, . 293 [RFC8762] Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple 294 Two-Way Active Measurement Protocol", RFC 8762, 295 DOI 10.17487/RFC8762, March 2020, 296 . 298 [RFC8972] Mirsky, G., Min, X., Nydell, H., Foote, R., Masputra, A., 299 and E. Ruffini, "Simple Two-Way Active Measurement 300 Protocol Optional Extensions", RFC 8972, 301 DOI 10.17487/RFC8972, January 2021, 302 . 304 7.2. Informative References 306 [I-D.ietf-spring-segment-routing-policy] 307 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 308 P. Mattes, "Segment Routing Policy Architecture", draft- 309 ietf-spring-segment-routing-policy-14 (work in progress), 310 October 2021. 312 [IEEE802.1AX] 313 IEEE Std. 802.1AX, "IEEE Standard for Local and 314 metropolitan area networks - Link Aggregation", November 315 2008. 317 Authors' Addresses 319 Zhenqiang Li 320 China Mobile 322 Email: li_zhenqiang@hotmail.com 324 Tianran Zhou 325 Huawei 326 China 328 Email: zhoutianran@huawei.com 330 Jun Guo 331 ZTE Corp. 332 China 334 Email: guo.jun2@zte.com.cn 335 Greg Mirsky 336 Ericsson 337 United States of America 339 Email: gregimirsky@gmail.com 341 Rakesh Gandhi 342 Cisco 343 Canada 345 Email: rgandhi@cisco.com