idnits 2.17.1 draft-hwy-bfd-sdi-00.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.yang-mpls-ps-sdi-sr]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 25, 2021) is 914 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) == Unused Reference: 'RFC5586' is defined on line 265, but no explicit reference was found in the text == Unused Reference: 'RFC6372' is defined on line 270, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BFD Working Group L. Han 3 Internet-Draft M. Wang 4 Intended status: Standards Track China Mobile 5 Expires: April 28, 2022 F. Yang 6 Huawei Technologies 7 October 25, 2021 9 Signal Degrade Indication in BFD 10 draft-hwy-bfd-sdi-00 12 Abstract 14 To satisfy the requirements of signal degrade indication described in 15 [I-D.yang-mpls-ps-sdi-sr], this document illustrates the extension of 16 BFD protocol to support signal degrade indication. 18 Requirements Language 20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 21 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 22 document are to be interpreted as described in RFC 2119 [RFC2119]. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on April 28, 2022. 41 Copyright Notice 43 Copyright (c) 2021 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Background . . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 60 3. Signal Degrade Overview . . . . . . . . . . . . . . . . . . . 3 61 3.1. Signal Degrade Definition . . . . . . . . . . . . . . . . 3 62 3.2. Signal Degrade vs Packet Loss Rate . . . . . . . . . . . 3 63 3.3. Use BFD to Support Signal Degrade Indication . . . . . . 4 64 3.4. Notification Spread in Network . . . . . . . . . . . . . 4 65 4. BFD Extension to Indicate Signal Degrade . . . . . . . . . . 4 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 68 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 70 7.2. Informative References . . . . . . . . . . . . . . . . . 6 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 73 1. Background 75 Signal Degrade (SD) is categorized as one of triggers to bring 76 survivability challenge to networks [RFC4428]. Not like the signal 77 failure caused by failure of links or nodes, Signal Degrade (SD) is 78 normally caused by fiber aging, fiber impairment, fiber pollution, 79 optical module mismatch or WDM transmission error etc. 81 The detection and transmission of signal degrade is discussed in 82 [I-D.zhl-mpls-tp-sd] and [I-D.yang-mpls-ps-sdi-sr]. When signal 83 degrade is detected, it can be spread via control plane, forwarding 84 plane, or management plane, or combination of any of them. 86 BFD [RFC5880] and SBFD [RFC7880] are widely used as the failure 87 notification in networks due to the characteristics of simplicity and 88 efficiency. BFD also provides good opportunity to indicate signal 89 degrade by reflecting it in BFD state changes. This document extends 90 the BFD protocol to carry signal degrade indication in networks. 92 2. Terminology 94 SD: Signal Degrade 96 BER: Bit Error Rate 97 MIP: Maintenance Entity Group Intermediate Point 99 PLR: Packet Loss Rate 101 FEC: Forwarding Error Correction 103 SLA: Service Level Agreement 105 BFD: Bidirectional Forwarding Detection 107 SBFD: Seamless BFD 109 OAM: Operation, Administration and Maintenance 111 3. Signal Degrade Overview 113 3.1. Signal Degrade Definition 115 In [IEEE 802.3-2018], Bit Error Rate (BER) is defined as the ratio of 116 the number of bits received in error to the total number of bits 117 received. It is one of parameters to indicate quality of physical 118 links. Depending on the Forwarding Error Correction (FEC) capability 119 of PHYs, BER can be classified into pre-FEC BER and post-FEC BER. 120 The pre-FEC BER value acquired from PHY on receiving port indicates 121 the on wire BER value of physical link. This value can also be 122 measured via external test instruments. Generally speaking, BER 123 specifically refers to pre-FEC BER. If FEC capability is unavailable 124 for some legacy PHYs, it is meaningless to differentiate pre-FEC and 125 post-FEC BER values. 127 Signal degrade can be detected based on the physical bit error 128 statistic on port level, no matter whether the PHY is with or without 129 Forwarding Error Correction. Port level statistic is an intuitive 130 approach to be best understood in the equipment and network systems. 131 In practice, flexible configuration of the watermark to trigger the 132 indication of signal degrade is also preferred. 134 3.2. Signal Degrade vs Packet Loss Rate 136 In packet switched network, the measurement of physical link is based 137 on the unit of packet, resulting in either no packet loss or a number 138 of packet loss to indicate the status of link. Although PHYs are 139 defined in [IEEE 802.3-2018], vendors may have different 140 implementations to deal with the error bits when equipment detects 141 them. Moreover, bit is a fix unit, but packet has variable length. 142 Several error bits can lead to one packet loss, or multiple packets' 143 loss. There is no uniform approach to calculate pre-FEC BER into 144 PLR. It means there is no parameter directly indicated the status of 145 physical links in packet switched network. 147 3.3. Use BFD to Support Signal Degrade Indication 149 For the network where BFD is used to provide the fast failure 150 detection, the minimal detection interval e.g. 3.3ms actually leaves 151 a huge gap of data packets between two consecutive BFD packets when 152 the line rate packets are transmitted over high speed Ethernet link. 153 Take an example of 10Gbps link transmitting the packets with length 154 of 192 bytes to calculate, more than twenty thousand packets are 155 transmitted within 3.3ms. Note that the criteria to announce a 156 failure of BFD based on three consecutive BFD packet loss. It may 157 not be accurate to rely on BFD to detect and trigger the protection 158 mechanism if there is signal degrade on the physical link. 160 3.4. Notification Spread in Network 162 In current packet switched networks, the error bit information like 163 BER is only obtained and processed locally on each node. There is no 164 indication or advertisement of the errors or its indications of 165 physical links. It should be possible to spread this information via 166 control plane, management plane or even data plane to suit for 167 different needs. Especially, if the signal degrade of the link could 168 be transmitted in data plane and aware by any other nodes, local 169 repair or end-to-end path protection could be performed even more 170 efficiently. Previous work proposed in [I-D.rkhd-mpls-tp-sd], 171 [I-D.zhl-mpls-tp-sd] and [I-D.zhang-ccamp-rsvpte-ber-measure] give 172 the examples of protocol extensions to support SD transmission for 173 further network convergence behaviors. With the emerge of telemetry, 174 it is also possible to collect and report this information more 175 frequently to SDN controller to facilitate the network operation and 176 management. 178 4. BFD Extension to Indicate Signal Degrade 180 The Diagnostic code in BFD specifies the local system's reason for 181 the last change in session state. The definition of the Values is 182 specified in Section 4.1 of [RFC5880]. 184 In this document, reserved values from 9 to 31 are requested to IANA 185 to support the signal degrade indication and removal. 187 (preamble) 189 0 1 2 3 190 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 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 |Vers | Diag |Sta|P|F|C|A|D|M| Detect Mult | Length | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | My Discriminator | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | Your Discriminator | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | Desired Min TX Interval | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | Required Min RX Interval | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | Required Min Echo RX Interval | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | Authentication (optional) | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 BFD Packet Format 209 5. IANA Considerations 211 The document requires the definition of the new indication and 212 removal of the signal degrade indication in BFD Value code. 214 6. Security Considerations 216 TBD 218 7. References 220 7.1. Normative References 222 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 223 Requirement Levels", BCP 14, RFC 2119, 224 DOI 10.17487/RFC2119, March 1997, 225 . 227 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 228 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 229 . 231 [RFC7880] Pignataro, C., Ward, D., Akiya, N., Bhatia, M., and S. 232 Pallagatti, "Seamless Bidirectional Forwarding Detection 233 (S-BFD)", RFC 7880, DOI 10.17487/RFC7880, July 2016, 234 . 236 7.2. Informative References 238 [I-D.rkhd-mpls-tp-sd] 239 Ram, R., Cohn, D., Daikoku, M., Yuxia, M., Jian, Y., and 240 A. D'Alessandro, "SD detection and protection triggering 241 in MPLS-TP", draft-rkhd-mpls-tp-sd-03 (work in progress), 242 May 2011. 244 [I-D.yang-mpls-ps-sdi-sr] 245 Yang, F., Han, L., and J. Zhao, "Problem Statement of 246 Signal Degrade Indication for SR over MPLS", draft-yang- 247 mpls-ps-sdi-sr-01 (work in progress), November 2020. 249 [I-D.zhang-ccamp-rsvpte-ber-measure] 250 Li, Z., Zhang, L., and G. Yang, "RSVP-TE Extensions for 251 Bit Error Rate (BER) Measurement", draft-zhang-ccamp- 252 rsvpte-ber-measure-02 (work in progress), July 2014. 254 [I-D.zhl-mpls-tp-sd] 255 Haiyan, Z., Jia, H., and H. Li, "SD-Triggered Protection 256 Switching in MPLS-TP", draft-zhl-mpls-tp-sd-03 (work in 257 progress), October 2010. 259 [RFC4428] Papadimitriou, D., Ed. and E. Mannie, Ed., "Analysis of 260 Generalized Multi-Protocol Label Switching (GMPLS)-based 261 Recovery Mechanisms (including Protection and 262 Restoration)", RFC 4428, DOI 10.17487/RFC4428, March 2006, 263 . 265 [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., 266 "MPLS Generic Associated Channel", RFC 5586, 267 DOI 10.17487/RFC5586, June 2009, 268 . 270 [RFC6372] Sprecher, N., Ed. and A. Farrel, Ed., "MPLS Transport 271 Profile (MPLS-TP) Survivability Framework", RFC 6372, 272 DOI 10.17487/RFC6372, September 2011, 273 . 275 Authors' Addresses 277 Liuyan Han 278 China Mobile 279 No.32 Xuanwumen west street 280 Beijing 100053 281 China 283 Email: hanliuyan@chinamobile.com 284 Minxue Wang 285 China Mobile 286 No.32 Xuanwumen west street 287 Beijing 100053 288 China 290 Email: wangminxue@chinamobile.com 292 Fan Yang 293 Huawei Technologies 294 Huawei Campus, No. 156 Beiqing Rd. 295 Beijing 100095 296 China 298 Email: shirley.yangfan@huawei.com