idnits 2.17.1 draft-qc-pce-path-routing-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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC8408, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: If the PCE receives an Open message without a PPR_CAPABILITY sub-TLV from the PCC, then the PCE MUST not send the PCC any request for PPR. -- The document date (July 8, 2019) is 1754 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.ietf-ospf-segment-routing-extensions' is mentioned on line 409, but not defined == Unused Reference: 'I-D.ietf-spring-segment-routing' is defined on line 693, but no explicit reference was found in the text == Unused Reference: 'RFC5120' is defined on line 715, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-chunduri-lsr-isis-preferred-path-routing-03 == Outdated reference: A later version (-04) exists of draft-chunduri-lsr-ospf-preferred-path-routing-03 == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-18 == Outdated reference: A later version (-19) exists of draft-ietf-lsr-isis-srv6-extensions-00 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-18 == Outdated reference: A later version (-02) exists of draft-qct-lsr-ppr-yang-01 Summary: 0 errors (**), 0 flaws (~~), 11 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group Y. Qu 3 Internet-Draft H. Chen 4 Updates: 8408 (if approved) Futurewei 5 Intended status: Standards Track July 8, 2019 6 Expires: January 9, 2020 8 PCEP Extensions for Preferred Path Routing 9 draft-qc-pce-path-routing-00 11 Abstract 13 This document specifies extensions to the Path Computation Element 14 Protocol (PCEP) that allow a stateful PCE to initiate Preferred Path 15 Routing (PPR) paths. It also specifies how PCC should react to the 16 PCEP messages. 18 Requirements Language 20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 21 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 22 "OPTIONAL" in this document are to be interpreted as described in BCP 23 14 [RFC2119][RFC8174] when, and only when, they appear in all 24 capitals, as shown here. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on January 9, 2020. 43 Copyright Notice 45 Copyright (c) 2019 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Overview of PCEP Operation in PPR Networks . . . . . . . . . 4 63 4. Extensions to PCEP . . . . . . . . . . . . . . . . . . . . . 4 64 4.1. Capability for PPR . . . . . . . . . . . . . . . . . . . 4 65 4.2. PPR TLV . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 4.2.1. PPR-Flags . . . . . . . . . . . . . . . . . . . . . . 7 67 4.2.2. PPR-Prefix Sub-TLV . . . . . . . . . . . . . . . . . 7 68 4.2.3. PPR-ID Sub-TLV . . . . . . . . . . . . . . . . . . . 8 69 4.2.4. PPR-PDE Sub-TLV . . . . . . . . . . . . . . . . . . . 9 70 4.2.5. PPR-Attributes Sub-TLV . . . . . . . . . . . . . . . 12 71 5. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 12 72 6. Management Considerations . . . . . . . . . . . . . . . . . . 13 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 74 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 75 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 76 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 77 10.1. Normative References . . . . . . . . . . . . . . . . . . 14 78 10.2. Informative References . . . . . . . . . . . . . . . . . 15 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 81 1. Introduction 83 Segment Routing (SR) [RFC8402] leverages the source routing paradigm. 84 A packet is steered through a network using an ordered list of 85 instructions, called "segments". A segment is often referred to by 86 its Segment Identifier (SID), and can represent any instruction, 87 topological or service based. The SR architecture can be implemented 88 using either MPLS [I-D.ietf-spring-segment-routing-mpls] or IPv6 89 [I-D.ietf-6man-segment-routing-header] forwarding plane. 91 A Preferred Path Routing (PPR) 92 [I-D.chunduri-lsr-isis-preferred-path-routing] 93 [I-D.chunduri-lsr-ospf-preferred-path-routing] path is identified by 94 a PPR ID and described as a list of Path Description Elements (PDEs). 95 A PPR path could be used as a Traffic Engineering (TE) path, or a 96 Service Function Chaining (SFC) [RFC7665] path etc. PPR can help to 97 reduce the data plane overhead and mitigate MTU issues. 99 [RFC5440] describes the Path Computation Element Protocol (PCEP) for 100 communication between a Path Computation Client (PCC) and a Path 101 Computation Element (PCE) or between a pair of PCEs. [RFC8281] 102 specifies a mechanism to dynamically initiate LSPs on a PCC based on 103 the requests from a stateful PCE or a controller using stateful PCE. 104 A stateful PCE can compute one or more SR-TE paths, and initiate a 105 SR-TE path on a PCC using the SR specific PCEP extensions specified 106 in [I-D.ietf-pce-segment-routing]. 108 It is possible to use a stateful PCE for computing PPR paths taking 109 into account various constraints. This document specifies the PCEP 110 extensions that can be used to for the stateful PCE to initiate a PPR 111 path on a PCC. 113 2. Terminology 115 The following terminologies are used in this document: 117 ERO: Explicit Route Object 119 IGP: Interior Gateway Protocol 121 IS-IS: Intermediate System to Intermediate System 123 LSR: Label Switching Router 125 NAI: Node or Adjacency Identifier 127 OSPF: Open Shortest Path First 129 PCC: Path Computation Client 131 PCE: Path Computation Element 133 PCEP: Path Computation Element Communication Protocol 135 RRO: Record Route Object 137 SID: Segment Identifier 139 SR: Segment Routing 141 PPR: Preferred Path Routing 143 PDE: Path Description Element 145 3. Overview of PCEP Operation in PPR Networks 147 In a PPR network, the ingress node of a PPR path prepends a PPR 148 header to all outgoing packets. Depending on the forwarding plane, 149 different formats of header will be chosen. The header contains a 150 PPR ID, in combination with the control plane information about the 151 PPR ID, the packets will be routed through the network. 153 In PCEP messages, PPR path information is carried in the Explicit 154 Route Object (ERO), which consists of a sequence of sub objects. PPR 155 paths computed by a PCE can be represented in an ERO with a PPR ID 156 followed by one of the following list: 158 o An ordered set of IP addresses representing network nodes/links. 160 o An ordered set of SIDs, with or without the corresponding IP 161 addresses. 163 o An ordered set of MPLS labels, with or without corresponding IP 164 address. 166 After a PCC receives the PCEP messages, one of the following two 167 methods can be used to program the control plane: 169 o IGP can be used to populate the PPR path information as described 170 in [I-D.chunduri-lsr-isis-preferred-path-routing] and 171 [I-D.chunduri-lsr-ospf-preferred-path-routing]. 173 o If PCEP is used directly to program a PPR path, and a PCC sees 174 itself is part of a PPR path, it will install the corresponding 175 information, such as PPR ID, next hop into forwarding table. 177 4. Extensions to PCEP 179 4.1. Capability for PPR 181 When a PCEP session is established between a PCE and a PCC, they 182 exchange their capabilities of supporting PPR. 184 A new sub-TLV, which is called PPR_CAPABILITY, is defined. It is 185 included in the PATH_SETUP_TYPE_CAPABILITY TLV with PST = TBD1 186 (suggested value 3 for PPR) in the OPEN object, which is exchanged in 187 Open messages when the PCEP session is established. Its format is 188 illustrated below. 190 0 1 2 3 191 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 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | Type = TBD2 | Length=4 | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | Reserved | Flags |I| 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 Figure 1: PPR_CAPABILITY sub-TLV 200 Type: TBD2 is to be assigned by IANA. 202 Length: 4. 204 Reserved: 2 octets. Must be set to zero in transmission and ignored 205 on reception. 207 Flags: 2 octets. This document defines the following flag bits. 208 The other bits MUST be set to zero by the sender and MUST be 209 ignored by the receiver. 211 * I: A PCC sets this flag bit to 1 to indicate that it is capable 212 of flooding PPR path information in an IGP domain. 214 The PCC, which supports PPR, sends the PCE an Open message containing 215 PPR_CAPABILITY sub-TLV. This sub-TLV indicates that the PCC is 216 capable of supporting PPR. 218 The PCE, which supports PPR, sends the PCC an Open message containing 219 PPR_CAPABILITY sub-TLV. This sub-TLV indicates that the PCE is 220 capable of supporting PPR. 222 When both the PCC and the PCE support PPR_CAPABILITY, each of the 223 Open messages sent by the PCC and PCE contains 224 PATH_SETUP_TYPE_CAPABILITY TLV with a PST list containing PST=TBD1 225 and a PPR_CAPABILITY sub-TLV. 227 If the PCE receives an Open message without a PPR_CAPABILITY sub-TLV 228 from the PCC, then the PCE MUST not send the PCC any request for PPR. 230 If the PCC receives an Open message without a PPR_CAPABILITY sub-TLV 231 from a PCE, then the PCC MUST ignore any request for PPR from the 232 PCE. 234 4.2. PPR TLV 236 A new TLV called PPR TLV is defined. When a PCE sends a PCC a 237 PCInitiate message for initiating PPR path, the message contains this 238 TLV in the LSP object. 240 A PPR TLV may contain the encodings of a Prefix, PPR-ID, and path 241 description with an ordered PDE Sub-TLVs and a set of optional PPR 242 attribute Sub-TLVs, which can be used to describe one or more 243 parameters of the path. The format of the PPR TLV is illustrated 244 below: 246 0 1 2 3 247 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 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | Type = TBD3 | Length | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 |I| PPR-Flags | Reserved | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | PPR-Prefix Sub-TLV (variable size) | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | PPR-ID Sub-TLV (variable size) | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | PPR-PDE Sub-TLVs (variable) | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | PPR-Attribute Sub-TLVs(variable) | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 Figure 2: PPR TLV Format 264 Type: TBD3 is to be assigned by IANA. 266 Length: Total length of the value field in bytes (variable). 268 PPR-Flags: 2 octets. The defined flags are described below. 270 Reserved: 2 octets. Must be set to zero in transmission and ignored 271 on reception. 273 PPR-Prefix Sub-TLV: Variable octets. It represents the prefix for 274 which path description is being attached to, and is defined below. 276 PPR-ID Sub-TLV: Variable octets. It represents the data plane or 277 forwarding identifier of the PPR, and is defined below. 279 PPR-PDE Sub-TLVs: Variable octets. They represent the path in 280 ordered PDE Sub-TLVs, and are defined below. 282 PPR-Attribute Sub-TLVs: Variable octets. They represent the path 283 attributes, and are defined below. 285 4.2.1. PPR-Flags 287 Two flags are defined in the PPR-Flags field of PPR TLV, which are 288 shown below: 290 0 1 2 3 4 5 6 7 15 291 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 292 |I | Reserved | 293 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 295 Figure 3: PPR-Flags Field 297 I Flag: IGP flag. If set, IGP will be used to flood this path as 298 described in [I-D.chunduri-lsr-isis-preferred-path-routing] and 299 [I-D.chunduri-lsr-isis-preferred-path-routing]. If not set, the 300 PCC received this TLV will verify the path information, and if it 301 sees itself as part of the PPR path, it will install the 302 corresponding path information into its forwarding table. 304 Reserved: This field Must be set to zero in transmission and ignored 305 on reception. 307 4.2.2. PPR-Prefix Sub-TLV 309 A PPR-Prefix Sub-TLV contains a prefix for the path described in a 310 PPR TLV. Its format is illustrated below: 312 0 1 2 3 313 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 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | Type = TBD4 | Length | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | MT-ID | Prefix Length | Mask Length | Reserved | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 // Prefix (variable) // 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | PPR-Prefix Sub-TLVs (variable) | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 Figure 4: PPR-Prefix Sub-TLV Format 326 Type: TBD4 is to be assigned by IANA. 328 Length: Total length of the value field in bytes (variable). 330 MT-ID: 1 octet. Multi-Topology ID (as defined in [RFC4915]). 332 Prefix Length: 1 octet. It is the length of the prefix in bits. 333 Only the most significant octets of the Prefix are encoded. 335 Mask Length: 1 octet. It is the valid length of the prefix in bits. 336 Only the most significant octets of the Prefix are encoded. 338 Reserved: 1 octet. Must be set to zero in transmission and ignored 339 on reception. 341 Prefix: Variable octets. It represents the prefix at the tail-end 342 of the PPR. For the address family IPv4 unicast, the prefix 343 itself is encoded as a 32-bit value. The default route is 344 represented by a prefix of length 0. 346 PPR-Prefix Sub-TLVs: Variable octets. It has 1 octet type, 1 octet 347 length and value field is defined per the type field. 349 4.2.3. PPR-ID Sub-TLV 351 A PPR-ID Sub-TLV contains an identifier, which represents the actual 352 data plane identifier in the packet and could be of any data plane as 353 defined in PPR-ID-type field. Both Prefix and PPR-ID MUST belong to 354 a same node in the network. The format of the PPR-ID Sub-TLV is 355 illustrated below: 357 0 1 2 3 358 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 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | Type = TBD5 | Length | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | PPR-ID Flags | PPR-ID Type | PPR-ID Length | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 |PPR-ID Mask Len| Algo | PPR-ID // 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 // PPR-ID (cont., variable size) // 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 Figure 5: PPR-ID Sub-TLV Format 371 Type: TBD5 is to be assigned by IANA. 373 Length: Total length of the value field in bytes (variable). 375 PPR-ID Type: 1 octet. Data plane type of PPR-ID. This is a new 376 registry (TBD IANA) for this Sub-TLV and the defined types are as 377 follows: 379 a. Type = 1: MPLS SID/Label. 381 b. Type = 2: Native IPv4 Address/Prefix. 383 c. Type = 3: Native IPv6 Address/Prefix. 385 d. Type = 4: IPv6 SID in SRv6 with SRH. 387 PPR-ID Flags: 2 octets. Two flags are defined below: 389 0 1 2 3 4 5 6 7 15 390 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 391 | Reserved | 392 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 394 Reserved: Reserved bits for future use. They must be set to zero 395 in transmission and ignored on reception. 397 PPR-ID Length: 1 octet. It is the length of the PPR-ID field in 398 octets and this depends on the PPR-ID type. See PPR-ID below for 399 the length of this field and other considerations. 401 PPR-ID Mask Len: 1 octet. It is applicable for only for PPR-ID Type 402 2. For Type 1 this value MUST be set to zero. It contains the 403 length of the PPR-ID Prefix in bits. Only the most significant 404 octets of the Prefix are encoded. This is needed, if PPR-ID 405 followed is an IPv4 Prefix instead of 4 octet Address 406 respectively. 408 Algo: 1 octet. It represents the SPF algorithm. Algorithm registry 409 is as defined in [I-D.ietf-ospf-segment-routing-extensions]. 411 PPR-ID: Variable octets. It represents the Preferred Path 412 forwarding identifier that would be on the data packet. The value 413 of this field is variable and it depends on the PPR-ID Type - for 414 Type 1, this is and MPLS SID/Label. For Type 2 this is a 4 byte 415 IPv4 address. 417 4.2.4. PPR-PDE Sub-TLV 419 This is a new Sub-TLV type in PPR TLV and is called as PPR Path 420 Description Element (PDE). PPR-PDEs are used to describe the path in 421 the form of set of contiguous and ordered Sub-TLVs, where first Sub- 422 TLV represents (the top of the stack in MPLS data plane or) first 423 node/segment of the path. These set of ordered Sub-TLVs can have 424 both topological SIDs and non-topological SIDs (e.g., service 425 segments). The format of the PPR-PDE Sub-TLV is illustrated below: 427 0 1 2 3 428 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 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | Type = TBD6 | Length | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 | PPR-PDE Type | PDE-ID Type | PDE-ID Len | Reserved | 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 | PPR-PDE Flags | PDE-ID Value // 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 // PDE-ID Value (Contd., Variable size) // 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 | PPR-PDE Sub-TLVs (variable) | 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 Figure 6: PPR-PDE Sub-TLV Format 443 Type: TBD6 is to be assigned by IANA. 445 Length: Total length of the value field in bytes (variable). 447 PPR-PDE Type: 1 octet. This is a new registry (TBD IANA) for this 448 Sub-TLV and the defined types are as follows: 450 a. Type = 1: Topological. 452 b. Type = 2: Non-Topological. 454 PPR-ID Type: 1 octet. PDE-forwarding IDentifier Type. This is a 455 new registry (TBD IANA) for this Sub-TLV and the defined types and 456 corresponding PDE-ID Len, PDE-ID Value are as follows: 458 Type = 1: SID/Label Sub-TLV as defined in [I-D.ietf-ospf-segment- 459 routing-extensions]. PDE-ID Len and PDE- ID Value fields are 460 defined as the above. 462 Type = 2: SR-MPLS Prefix SID. PDE-ID Len and PDE-ID Value are 463 the same as Type 1. 465 Type = 3: SR-MPLS Adjacency SID. PDE-ID Len and PDE-ID Value are 466 the same as Type 1. 468 Type = 4: IPv4 Node Address. PDE-ID Len is 4 bytes and PDE-ID 469 Value is 4 bytes IPv4 address encoded similar to IPv4 Prefix 470 described above. 472 Type = 5: IPv4 P2P interface Address. PDE-ID Len is 4 bytes and 473 PDE-ID Value is 4 bytes IPv4 address encoded similar to IPv4 474 Prefix described above. 476 Type = 6: IPv4 LAN interface Address. PDE-ID Len is 4 bytes and 477 PDE-ID Value is 4 bytes IPv4 address encoded similar to IPv4 478 Prefix described above. 480 Type = 7: IPv6 Node Address. PDE-ID Len is 16 bytes and PDE-ID 481 Value is 16 bytes IPv6 address encoded similar to IPv6 Prefix 482 described above. 484 Type = 8: IPv6 P2P interface Address. PDE-ID Len is 16 bytes and 485 PDE-ID Value is 16 bytes IPv6 address encoded similar to IPv6 486 Prefix described above. 488 Type = 9: IPv6 LAN interface Address. PDE-ID Len is 16 bytes and 489 PDE-ID Value is 16 bytes IPv6 address encoded similar to IPv6 490 Prefix described above. 492 Type = 10: SRv6 Node SID as defined in 493 [I-D.ietf-lsr-isis-srv6-extensions]. 495 Type = 11: SRv6 Adjacency-SID. PDE-ID Len and PDE-ID Values are 496 similar to SRv6 Node SID above. 498 PPR-ID Len: 1 octet. It is the length of the PPR-ID field in 499 octets. 501 Reserved: 1 octet. Reserved bits MUST be reset to zero on 502 transmission and ignored on receive. 504 PPR-PDE Flags: 2 octets. Two flags are defined below: 506 0 1 2 3 4 5 6 7 15 507 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 508 |L | Reserved | 509 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 511 L: Loose Bit. Indicates the type of next "Topological PDE-ID" in 512 the path description. If set, the next Topological PDE is 513 Loose. If this flag is unset, the next Topological PDE is 514 Strict Type. 516 Reserved: Reserved bits for future use. They must be set to zero 517 in transmission and ignored on reception. 519 PPR-PDE Sub-TLVs: TBD. It has 2 octet type, 2 octet length and 520 value field is defined per type. 522 4.2.5. PPR-Attributes Sub-TLV 524 PPR-Attribute Sub-TLVs describe the attributes of the path. The 525 following Sub-TLVs draw from a new registry for Sub-TLV numbers; this 526 registry is to be created by IANA, and administered using the first 527 come first serve process: 529 Type: TBD7 is to be assigned by IANA. This is Packet Traffic 530 accounting Sub-TLV. Length is 0. There is no value field. It 531 specifies to create a counter to count number of packets forwarded 532 on this PPR-ID on each node in the path description. 534 Type: TBD8 is to be assigned by IANA. This is Traffic statistics in 535 Bytes Sub-TLV. Length is 0. Thee is no value field. It 536 specifies to create a counter to count number of bytes forwarded 537 on this PPR-ID specified in the network header (e.g. IPv4, IPv6) 538 on each node in the path description. 540 Type: TBD9 is to be assigned by IANA. PPR-Metric Sub-TLV. Length 541 is 4 bytes, and Value is metric of this path represented through 542 the PPR-ID. Different nodes can advertise the same PPR-ID for the 543 same Prefix with a different set of PPR-PDE Sub-TLVs and the 544 receiving node MUST consider the lowest metric value (TBD more, on 545 what happens when metric is same for two different set of PPR-PDE 546 Sub-TLVs). 548 5. Procedures 550 PPR_CAPABILITY sub-TLV in the Open message is exchanged between a PCC 551 and a PCE to indicate the support of PPR. When both the PCC and the 552 PCE support PPR_CAPABILITY, each of the Open messages sent by the PCC 553 and PCE contains PATH_SETUP_TYPE_CAPABILITY TLV with a PST list 554 containing PST=TBD1 and a PPR_CAPABILITY sub-TLV. 556 If a PCC sets the I bit to 1 in PPR_CAPABILITY sub-TLV, it means this 557 PCC is capable of flooding PPR path info across IGP domain. 558 Otherwise it means it supports to install PPR path info into its 559 forwarding table but can't flood the information. 561 After a PCC receives a PPR TLV, it needs to verify whether it's 562 valid. 564 If a PCC receives a PPR TLV with flog I bit set to 1, however this 565 PCC doesn't support IGP flooding of PPR info, it MUST consider the 566 TLV invalid and MUST sent a PCErr message with Error-Type = 10 567 ("Reception of an invalid object"). 569 The PPR TLV contains a sequence of subobjects/sub TLVs, which defines 570 the PPR path information. If a routing process/protocol is 571 configured to flood PPR path, it interprets the sub TLVs and converts 572 them into corresponding routing protocol TLVs and flood them. 574 Section 4 in [I-D.chunduri-lsr-isis-preferred-path-routing] describes 575 how PCCs act after receiving path information from a controller. 577 6. Management Considerations 579 This document adds a new path setup type to PCEP to allow PPR paths 580 to be set up on PCCs. This path setup type may be used with PECP 581 alongside other path setup types, such as RSVP-TE, Segment Routing 582 Traffic Engineering, or it may be used exclusively. 584 The PATH-SETUP-TYPE-CAPABILITY TLV is used to indicate the path setup 585 type supported. It requires both PCC and PCE to include PST=TBD1, 586 also include the PPR-CAPABILITY sub-TLV. 588 A network operator can use the following steps to enable PCEP to 589 setup paths using PPR as path setup type: 591 o The operator enables the PPR PST on the PCE servers. 593 o The operator enables the PPR PST on the PCCs. 595 o The operator resets each PCEP session. The PCEP sessions come 596 back up with PPR enabled. 598 o If the operator detects a problem, they can roll the network back 599 to its initial state by disabling the PPR PST on the PCEP speakers 600 and resetting the PCEP sessions. 602 The data plane is unaffected if a PCEP session is reset. Any PPR 603 path that was set up before the session reset will remain in active. 605 The PPR YANG module is defined in [I-D.qct-lsr-ppr-yang], and it is 606 used to configure PPR path information on a router and it can coexist 607 with the path set up method defined in this document. 609 7. Security Considerations 611 The security considerations described in [RFC5440], [RFC8231], 612 [RFC8281] and [RFC8408] are applicable to this specification. No 613 additional security measure is required. 615 This draft enables a network controller to instantiate a path in the 616 network, and that creates additional vulnerability. 618 8. IANA Considerations 620 TBD. 622 9. Acknowledgements 624 TBD. 626 10. References 628 10.1. Normative References 630 [I-D.chunduri-lsr-isis-preferred-path-routing] 631 Chunduri, U., Li, R., White, R., Tantsura, J., Contreras, 632 L., and Y. Qu, "Preferred Path Routing (PPR) in IS-IS", 633 draft-chunduri-lsr-isis-preferred-path-routing-03 (work in 634 progress), May 2019. 636 [I-D.chunduri-lsr-ospf-preferred-path-routing] 637 Chunduri, U., Qu, Y., White, R., Tantsura, J., and L. 638 Contreras, "Preferred Path Routing (PPR) in OSPF", draft- 639 chunduri-lsr-ospf-preferred-path-routing-03 (work in 640 progress), May 2019. 642 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 643 Requirement Levels", BCP 14, RFC 2119, 644 DOI 10.17487/RFC2119, March 1997, 645 . 647 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 648 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 649 DOI 10.17487/RFC5440, March 2009, 650 . 652 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 653 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 654 May 2017, . 656 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 657 Computation Element Communication Protocol (PCEP) 658 Extensions for Stateful PCE", RFC 8231, 659 DOI 10.17487/RFC8231, September 2017, 660 . 662 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 663 Computation Element Communication Protocol (PCEP) 664 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 665 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 666 . 668 [RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J. 669 Hardwick, "Conveying Path Setup Type in PCE Communication 670 Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408, 671 July 2018, . 673 10.2. Informative References 675 [I-D.ietf-6man-segment-routing-header] 676 Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and 677 d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header 678 (SRH)", draft-ietf-6man-segment-routing-header-18 (work in 679 progress), April 2019. 681 [I-D.ietf-lsr-isis-srv6-extensions] 682 Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and 683 Z. Hu, "IS-IS Extensions to Support Routing over IPv6 684 Dataplane", draft-ietf-lsr-isis-srv6-extensions-00 (work 685 in progress), May 2019. 687 [I-D.ietf-pce-segment-routing] 688 Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 689 and J. Hardwick, "PCEP Extensions for Segment Routing", 690 draft-ietf-pce-segment-routing-16 (work in progress), 691 March 2019. 693 [I-D.ietf-spring-segment-routing] 694 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 695 Litkowski, S., and R. Shakir, "Segment Routing 696 Architecture", draft-ietf-spring-segment-routing-15 (work 697 in progress), January 2018. 699 [I-D.ietf-spring-segment-routing-mpls] 700 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., 701 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 702 data plane", draft-ietf-spring-segment-routing-mpls-18 703 (work in progress), December 2018. 705 [I-D.qct-lsr-ppr-yang] 706 Qu, Y., Chunduri, U., and J. Tantsura, "YANG Data Model 707 for Preferred Path Routing", draft-qct-lsr-ppr-yang-01 708 (work in progress), March 2019. 710 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 711 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 712 RFC 4915, DOI 10.17487/RFC4915, June 2007, 713 . 715 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 716 Topology (MT) Routing in Intermediate System to 717 Intermediate Systems (IS-ISs)", RFC 5120, 718 DOI 10.17487/RFC5120, February 2008, 719 . 721 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 722 Chaining (SFC) Architecture", RFC 7665, 723 DOI 10.17487/RFC7665, October 2015, 724 . 726 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 727 Decraene, B., Litkowski, S., and R. Shakir, "Segment 728 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 729 July 2018, . 731 Authors' Addresses 733 Yingzhen Qu 734 Futurewei 736 EMail: yingzhen.qu@futurewei.com 738 Huaimo Chen 739 Futurewei 741 EMail: huaimo.chen@futurewei.com