idnits 2.17.1 draft-li-pce-tunnel-segment-02.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.li-spring-tunnel-segment]), 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 date (March 12, 2017) is 2595 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) == Missing Reference: 'I-D.draft-dhodylee-pce-pcep-ls' is mentioned on line 256, but not defined == Outdated reference: A later version (-04) exists of draft-chen-pce-pce-initiated-ip-tunnel-00 == Outdated reference: A later version (-27) exists of draft-dhodylee-pce-pcep-ls-07 ** Downref: Normative reference to an Experimental draft: draft-dhodylee-pce-pcep-ls (ref. 'I-D.dhodylee-pce-pcep-ls') == Outdated reference: A later version (-02) exists of draft-li-spring-tunnel-segment-01 == Outdated reference: A later version (-08) exists of draft-zhao-pce-pcep-extension-for-pce-controller-04 ** Obsolete normative reference: RFC 5512 (Obsoleted by RFC 9012) == Outdated reference: A later version (-11) exists of draft-ietf-pce-pce-initiated-lsp-09 == Outdated reference: A later version (-07) exists of draft-sivabalan-pce-binding-label-sid-02 Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 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 X. Chen 4 Intended status: Standards Track Huawei Technologies 5 Expires: September 13, 2017 March 12, 2017 7 PCEP Extensions for Tunnel Segment 8 draft-li-pce-tunnel-segment-02 10 Abstract 12 [I-D.li-spring-tunnel-segment] introduces a new type of segment, 13 Tunnel Segment, for the segment routing. Tunnel segment can be used 14 to reduce SID stack depth of SR path, span the non-SR domain or 15 provide differentiated services. A binding label can be assigned to 16 tunnel segment. An upstream node can use such a binding label for 17 steering traffic into the appropriate tunnel. This document 18 specifies a set of extensions to PCEP to support that PCC reports 19 binding label of tunnel to PCE and that PCE allocates label for 20 tunnel and updates label binding of tunnel to PCC. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 26 document are to be interpreted as described in [RFC2119]. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on September 13, 2017. 45 Copyright Notice 47 Copyright (c) 2017 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3.1. Procedure for PCC Reporting Label Binding . . . . . . . . 3 66 3.2. Procedure for PCE Downloading Label Binding . . . . . . . 5 67 4. Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 4.1. LS object . . . . . . . . . . . . . . . . . . . . . . . . 6 69 5. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 5.1. Tunnel Label Binding TLV . . . . . . . . . . . . . . . . 6 71 5.2. PATH-SETUP-TYPE TLV . . . . . . . . . . . . . . . . . . . 7 72 5.3. Tunnel Related TLV . . . . . . . . . . . . . . . . . . . 7 73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 74 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 76 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 77 8.2. Informative References . . . . . . . . . . . . . . . . . 8 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 80 1. Introduction 82 [I-D.li-spring-tunnel-segment] introduces a new type of segment, 83 Tunnel Segment, for the segment routing. Tunnel segment can be used 84 to reduce SID stack depth of SR path, span the non-SR domain or 85 provide differentiated services. A binding label can be assigned to 86 tunnel segment. An upstream node can use such a binding label for 87 steering traffic into the appropriate tunnel. The tunnel segment can 88 be allocated for RSVP-TE tunnel, SR-TE tunnel or IP tunnel. 90 [I-D.li-spring-tunnel-segment] defines the requirement of control 91 plane to support use cases of tunnel segment. The PCE related 92 requirements are as follows: 94 -- PCEP extensions SHOULD be introduced to advertise the binding 95 relationship between a SID/label and the corresponding tunnel from a 96 PCC to a PCE. Attributes of the tunnel MAY be carried optionally. 98 -- PCE SHOULD support to allocate SID/label for the corresponding 99 tunnel dynamically. 101 -- PCEP extensions SHOULD be introduced to distribute the binding 102 relationship between a SID/label and the corresponding tunnel from a 103 PCE to a PCC. Attributes of the tunnel MAY be carried optionally. 105 This document specifies the protocol extensions to PCEP to support 106 these requirements defined in [I-D.li-spring-tunnel-segment]. 108 2. Terminology 110 SR: Segment Routing 112 SR-TE: Segment Routing Traffic Engineering 114 SR-TE Tunnel: Segment Routing Traffic Engineering Tunnel 116 This document uses the terms defined in [RFC5440]: PCC, PCE, PCEP 117 Peer. 119 The following terms are defined in [I-D.ietf-pce-pce-initiated-lsp]: 121 PCE-initiated LSP: LSP that is instantiated as a result of a request 122 from the PCE. 124 The following terms are defined in 125 [I-D.chen-pce-pce-initiated-ip-tunnel]: 127 IP Tunnel: Tunnel that uses IP encapsulation. 129 PCE-initiated IP Tunnel: IP Tunnel that is instantiated as a result 130 of a request from the PCE. 132 3. Procedures 134 3.1. Procedure for PCC Reporting Label Binding 136 In the procedure for PCC reporting the label binding PCC allocates 137 the label and reports the label binding for the tunnel according to 138 the local policy PCC. For report the label binding information, 139 there are following options: 141 Option 1: [I-D.zhao-pce-pcep-extension-for-pce-controller] specifies 142 the procedures and PCEP protocol extensions for using the PCE as the 143 central controller where LSPs are calculated/setup/initiated and 144 label forwarding entries are downloaded to PCC. It introduces the 145 LABEL object to specify the label binding information in PCLabelUpd 146 message. The label carried in LABEL object is mapped to specific LSP 147 carried in LSP object or FEC carried in FEC object. The LABEL object 148 defined in the document is to allocate label from the PCE to PCC and 149 is not appropriate to represent the label binding for the tunnel 150 which can be carried in other PCE objects. 152 Option 2: [I-D.sivabalan-pce-binding-label-sid] proposes an approach 153 for reporting binding label/SID to Path Computation Element (PCE) for 154 supporting PCE-based Traffic Engineering policies. It introduces the 155 optional TLV called "TE-PATH-BINDING TLV" to carry binding label or 156 SID for a TE path. This TLV is limited to traffic engineering and 157 not appropriate for tunnel segment. 159 Option 3: PCEP-LS [I-D.dhodylee-pce-pcep-ls] extends the Path 160 Computation Element Communication Protocol (PCEP) with TED population 161 capability. A PCEP LS Report message (also referred to as LSRpt 162 message) is sent by a PCC to a PCE to report the TED state. The LS 163 object is a mandatory object which carries TE information of a TE 164 node or a TE link. [I-D.wu-pce-pcep-ls-sr-extension] introduces new 165 extensions of PCEP-LS to export path segment information for Segment 166 Routing. 168 This document adopts Option 3 and introduces a new type of TLV, 169 TUNNEL-LABEL-BINDING TLV, which is a new optional TLV defined to 170 report the label mapping for the tunnel in the case of Segement 171 Routing. The tunnel can be PCE-initiated tunnel or created by PCC. 172 [I-D.chen-pce-pce-initiated-ip-tunnel] defines the PCE-initiated IP 173 tunnel and Tunnel object. Tunnel related TLVs defined in [I-D.chen- 174 pce-pce-initiated-ip-tunnel] will be used when report label binding 175 for the tunnel. In order to support Tunnel Segment for MPLS TE 176 tunnel and SR-TE tunnel, this document introduces two new tunnel 177 types for tunnel related TLVs: RSVP-TE tunnel and SR-TE tunnel. 179 In this document LS object will be extended to carry the label 180 mapping information for the tunnel. A new Object-Type value is 181 defined for the LS object to indicate Tunnel Segment. The LS object 182 in LSRpt message MUST carry both TUNNEL-LABEL-BINDING TLV and Tunnel 183 Identifier TLV with the new Object-Type value. If a PCC wants to 184 modify a previously reported label, it MUST send a LSRpt message with 185 the TUNNEL-LABEL-BINDING TLV containing the new label binding value. 186 If the Tunnel Identifier TLV is missing, the PCE will generate an 187 error with error-type 6 (mandatory object missing) and error-value 188 which means Tunnel Identifier TLV missing and close the session. If 189 the TUNNEL-LABEL-BINDING TLV is missing, the PCE will generate an 190 error with error-type 6 (mandatory object missing) and error-value 191 which means TUNNEL-LABEL-BINDING TLV missing and close the session. 193 If a PCE does not recognize the TUNNEL-LABEL-BINDING TLV, it MUST 194 ignore the TLV in accordance with [RFC5440]. If a PCE recognizes the 195 TLV but does not support the TLV, it MUST send PCErr with Error-Type 196 = 2 (Capability not supported). If there are more than one TUNNEL- 197 LABEL-BINDING TLVs, only the first TLV MUST be processed and the rest 198 MUST be silently ignored. 200 If a PCE does not recognize the Tunnel Identifier TLV, it MUST ignore 201 the TLV in accordance with [RFC5440]. If a PCE recognizes the TLV 202 but does not support the TLV, it MUST send PCErr with Error-Type = 2 203 (Capability not supported). If there are more than one Tunnel 204 Identifier TLVs, only the first TLV MUST be processed and the rest 205 MUST be silently ignored. 207 3.2. Procedure for PCE Downloading Label Binding 209 [I-D.zhao-pce-pcep-extension-for-pce-controller] has defined the 210 Label Update Message (also referred to as PCLabelUpd) that is a PCEP 211 message sent by a PCE to a PCC to download label or update the label 212 mapping. The same message is also used to cleanup the label mapping. 213 In the procedure for PCE downloading the label binding for Tunnel 214 Segment PCE is responsible for allocating the label for PCE-initiated 215 tunnel or the tunnel initiated by PCC and reported to PCE. 217 [I-D.chen-pce-pce-initiated-ip-tunnel] defines the PCE-initiated IP 218 tunnel and the TUNNEL object. PCE uses the Label Update Message to 219 download the label mapping for the tunnel in the case of Segment 220 Routing. The PCLabelUpd Message is defined in 221 [I-D.zhao-pce-pcep-extension-for-pce-controller] and the extension of 222 the PCLabelUpd message for tunnel segment is defined as follows: 224 ::= (| 225 |) 226 Where: 227 ::= 228