idnits 2.17.1 draft-paul-pce-dynamic-tunnel-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: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 7 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 33 instances of too long lines in the document, the longest one being 14 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 20, 2018) is 1984 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: 'RFC8231' is mentioned on line 92, but not defined == Unused Reference: 'RFC4657' is defined on line 279, 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. -------------------------------------------------------------------------------- 1 PCE Arijit Paul 2 Internet-Draft Juniper Networks 3 Intended status: Standards Track November 20, 2018 4 Expires: May 20, 2019 6 PCEP extension to support reporting of dynamic tunnels 7 draft-paul-pce-dynamic-tunnel-00 9 Abstract 11 In a SDN environment, path computation element protocol(PCEP) 12 (RFC 5440) is used between a controller and the network devices, 13 using which controller can setup and tear down Resource ReserVation 14 Protocol (RSVP) based label switched paths(LSPs) in the network 15 having Path Computation Client (PCC) as Label Switched Router (LSR). 16 In an environment where dynamic tunnels are used to provide MPLS based 17 customer services instead of a Label Switched Path, the specifications 18 lacks a method to report the Dynamic tunnels over PCEP session to PCE. 19 This draft defines a method to advertise the dynamic tunnels via PCEP 20 session to PCE. 22 This document proposes new object TLV that can be used to report 23 dynamic tunnels to the PCE. 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 http://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 March 8, 2018 42 Copyright Notice 44 Copyright (c) 2016 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 (http://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 . . . . . . . . . . . . . . . . . . . . . . . . 1 60 2. Conventions used in this document . . . . . . . . . . . . . . 2 61 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 2 62 4. Overview of Protocol Extensions . . . . . . . . . . . . . . . 2 63 4.1. Capability Advertisement . . . . . . . . . . . . . . . . 2 64 4.2. Dynamic-Tunnel Object . . . . . . . . . . . . . . . . . 3 65 4.2.1 IPV4-TUNNEL-IDENTIFIERS TLV . . . . . . . . . . . . . 5 66 4.3. Metric Object . . . . . . . . . . . . . . . . . . . . . 6 67 5. Backward Compatibility Consideration . . . . . . . . . . . . 6 68 6. Management Considerations . . . . . . . . . . . . . . . . . . 6 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 70 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 71 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 73 9.2. Informative References . . . . . . . . . . . . . . . . . 7 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 76 1. Introduction 78 As described in [RFC5440], PCEP can be used to create, modify or 79 delete LSPs between PCCs. PCEP can be used to create, modify and 80 delete RSVP and segment routing LSPs between PCCs. This document 81 specifies the way to report the dynamic nexthop based tunnels from PCC 82 to PCE server. This is helpful for PCE to have complete visibility 83 of the network and help take intelligent decisions based on the 84 information available to it. 86 In this draft a method to report dynamic tunnels from PCC via PCEP is 87 outlined. 89 This document proposes one new pcep objects to carry the tunnels attributes 90 for individual dynamic tunnels. Since only reporting of dynamic tunnels 91 is outlined here, only dynamic tunnel object and well-known metric objects 92 are being carried in PCRpt [RFC8231] of PCEP message in order to report 93 the dynamic tunnel to PCE. 95 2. Conventions used in this document 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in RFC2119 [RFC2119]. 101 3. Motivation 103 PCEP protocol lacks the capability to report dynamic-tunnels e,g, 104 MPLS over UDP and MPLS over GRE to the PCE. In the SDN scenario 105 where a controller uses the information provided by PCEP to gain 106 network visibility, adding the report capability of dynamic-tunnel 107 via PCEP helps controller gain additional insights about network 108 tunnels. 110 4. Overview of Protocol Extensions 112 4.1. Capability Advertisement 114 During the PCEP session initialization phase, PCEP speakers (PCE or PCC) 115 advertise their support of dynamic tunnel report capability. A PCEP 116 speaker includes the "STATEFUL-PCE-CAPABILITY TLV", described in 117 Section 7.1.1, in the OPEN object to advertise its support for PCEP 118 Stateful PCE extensions. The STATEFUL-PCE-CAPABILITY TLV includes 119 the 'Dynamic Tunnel Report' flag that indicates whether the PCEP speaker 120 supports Dynamic Tunnel report capability. 122 One new flag is added in this document: 124 D (DYNAMIC-TUNNEL-REPORT bit - TBD): if set to 1 by a PCC, the D Flag 125 indicates that the PCC is willing to send Dynamic Tunnel State Reports 126 whenever dynamic tunnel state changes.; if 127 set to 1 by a PCE, the D Flag indicates that the PCE is interested 128 in receiving Dynamic Tunnel State Reports whenever dynamic tunnel state changes. 129 The DYNAMIC-TUNNEL-REPORT Flag must be 130 advertised by both a PCC and a PCE for PCRpt messages DYNAMIC-TUNNEL-REPORT 131 extension to be allowed on a PCEP session. 133 4.2 Dynamic-Tunnel Object 135 Path Computation State Report (PCRpt): a PCEP message sent by a PCC 136 to a PCE to report the status of one or more LSPs. Each LSP State 137 Report in a PCRpt message MAY contain the actual LSP's path, 138 bandwidth, operational and administrative status, etc. An LSP 139 Status Report carried on a PCRpt message is also used in 140 delegation or revocation of control of an LSP to/from a PCE. The 141 PCRpt message is described in Section 6.1. 143 One new object is defined in order to report dynamic tunnels to PCE. 145 The Dynamic-Tunnel object MUST be present within PCRpt messages while 146 reporting dynamic tunnel. The LSP 147 object contains a set of fields used to specify the target LSP, the 148 operation to be performed on the LSP, and LSP delegation. It also 149 contains a flag indicating to a PCE that the LSP State 150 Synchronization is in progress. This document focuses on MPLS Tunnels that 151 run over UDP or GRE. 153 Dynamic tunnel Object-Class is TBD. 155 Dynamic tunnel Object-Type is TBD. 157 The format of the Dynamic-Tunnel object body is shown in Figure 1: 159 0 1 2 3 160 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 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | Tunnel-ID | Flag | |O|R|S| 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 // TLVs // 165 | | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 Figure 1: The LSP Object format 170 Tunnel-ID (20 bits): A PCEP-specific identifier for the Dynamic Tunnel. A PCC 171 creates a unique Tunnel-ID for each dynamic tunnel that is constant for the 172 lifetime of a PCEP session. The PCC will advertise the same Tunnel-ID 173 on all PCEP sessions it maintains at a given time. There will not be any 174 name associated with dynamic-tunnel, so no mapping between Tunnel-ID and 175 tunnel name is maintained. If needed PCE can maintain mapping of Tunnel-ID 176 with source and destination of dynamic tunnels. 178 All subsequent PCEP messages then address the LSP by the Tunnel-ID. The 179 values of 0 and 0xFFFFF are reserved. Note that the Tunnel-ID is a 180 value that is constant for the lifetime of the PCEP session. 182 Flags (12 bits), starting from the least significant bit: 184 S (SYNC - 1 bit): The S flag MUST be set to 1 on each PCRpt sent 185 from a PCC during State Synchronization. The S flag MUST be set 186 to 0 in other messages sent from the PCC. 188 R (Remove - 1 bit): On PCRpt messages, the R flag indicates that the 189 Dynamic tunnel has been removed from the PCC and the PCE SHOULD remove all 190 state from its database. Upon receiving an Dynamic tunnel State Report with 191 the R flag set to 1 for a Dynamic tunnel, the PCE SHOULD 192 remove all state for the path identified by the IPV4-TUNNEL-IDENTIFIERS 193 TLV from its database. 195 O (Operational - 3 bits): On PCRpt messages, the O field represents 196 the operational status of the LSP. 198 The following values are defined: 200 0 - DOWN: not active. 202 1 - UP: signaled. 204 2 - ACTIVE: up and carrying traffic. 206 3-7 - Reserved: these values are reserved for future use. 208 Unassigned bits are reserved for future uses. They MUST be set to 0 209 on transmission. 211 TLVs that may be included in the Dynamic-Tunnel object are described in the 212 following sections. 214 4.2.1 IPV4-TUNNEL-IDENTIFIERS TLV 216 The format of the IPV4-TUNNEL-IDENTIFIERS TLV is shown in the following 217 figure: 219 0 1 2 3 220 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 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | Type=[TBD] | Length=16 | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | IPv4 Tunnel Source Address | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | IPv4 Tunnel Destination Address | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | Tunnel Type | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 Figure 2: IPV4-TUNNEL-IDENTIFIERS TLV Format 233 The type of the TLV is to be assigned by IANA and it has a fixed 234 length of 2 octets. 236 IPv4 Tunnel Source Address: contains the tunnel's source IPv4 address 238 IPv4 Tunnel Destination Address: contains the tunnel's destination IPv4 239 address 241 Tunnel Type: Defines the tunnel type. This draft assigns MPLSoUDP a 242 numeric value of 1 and MPLSoGRE a numeric value of 2. 244 4.3 Metric Object 246 This object is already defined in [RFC5440]. It can be reused and metric 247 type should be set to value 1 which signifies IGP metric. 249 5. Backward Compatibility Consideration 251 A PCE that does not support the new capability will not bring up the session 252 during initialization phase. 254 6. Management Considerations 256 Not needed. 258 7. Security Considerations 260 This document raises no new security issues. 262 8. IANA Considerations 264 IANA is requested to allocate a Type for this new object to 265 support dynamic tunnel reporting. 267 9. References 269 9.1. Normative References 271 [draft-crabbe-pce-pce-initiated-lsp] E. Crabbe, "PCEP Extensions 272 for PCE-initiated LSP Setup 273 in a Stateful PCE Model" 275 [draft-sivabalan-pce-segment-routing] E. Crabbe, "PCEP Extensions 276 for Stateful PCE" 277 9.2. Informative References 279 [RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE) 280 Communication Protocol Generic Requirements", RFC 4657, 281 September 2006. 283 [RFC5440] Le Roux, JL., "Path Computation Element (PCE) 284 Communication Protocol (PCEP)", RFC 5440, March 2009. 285 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 286 Requirement Levels", RFC 2119, March 1997 288 Author's Addresses 290 Arijit Paul 291 10214 Parkwood Dr. Apt 5 292 Cupertino, CA - 95014 293 USA 295 Email: arijitp@juniper.net