Network Working Group W. Cheng Internet-Draft L. Wang Intended status: Standards Track H. Li Expires: January 3, 2019 China Mobile M. Chen Huawei R. Zigler Broadcom S. Zhan ZTE R. Gandhi Cisco Systems, Inc. July 02, 2018 Path Segment in MPLS Based Segment Routing Network draft-cheng-spring-mpls-path-segment-02 Abstract An SR path is identified by an SR segment list, one or partial segments of the list cannot uniquely identify the SR path. Path identification is the precondition of performance measurement (PM) of an SR path. This document introduces the concept of Path Segment that is used to identify an SR path. When used, it is inserted at the ingress node of the SR path and immediately follows the last segment of the SR path. The Path Segment will not be popped off until it reaches the egress of the SR path. Path segment can be used by the egress node to implement path identification hence to support SR path PM, end-2-end SR path protection and bidirectional SR paths correlation. 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 Cheng, et al. Expires January 3, 2019 [Page 1] Internet-Draft Path Segment in SR-MPLS July 2018 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 January 3, 2019. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Path Segment . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. One Label Solution . . . . . . . . . . . . . . . . . . . 3 2.2. Two Labels Solution . . . . . . . . . . . . . . . . . . . 5 3. Path Segment Allocation . . . . . . . . . . . . . . . . . . . 6 4. Path Segment based PM . . . . . . . . . . . . . . . . . . . . 6 4.1. Direct Packet Loss Measurement . . . . . . . . . . . . . 7 4.2. Indirect Packet Loss Measurement . . . . . . . . . . . . 7 4.3. Packet Delay Measurement . . . . . . . . . . . . . . . . 8 5. Path Segment for Bi-directional SR Path . . . . . . . . . . . 8 6. Path Segment based End-2-end Path Protection . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 11.1. Normative References . . . . . . . . . . . . . . . . . . 9 11.2. Informative References . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Cheng, et al. Expires January 3, 2019 [Page 2] Internet-Draft Path Segment in SR-MPLS July 2018 1. Introduction Segment Routing (SR) [I-D.ietf-spring-segment-routing] is a source routed forwarding method that allows to directly encode forwarding instructions (called segments) in each packet, hence it enables to steer traffic through a network without the per-flow states maintained in the transit nodes. Segment Routing can be instantiated on MPLS data plane or IPv6 data plane. The former is called SR-MPLS [I-D.ietf-spring-segment-routing-mpls], the latter is called SRv6 [I-D.ietf-6man-segment-routing-header]. SR-MPLS leverages the MPLS label stack to construct SR path, and SRv6 uses the Segment Routing Header to construct SR path. In an SR-MPLS network, when a packet is transmitted along an SR path, the labels in the MPLS label stack will be swapped or popped. So that no label or only the last label may be left in the MPLS label stack when the packet reaches the egress node. Thus, the egress node cannot determine from which SR path the packet comes. However, to support use cases like end-2-end 1+1 path protection, bidirectional path correlation or performance measurement(PM), the ability to implement path identification is the pre-condition. Therefore, this document introduces a new segment that is referred to as Path Segment. A Path Segment is defined to unique identify an SR path in a specific context. (e.g., in the context of the egress node or ingress node of an SR path, or within an SR domain). It is normally used by egress nodes for path identification or correlation. 2. Path Segment This document introduces two options for SR path identification: one label solution and two labels solution. [Editor notes: it is supposed that the WG will discuss and decide which one is preferred. There some discussions on the mailing list show that the one label solution is preferred.] 2.1. One Label Solution The Path Segment is a single label that is assigned from the Segment Routing Local Block (SRLB) or Segment Routing Global Block (SRGB) of the egress node of an SR path. It means that the Path Segment is unique in the context of the egress node of SR paths. When Path Segment is used, a Path label MUST be inserted at the ingress node and MUST immediately follow the last label of the SR path. Cheng, et al. Expires January 3, 2019 [Page 3] Internet-Draft Path Segment in SR-MPLS July 2018 The value of the TTL field of the Path label MUST be set to the same value of the last segment label of the SR path. If the Path label is the bottom label, the S bit MUST be set. How to set to the TC field is up to the specific use case of Path segment. Normally, the intermediates node will not see the Path Segment label and do not know how to process it even if they see it. A Path Segment label presenting to an intermediate node is an error situation. The egress node MUST pop the Path label and deliver it to relevant components for further processing. For example, when performance measurement is enabled on the SR path, it will trigger packet counting or timestamping. The label stack with Path Segment is as below (Figure1): +--------------------+ | ... | +--------------------+ | Label 1 | +--------------------+ | Label 2 | +--------------------+ | ... | +--------------------+ | Label n | +--------------------+ | Path Label | +--------------------+ | ... | +--------------------+ Figure 1: Label Stack with Path Segment Where: o The Label 1-n are the segment labels that are used to direct how to steer the packets along the SR path. o The Path Label identifies the SR path in the context of the egress node of the SR path. Cheng, et al. Expires January 3, 2019 [Page 4] Internet-Draft Path Segment in SR-MPLS July 2018 2.2. Two Labels Solution Two segments (Source segment and Path segment) are used to identify an SR path. The Source segment is a global node segment, it can uniquely identify a node within an SR domain. It MUST NOT be used for forwarding and indicates that a Path segment immediately follows. The Path segment is a local segment generated at the ingress node to identify an SR path. The combination of Source segment and Path segment can uniquely identify an SR Path with an SR domain. A node that enables Path segment function will be assigned two node segments. One is for forwarding just as defined in [I-D.ietf-spring-segment-routing], the other is for source identification. The corresponding label of the Source Segment is indexed in the SRGB of the node to which the Source Segment will be presented. The Path segment label is a local label that is assigned to an SR path at the ingress node. The label stack with Source and Path segments is as below (Figure 2): +--------------------+ | ... | +--------------------+ | Label 1 | +--------------------+ | Label 2 | +--------------------+ | ... | +--------------------+ | Label n | +--------------------+ | Source Label | +--------------------+ | Path Label | +--------------------+ | ... | +--------------------+ Figure 2: Label Stack with Source and Path Segments Where: o The Label 1-n are the segment labels that are used to direct how to steer the packets along an SR path, and the "label n" is the Cheng, et al. Expires January 3, 2019 [Page 5] Internet-Draft Path Segment in SR-MPLS July 2018 last label of the SR path or the label that directs forwarding packets to the node to which the Source Segment will be presented. o The Source Label identifies the source of the SR path. The value of the TTL field of the Source Label MUST be set to the same values as the label (e.g., the Label n) it follows. How to set to TC field is up to the specific use case of Path segment. o The Path Label identifies the SR path in the context of source node. If the Path label is the bottom label, the S bit MUST be set. The value of the TC and TTL fields SHOULD be set to the same values as the Source label. The Source and Path label MUST be inserted at the ingress node of an SR path. And they MUST immediately follow the label that directs forwarding packets to the node (e.g., the egress or an intermediate node) to which the Source Segment (as the stack top label) and Path Segment are presented. If a node receives a packet with an unknown Source Label, the packet MUST be discarded and an error SHOULD be reported. The Source label and Path label MUST be popped at the node who receives a packet with the Source label as the stack top label. 3. Path Segment Allocation Several ways can be used to assign the Path Segment. One way is that to set up a communication channel (e.g., MPLS Generic Associated Channel (G-ACh)) between the ingress node and the egress node and the ingress node of the SR path can directly send a request to the egress node to ask for a Path label. Another candidate way is to leverage a centralized controller (e.g., PCE, SDN controller) to assign the Path label. PCEP based Path Segment allocation is defined in [I-D.li-pce-sr-path-segment], and SR-policy based path segment allocation is defined in [I-D.li-idr-sr-policy-path-segment-distribution]. 4. Path Segment based PM Path segment is mainly for packet loss measurement, but it can also apply to packet delay measurement. Cheng, et al. Expires January 3, 2019 [Page 6] Internet-Draft Path Segment in SR-MPLS July 2018 4.1. Direct Packet Loss Measurement Measuring packet loss of real traffic is called "direct mode" packet loss measurement in [RFC6374]. To measure the packet loss of the real traffic of an SR path, one fundamental condition is path identification at the measuring points. For an SR path, the ingress node have the complete information of the path, it can use those information for packet counting. At the egress node, since the path label (or combination with Source label) can be used to identify the path, path based packet counting can be implemented as well. Once get the counts on ingress and egress node, packet loss can be calculated. [RFC6374] defines Loss Measurement Message to comunicate the counts between ingress and egress nodes. [I-D.gandhi-spring-sr-mpls-pm] reviews how mechanisms defined in [RFC6374] can be used for packet Delay Measurement (DM) and Loss Measurements (LM) in SR networks with MPLS data plane. [I-D.gandhi-spring-udp-pm] specifies a procedure for using UDP path for sending and processing in-band probe query and response messages for packet loss and delay measurement. The "direct mode" for loss measurement defined in [RFC6374] assumes that there is no packet misordering, otherwise it will degrade the accuracy of the packet loss measurement. So, for the case where this is no packet misordering, the direct packet losss measurment defined in [RFC6374] can be used. [RFC8321] introduces an Alternate-Marking (coloring) based mechanism to perform packet loss, delay, and jitter measurements on real traffic. For packet loss measurement, since it only depends on the marker (color) on each packet to differentiate to which block/batch the packet belong, packet misordering will not affect the accuracy of the packet loss measurement. How to apply Alternate-Marking based mechanism [RFC8321] to measure performance of an SR path will added in next revision. 4.2. Indirect Packet Loss Measurement As defined in [RFC6374], indirect packet loss measurement is to measure the packet loss of the injected OAM probing packets, hence to mimc the performance of a path. For indirect packet loss measurement, path identification is also needed. But compare to the direct packet loss measurement, the path segment can be carried in the SR label stack (just as described in Section 2 of this document), or be directly carried in the Loss Measurement Message (e.g., a new TLV). The detail of how path segment is carried in the Loss Measurement Message will be defined in future version. Cheng, et al. Expires January 3, 2019 [Page 7] Internet-Draft Path Segment in SR-MPLS July 2018 4.3. Packet Delay Measurement More detail will be added in next revision. 5. Path Segment for Bi-directional SR Path With the current SR architecture, an SR path is an unidirectional path. In some scenarios, for example, mobile backhaul transport network, there are requirements to support bi-directional path, and the path is normally treated as a single entity and both directions of the path have the same fate, for example, failure in one direction will result in switching at both directions. MPLS supports this by introducing the concepts of co-routed bidirectional LSP and associated bi-directional LSP. With SR, to support bidirectional path, a straightforward way is to bind two unidirectional SR paths to a single bi-directional path. Path segments can be used to correlate the two unidirectional SR paths at both ends of the paths. [I-D.li-pce-sr-path-segment] defines how to use PCEP to initiate a bidirectional SR path, and [I-D.li-idr-sr-policy-path-segment-distribution] defines how to use SR policy to initiate a bidirectional SR path. 6. Path Segment based End-2-end Path Protection For end-2-end 1+1 path protection, the egress node of an path needs to know the set of paths that constitute the primary and the backup(s), in order to select the primary packet for onward transmission, and to discard the packets from the backups. To do this each path needs a path identifier that is unique at the egress node. Depending on the design, this single unique label chosen by the egress PE or the combination of the source node identifier and a unique path identifier chosen by the source. There then needs to be a method of binding this path identifiers into equivalence groups such that the egress PE can determine the set of packets that represent a single path and its backup. It is obvious that this group can be instantiated in the network by an SDN controller. In a network that is using a distributed control plane the approach will depend on the control protocol used, but the essence of the solution is that which ever PE is responsible for creating the group advertises then as a group of equivalent paths. Whether one of these Cheng, et al. Expires January 3, 2019 [Page 8] Internet-Draft Path Segment in SR-MPLS July 2018 is advertised as primary and the others as secondary will or all are advertised as of equal status will depend on the details of the underlying protection mechanism. 7. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 8. Security Considerations 9. Contributors The following individuals also contribute to this document. o Shuangping Zhan, ZTE o Cheng Li, Huawei 10. Acknowledgements The authors would like to thank Stewart Bryant for his review, suggestion and comments to this document. 11. References 11.1. Normative References [I-D.ietf-6man-segment-routing-header] Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header (SRH)", draft-ietf-6man-segment-routing-header-14 (work in progress), June 2018. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . 11.2. Informative References [I-D.gandhi-spring-sr-mpls-pm] Gandhi, R., Filsfils, C., Soni, S., daniel.voyer@bell.ca, d., Salsano, S., and P. Ventre, "Performance Measurement in Segment Routing Networks with MPLS Data Plane", draft- gandhi-spring-sr-mpls-pm-01 (work in progress), June 2018. Cheng, et al. Expires January 3, 2019 [Page 9] Internet-Draft Path Segment in SR-MPLS July 2018 [I-D.gandhi-spring-udp-pm] Gandhi, R., Filsfils, C., Soni, S., daniel.voyer@bell.ca, d., Salsano, S., and P. Ventre, "UDP Path for In-band Performance Measurement for Segment Routing Networks", draft-gandhi-spring-udp-pm-01 (work in progress), June 2018. [I-D.ietf-spring-segment-routing] Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", draft-ietf-spring-segment-routing-15 (work in progress), January 2018. [I-D.ietf-spring-segment-routing-mpls] Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing with MPLS data plane", draft-ietf-spring-segment-routing-mpls-14 (work in progress), June 2018. [I-D.li-idr-sr-policy-path-segment-distribution] Li, C., Chen, M., Dong, J., and Z. Li, "Segment Routing Policies for Path Segment and Bi-directional Path", draft- li-idr-sr-policy-path-segment-distribution-00 (work in progress), April 2018. [I-D.li-pce-sr-path-segment] Li, C., Chen, M., Dong, J., Li, Z., and D. Dhody, "Path Computation Element Communication Protocol (PCEP) Extension for Path Identification in Segment Routing (SR)", draft-li-pce-sr-path-segment-00 (work in progress), June 2018. [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay Measurement for MPLS Networks", RFC 6374, DOI 10.17487/RFC6374, September 2011, . [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, "Alternate-Marking Method for Passive and Hybrid Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, January 2018, . Authors' Addresses Cheng, et al. Expires January 3, 2019 [Page 10] Internet-Draft Path Segment in SR-MPLS July 2018 Weiqiang Cheng China Mobile Email: chengweiqiang@chinamobile.com Lei Wang China Mobile Email: wangleiyj@chinamobile.com Han Li China Mobile Email: lihan@chinamobile.com Mach(Guoyi) Chen Huawei Email: mach.chen@huawei.com Royi Zigler Broadcom Email: royi.zigler@broadcom.com Shuangping Zhan ZTE Email: zhan.shuangping@zte.com.cn Rakesh Gandhi Cisco Systems, Inc. Canada Email: rgandhi@cisco.com Cheng, et al. Expires January 3, 2019 [Page 11]