Multiprotocol Label Switching Working Group                      F. Yang
Internet-Draft                                                    Huawei
Intended status: Informational                                    L. Han
Expires: September 10, 2020                                 China Mobile
                                                                 J. Zhao
                                                                   CAICT
                                                           March 9, 2020


Problem Statement of Signal Degrade Indication for Segment Routing over
                              MPLS Network
                      draft-yang-mpls-ps-sdi-sr-00

Abstract

   This document outlines the problem statements and the use cases
   needed to be taken into account when the signal degrade is detected
   and indicated in the networks of Segment Routing (SR) over MPLS.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 10, 2020.

Copyright Notice

   Copyright (c) 2020 IETF Trust and the persons identified as the
   document authors.  All rights reserved.





Yang, et al.           Expires September 10, 2020               [Page 1]


Internet-Draft        draft-yang-mpls-ps-sdi-sr-00            March 2020


   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 Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Problem Statement and Use Case  . . . . . . . . . . . . . . .   3
     3.1.  Overview of Signal Degrade in SR over MPLS Network  . . .   3
     3.2.  Influence on Voice and Data Service . . . . . . . . . . .   4
     3.3.  Engineering Considerations  . . . . . . . . . . . . . . .   5
       3.3.1.  Signal Degrade in Diversity of PHYs . . . . . . . . .   5
       3.3.2.  Performance Management Detection  . . . . . . . . . .   5
       3.3.3.  BFD Detection . . . . . . . . . . . . . . . . . . . .   5
     3.4.  LER and LSR Consideration . . . . . . . . . . . . . . . .   5
     3.5.  Signal Degrade Approach . . . . . . . . . . . . . . . . .   6
     3.6.  Isolation of Signal Degrade Detection and Protection  . .   6
     3.7.  Parameter Threshold . . . . . . . . . . . . . . . . . . .   6
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   Signal Failure (SF) and Signal Degradation (SD) are categorized as
   the trigger to bring the survivability challenge to the network in
   [RFC6372].  Signal Failure (SF) can be interpreted as the absence of
   the network resources, and Signal Degradation (SD) can be regarded as
   the decrease of the signal quality quantifiable measurement.  The
   meanings of signal failure is straightforward, indicating the failure
   of the interfaces, links or nodes.  Meanwhile, fiber aging, fiber
   impairment, fiber pollution, optical module mismatch or WDM
   transmission error are the potential reasons to generate signal
   degrade.

   In [RFC6378], linear protection mechanisms for the MPLS Transport
   Profile (MPLS-TP) are introduced, and the protection switching



Yang, et al.           Expires September 10, 2020               [Page 2]


Internet-Draft        draft-yang-mpls-ps-sdi-sr-00            March 2020


   protocol associated with Signal Failure (SF) is specified.
   Similarly, [RFC7271] specifies the mechanisms of linear protection
   functions for SDH, OTN and Ethernet transport networks, and the
   capability of supporting the protection against Signal Degrade (SD)
   in Section 7.  The drafts [I-D.rkhd-mpls-tp-sd] and
   [I-D.zhl-mpls-tp-sd] also gives detailed descriptions about the
   Signal Degrade (SD) detection and the consequent triggered protection
   mechanism.

   In the era of the source routing paradigm, Segment Routing over MPLS
   (SR-MPLS) [RFC8402] would be widely utilized for any kinds of network
   scenarios, not only the Ethernet metro/IP core or data center, but
   also the IP Radio Access Networks (RAN).  It is evaluable to
   investigate the necessity of supporting detection of Signal Degrade
   (SD) and the protection mechanisms against it in the source routing
   paradigm.

   This document gives the problem statements as well as several use
   cases for the Signal Degrade indication and advertisement in the
   networks of SR over MPLS (SR-MPLS).  The approach of signal degrade
   detection has been explicitly defined in IEEE 802.3 series standard.
   The triggered protection mechanism is irrelevant to Signal Degrade
   indication and consequently is out of scope.

2.  Terminology

   TBD

3.  Problem Statement and Use Case

3.1.  Overview of Signal Degrade in SR over MPLS Network

   In the present mobile backhaul network, 3G/4G services are operated
   on different flavors of MPLS.  Figure 1 depicts the overview of the
   signal degrade detection in the segment routing over MPLS network.
















Yang, et al.           Expires September 10, 2020               [Page 3]


