idnits 2.17.1 draft-yang-mpls-ps-sdi-sr-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 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 (November 2, 2020) is 1271 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC7271' is defined on line 288, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ali-spring-bfd-sr-policy-05 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group F. Yang 3 Internet-Draft Huawei Technologies 4 Intended status: Informational L. Han 5 Expires: May 6, 2021 China Mobile 6 J. Zhao 7 China Academy of Information Communications Technology 8 November 2, 2020 10 Problem Statement of Signal Degrade Indication for SR over MPLS 11 draft-yang-mpls-ps-sdi-sr-01 13 Abstract 15 This document outlines the problem statements and the use cases 16 needed to be taken into account when the signal degrade is detected 17 and indicated in Segment Routing (SR) over MPLS networks. 19 Requirements Language 21 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 22 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 23 document are to be interpreted as described in RFC 2119 [RFC2119]. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on May 6, 2021. 42 Copyright Notice 44 Copyright (c) 2020 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Problem Statement and Use Case . . . . . . . . . . . . . . . 3 62 3.1. Overview of Signal Degrade in SR over MPLS Network . . . 3 63 3.2. Influence on Voice and Data Service . . . . . . . . . . . 4 64 3.3. Engineering Considerations . . . . . . . . . . . . . . . 4 65 3.3.1. Signal Degrade in Diversity of PHYs . . . . . . . . . 4 66 3.3.2. Performance Management Detection . . . . . . . . . . 4 67 3.3.3. BFD Detection . . . . . . . . . . . . . . . . . . . . 5 68 3.4. LER and LSR Consideration . . . . . . . . . . . . . . . . 5 69 3.5. Signal Degrade Approach . . . . . . . . . . . . . . . . . 5 70 3.6. Parameter Threshold . . . . . . . . . . . . . . . . . . . 5 71 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 72 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 73 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 74 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 75 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 76 7.2. Informative References . . . . . . . . . . . . . . . . . 6 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 79 1. Introduction 81 Signal Failure (SF) and Signal Degrade (SD) are categorized as the 82 trigger to bring the survivability challenge to the network in 83 [RFC4428]. Signal Failure (SF) can be interpreted as the absence of 84 the network resources, and Signal Degrade (SD) can be regarded as the 85 decrease of the signal quality quantifiable measurement. The 86 meanings of signal failure is straightforward, indicating the failure 87 of the interfaces, links or nodes. Meanwhile, fiber aging, fiber 88 impairment, fiber pollution, optical module mismatch or WDM 89 transmission error are the potential reasons to generate signal 90 degrade. 92 Segment Routing(SR) leverages the source routing paradigm. In the 93 era of source routing paradigm, Segment Routing over MPLS (SR-MPLS) 94 [RFC8402] has been widely utilized for different kinds of network 95 scenarios. It is valuable to investigate the necessity of supporting 96 detection of Signal Degrade (SD) in the source routing paradigm. 98 This document gives the problem statements for the Signal Degrade 99 indication and advertisement in the networks of SR over MPLS (SR- 100 MPLS). The triggered protection mechanism is irrelevant to Signal 101 Degrade indication and consequently is out of scope. 103 2. Terminology 105 SD: Signal Degrade 107 PLR: Packet Loss Rate 109 SLA: Service Level Agreement 111 FEC: Forwarding Error Correction 113 BFD: Bidirectional Forwarding Detection 115 3. Problem Statement and Use Case 117 3.1. Overview of Signal Degrade in SR over MPLS Network 119 +-----+ +-----+ 120 +-------|LSR1 |-----|LSR2 |------+ 121 | +-----+ +-----+ | 122 | \ / | 123 | \ / | 124 +-----+ +-----+ +-----+ 125 -----|LER1 | |LSR5 | |LER2 |----- 126 +-----+ +-----+ +-----+ 127 | / \ | 128 | / \ | 129 | +-----+ +-----+ | 130 +-------|LSR3 |-----|LSR4 |------+ 131 +-----+ +-----+ 133 Figure 1: Overview of Signal Degrade in SR over MPLS Network 135 Figure 1 depicts the overview of the signal degrade detection in the 136 segment routing over MPLS network. LER1 and LER2 are the Label Edge 137 Routers, and LSR1 to LSR5 are the Label Switching Routers. The 138 signal degrade can happen at any links in the SR over MPLS network, 139 not only the links connected to LERs, but also the links between 140 LSRs. There is no signal degrade is defined in the current OAM 141 [I-D.ietf-spring-sr-oam-requirement] or BFD 142 [I-D.ali-spring-bfd-sr-policy] mechanisms designed for SR over MPLS 143 network. 145 3.2. Influence on Voice and Data Service 147 In mobile backhaul network, signal degrade may not lead to service 148 interruption, however it impairs the services and dissatisfies the 149 Service Level Agreements (SLAs). Take VoLTE service as an example, 150 signal degrade over the optical transmission can bring noise, carton, 151 call delay, drop line or even cause base station disconnection. In 152 addition, the download speed of data service would decrease 153 dramatically when signal degrade increases. There are some 154 statistics captured from live network shown in Table 1. 156 +------------------+---------------------------+ 157 | Packet Loss Rate | Decrease of Download Rate | 158 +------------------+---------------------------+ 159 | 0 | No affect | 160 | <0.01% | No affect | 161 | 0.05% | 23% | 162 | 0.2% | 58% | 163 | 1% | 75% | 164 +------------------+---------------------------+ 166 Table 1 Relation between Packet Loss Rate and Decrease of Download 167 Rate 169 3.3. Engineering Considerations 171 3.3.1. Signal Degrade in Diversity of PHYs 173 From the perspective of engineering, there are a variety of PHYs 174 defined in IEEE 802.3. The PHYs without Forward Error Correction 175 (FEC) generates the defects/alarms, PHYs with the FEC correct the bit 176 errors. There is no uniform mechanism to guarantee the control of 177 the bit errors. 179 3.3.2. Performance Management Detection 181 The approaches of OAM performance management can be used as the tools 182 to detect the signal degrade. On one hand, active performance 183 management cannot fulfill the Signal Degrade detection all the time. 184 On the other hand, passive performance management consumes too much 185 resource of the equipment so that operators can hardly use it in the 186 networks. The current performance management mechanism is not 187 feasible to detect signal degrade conveniently and efficiently. 189 3.3.3. BFD Detection 191 For the worst case, when signal degrade happens on LSRs, the current 192 best practice is to make use of the result of BFD protocol on LERs to 193 trigger the protection mechanism. The detection time is at least 194 3.3ms*3 later than the time when the signal degrade happens. If the 195 LSRs can trigger the protection protocol in a more direct and 196 efficient way, the network service interruption time can be reduced. 198 3.4. LER and LSR Consideration 200 There are local and remote request logics about the signal degrade 201 defined in [RFC6378]. Meanwhile, the Protection State Coordination 202 (PSC) process and the messages are utilized to advertise and exchange 203 the signal degrade state between LERs. In the network of MPLS-TP, 204 the LSRs stay dumb in the transmission of OAM messages. 206 In the SR over MPLS networks, only the headend LER knows all the 207 segments in the label stack, the other LSRs and LER2 does not know 208 the entire label stack. As for the signal degrade happens on either 209 headend LER or other LSRs and LER, the mechanism of the signal 210 degrade indication would be differently designed. 212 3.5. Signal Degrade Approach 214 In Section 4.1 of [RFC6372], approaches of detection or recognition 215 of network defect such as signal degrade are specified. The signal 216 degrade indication can be detected from a network defect, or 217 advertised by an in-band data-plane-based OAM mechanism, or by in- 218 band or out-of-band control-plane signaling, or triggered from the 219 centralized Network Management System (NMS) or a SDN controller. The 220 appropriate approaches should be wisely selected. 222 3.6. Parameter Threshold 224 Parameters like BER or PLR are the different quantitative measurement 225 methods. It is flexible for the service providers to set different 226 values of threshold based on the geographical site investigations. 227 For an even more complicated scenario, the threshold may be defined 228 differently in terms of services, for example to differentiate the 229 requirements of the eMBB or URLLC applications in 5G era. 231 4. IANA Considerations 233 This document makes no request of IANA. 235 Note to RFC Editor: this section may be removed on publication as an 236 RFC. 238 5. Security Considerations 240 This document has no consideration of security. 242 Note to RFC Editor: this section may be removed on publication as an 243 RFC. 245 6. Acknowledgements 247 TBD 249 7. References 251 7.1. Normative References 253 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 254 Requirement Levels", BCP 14, RFC 2119, 255 DOI 10.17487/RFC2119, March 1997, 256 . 258 7.2. Informative References 260 [I-D.ali-spring-bfd-sr-policy] 261 Ali, Z., Talaulikar, K., Filsfils, C., Nainar, N., and C. 262 Pignataro, "Bidirectional Forwarding Detection (BFD) for 263 Segment Routing Policies for Traffic Engineering", draft- 264 ali-spring-bfd-sr-policy-05 (work in progress), May 2020. 266 [I-D.ietf-spring-sr-oam-requirement] 267 Kumar, N., Pignataro, C., Akiya, N., Geib, R., Mirsky, G., 268 and S. Litkowski, "OAM Requirements for Segment Routing 269 Network", draft-ietf-spring-sr-oam-requirement-03 (work in 270 progress), January 2017. 272 [RFC4428] Papadimitriou, D., Ed. and E. Mannie, Ed., "Analysis of 273 Generalized Multi-Protocol Label Switching (GMPLS)-based 274 Recovery Mechanisms (including Protection and 275 Restoration)", RFC 4428, DOI 10.17487/RFC4428, March 2006, 276 . 278 [RFC6372] Sprecher, N., Ed. and A. Farrel, Ed., "MPLS Transport 279 Profile (MPLS-TP) Survivability Framework", RFC 6372, 280 DOI 10.17487/RFC6372, September 2011, 281 . 283 [RFC6378] Weingarten, Y., Ed., Bryant, S., Osborne, E., Sprecher, 284 N., and A. Fulignoli, Ed., "MPLS Transport Profile (MPLS- 285 TP) Linear Protection", RFC 6378, DOI 10.17487/RFC6378, 286 October 2011, . 288 [RFC7271] Ryoo, J., Ed., Gray, E., Ed., van Helvoort, H., 289 D'Alessandro, A., Cheung, T., and E. Osborne, "MPLS 290 Transport Profile (MPLS-TP) Linear Protection to Match the 291 Operational Expectations of Synchronous Digital Hierarchy, 292 Optical Transport Network, and Ethernet Transport Network 293 Operators", RFC 7271, DOI 10.17487/RFC7271, June 2014, 294 . 296 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 297 Decraene, B., Litkowski, S., and R. Shakir, "Segment 298 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 299 July 2018, . 301 Authors' Addresses 303 Fan Yang 304 Huawei Technologies 306 Email: shirley.yangfan@huawei.com 308 Liuyan Han 309 China Mobile 311 Email: hanliuyan@chinamobile.com 313 Junfeng Zhao 314 China Academy of Information Communications Technology 316 Email: zhaojunfeng@caict.ac.cn