Internet-Draft        draft-yang-mpls-ps-sdi-sr-00            March 2020


                  +-----+     +-----+
          +-------|LSR1 |-----|LSR2 |------+
          |       +-----+     +-----+      |
          |             \    /             |
          |              \  /              |
        +-----+         +-----+         +-----+
   -----|LER1 |         |LSR5 |         |LER2 |-----
        +-----+         +-----+         +-----+
          |              /  \              |
          |             /    \             |
          |       +-----+     +-----+      |
          +-------|LSR3 |-----|LSR4 |------+
                  +-----+     +-----+

       Figure 1: Overview of Signal Degrade in SR over MPLS Network

   LER1 and LER2 are the Label Edge Routers, and LSR1 to LSR5 are the
   Label Switching Routers.  The signal degrade can happen at any links
   in the SR over MPLS network, not only the links connected to LERs,
   but also the links between LSRs.  There is no signal degradation is
   defined in the current OAM [I-D.ietf-spring-sr-oam-requirement] or
   BFD [I-D.ali-spring-bfd-sr-policy] mechanisms designed for SR over
   MPLS network.

3.2.  Influence on Voice and Data Service

   In the mobile backhaul network, take VoLTE as an example, voice
   service is extremely sensitive to signal degradation.  The bit error
   on the packets can bring noise, carton, voice call delay, drop line
   or even the base station disconnection.

   Moreover, the download speed of data service is also dramatically
   decreased when the packet loss rate is increasing, although the
   packet loss rate stays in a very low level in all cases.  The
   detailed network statistics is shown in Table 1.

             +------------------+---------------------------+
             | Packet Loss Rate | Decrease of Download Rate |
             +------------------+---------------------------+
             | 0                | No affect                 |
             | <0.01%           | No affect                 |
             | 0.05%            | 23%                       |
             | 0.2%             | 58%                       |
             | 1%               | 75%                       |
             +------------------+---------------------------+

    Table 1 Relation between Packet Loss Rate and Decrease of Download
                                   Rate



Yang, et al.           Expires September 10, 2020               [Page 4]


Internet-Draft        draft-yang-mpls-ps-sdi-sr-00            March 2020


   Signal degradation won't cause the entire service interruption,
   however it impairs the services and dissatisfies the Service Level
   Agreements (SLAs) significantly.

3.3.  Engineering Considerations

3.3.1.  Signal Degrade in Diversity of PHYs

   From the perspective of engineering, there are a variety of PHYs
   defined in IEEE 802.3.  The PHYs without Forward Error Correction
   (FEC) generates the defects/alarms, PHYs with the FEC correct the bit
   errors.  There is no uniform mechanism to guarantee the control of
   the bit errors.

3.3.2.  Performance Management Detection

   The approaches of OAM performance management can be used as the tools
   to detect the signal degrade.  On one hand, active performance
   management cannot fulfill the Signal Degrade detection all the time.
   On the other hand, passive performance management consumes too much
   resource of the equipment so that operators can hardly use it in the
   networks.  The current performance management mechanism is not
   feasible to detect signal degrade conveniently and efficiently.

3.3.3.  BFD Detection

   For the worst case, when signal degrade happens on LSRs, the current
   best practice is to make use of the result of BFD protocol on LERs to
   trigger the protection mechanism.  The detection time is at least
   3.3ms*3 later than the time when the signal degrade happens.  If the
   LSRs can trigger the protection protocol in a more direct and
   efficient way, the network service interruption time can be reduced.

3.4.  LER and LSR Consideration

   There are local and remote request logics about the signal degrade
   defined in [RFC6378].  Meanwhile, the Protection State Coordination
   (PSC) process and the messages are utilized to advertise and exchange
   the signal degrade state between LERs.  In the network of MPLS-TP,
   the LSRs stay dumb in the transmission of OAM messages.

   In the SR over MPLS networks, only the headend LER knows all the
   segments in the label stack, the other LSRs and LER2 does not know
   the entire label stack.  As for the signal degradation happens on
   either headend LER or other LSRs and LER, the mechanism of the signal
   degrade indication would be differently designed.





Yang, et al.           Expires September 10, 2020               [Page 5]


Internet-Draft        draft-yang-mpls-ps-sdi-sr-00            March 2020


3.5.  Signal Degrade Approach

   In Section 4.1 of [RFC6372], approaches of detection or recognition
   of network defect such as signal degrade are specified.  The signal
   degrade indication can be detected from a network defect, or
   advertised by an in-band data-plane-based OAM mechanism, or by in-
   band or out-of-band control-plane signaling, or triggered from the
   centralized Network Management System (NMS) or a SDN controller.  The
   appropriate approaches should be wisely selected.

3.6.  Isolation of Signal Degrade Detection and Protection

   The signal degrade detection is monitored based on the physical link,
   however the signal degrade can be processed and notified at the
   transport path level (e.g.  LSP level).  As a result, the protection
   can be triggered based on the granularity like LSPs.

3.7.  Parameter Threshold

   Parameters like BER or PLR are the different quantitative measurement
   methods.  It is flexible for the service providers to set different
   values of threshold based on the geographical site investigations.
   For an even more complicated scenario, the threshold may be defined
   differently in terms of services, for example to differentiate the
   requirements of the eMBB or URLLC applications in 5G era.

4.  IANA Considerations

   This document makes no request of IANA.

   Note to RFC Editor: this section may be removed on publication as an
   RFC.

5.  Security Considerations

   TBD

6.  Acknowledgements

   TBD

7.  References

7.1.  Normative References







Yang, et al.           Expires September 10, 2020               [Page 6]


Internet-Draft        draft-yang-mpls-ps-sdi-sr-00            March 2020


   [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>.

7.2.  Informative References

   [I-D.ali-spring-bfd-sr-policy]
              Ali, Z., Talaulikar, K., Filsfils, C., Kumar, N., and C.
              Pignataro, "Bidirectional Forwarding Detection (BFD) for
              Segment Routing Policies for Traffic Engineering", draft-
              ali-spring-bfd-sr-policy-04 (work in progress), October
              2019.

   [I-D.ietf-spring-sr-oam-requirement]
              Kumar, N., Pignataro, C., Akiya, N., Geib, R., Mirsky, G.,
              and S. Litkowski, "OAM Requirements for Segment Routing
              Network", draft-ietf-spring-sr-oam-requirement-03 (work in
              progress), January 2017.

   [I-D.rkhd-mpls-tp-sd]
              Ram, R., Cohn, D., Daikoku, M., Yuxia, M., Jian, Y., and
              A. D'Alessandro, "SD detection and protection triggering
              in MPLS-TP", draft-rkhd-mpls-tp-sd-03 (work in progress),
              May 2011.

   [I-D.zhl-mpls-tp-sd]
              Haiyan, Z., Jia, H., and H. Li, "SD-Triggered Protection
              Switching in MPLS-TP", draft-zhl-mpls-tp-sd-03 (work in
              progress), October 2010.

   [RFC6372]  Sprecher, N., Ed. and A. Farrel, Ed., "MPLS Transport
              Profile (MPLS-TP) Survivability Framework", RFC 6372,
              DOI 10.17487/RFC6372, September 2011,
              <https://www.rfc-editor.org/info/rfc6372>.

   [RFC6378]  Weingarten, Y., Ed., Bryant, S., Osborne, E., Sprecher,
              N., and A. Fulignoli, Ed., "MPLS Transport Profile (MPLS-
              TP) Linear Protection", RFC 6378, DOI 10.17487/RFC6378,
              October 2011, <https://www.rfc-editor.org/info/rfc6378>.

   [RFC7271]  Ryoo, J., Ed., Gray, E., Ed., van Helvoort, H.,
              D'Alessandro, A., Cheung, T., and E. Osborne, "MPLS
              Transport Profile (MPLS-TP) Linear Protection to Match the
              Operational Expectations of Synchronous Digital Hierarchy,
              Optical Transport Network, and Ethernet Transport Network
              Operators", RFC 7271, DOI 10.17487/RFC7271, June 2014,
              <https://www.rfc-editor.org/info/rfc7271>.



Yang, et al.           Expires September 10, 2020               [Page 7]


Internet-Draft        draft-yang-mpls-ps-sdi-sr-00            March 2020


   [RFC8402]  Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
              Decraene, B., Litkowski, S., and R. Shakir, "Segment
              Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
              July 2018, <https://www.rfc-editor.org/info/rfc8402>.

Authors' Addresses

   Fan Yang
   Huawei

   Email: shirley.yangfan@huawei.com


   Liuyan Han
   China Mobile

   Email: hanliuyan@chinamobile.com


   Junfeng Zhao
   CAICT

   Email: zhaojunfeng@caict.ac.cn




























Yang, et al.           Expires September 10, 2020               [Page 8]