idnits 2.17.1 draft-ietf-pce-segment-routing-16.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 -- The document date (March 4, 2019) is 1873 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) == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-18 == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-16 == Outdated reference: A later version (-18) exists of draft-ietf-idr-bgp-ls-segment-routing-msd-02 == Outdated reference: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-22 == Outdated reference: A later version (-23) exists of draft-ietf-pce-pcep-yang-09 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-02 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE S. Sivabalan 3 Internet-Draft C. Filsfils 4 Updates: 8408 (if approved) Cisco Systems, Inc. 5 Intended status: Standards Track J. Tantsura 6 Expires: September 5, 2019 Apstra, Inc. 7 W. Henderickx 8 Nokia 9 J. Hardwick 10 Metaswitch Networks 11 March 4, 2019 13 PCEP Extensions for Segment Routing 14 draft-ietf-pce-segment-routing-16 16 Abstract 18 Segment Routing (SR) enables any head-end node to select any path 19 without relying on a hop-by-hop signaling technique (e.g., LDP or 20 RSVP-TE). It depends only on "segments" that are advertised by link- 21 state Interior Gateway Protocols (IGPs). A Segment Routing Path can 22 be derived from a variety of mechanisms, including an IGP Shortest 23 Path Tree (SPT), explicit configuration, or a Path Computation 24 Element (PCE). This document specifies extensions to the Path 25 Computation Element Communication Protocol (PCEP) that allow a 26 stateful PCE to compute and initiate Traffic Engineering (TE) paths, 27 as well as a PCC to request a path subject to certain constraints and 28 optimization criteria in SR networks. 30 Requirements Language 32 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 33 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 34 "OPTIONAL" in this document are to be interpreted as described in BCP 35 14 [RFC2119] [RFC8174] when, and only when, they appear in all 36 capitals, as shown here. 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at https://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on September 5, 2019. 55 Copyright Notice 57 Copyright (c) 2019 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (https://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 73 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 74 3. Overview of PCEP Operation in SR Networks . . . . . . . . . . 5 75 4. Object Formats . . . . . . . . . . . . . . . . . . . . . . . 7 76 4.1. The OPEN Object . . . . . . . . . . . . . . . . . . . . . 7 77 4.1.1. The Path Setup Type Capability TLV . . . . . . . . . 7 78 4.1.2. The SR PCE Capability sub-TLV . . . . . . . . . . . . 8 79 4.2. The RP/SRP Object . . . . . . . . . . . . . . . . . . . . 9 80 4.3. ERO . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 81 4.3.1. SR-ERO Subobject . . . . . . . . . . . . . . . . . . 9 82 4.3.2. NAI Associated with SID . . . . . . . . . . . . . . . 12 83 4.4. RRO . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 84 4.5. METRIC Object . . . . . . . . . . . . . . . . . . . . . . 14 85 5. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 15 86 5.1. Exchanging the SR PCE Capability . . . . . . . . . . . . 15 87 5.2. ERO Processing . . . . . . . . . . . . . . . . . . . . . 16 88 5.2.1. SR-ERO Validation . . . . . . . . . . . . . . . . . . 16 89 5.2.2. Interpreting the SR-ERO . . . . . . . . . . . . . . . 18 90 5.3. RRO Processing . . . . . . . . . . . . . . . . . . . . . 20 91 6. Management Considerations . . . . . . . . . . . . . . . . . . 21 92 6.1. Controlling the Path Setup Type . . . . . . . . . . . . . 21 93 6.2. Migrating a Network to Use PCEP Segment Routed Paths . . 22 94 6.3. Verification of Network Operation . . . . . . . . . . . . 23 95 6.4. Relationship to Existing Management Models . . . . . . . 24 97 7. Security Considerations . . . . . . . . . . . . . . . . . . . 24 98 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 99 8.1. PCEP ERO and RRO subobjects . . . . . . . . . . . . . . . 24 100 8.2. New NAI Type Registry . . . . . . . . . . . . . . . . . . 25 101 8.3. New SR-ERO Flag Registry . . . . . . . . . . . . . . . . 25 102 8.4. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 26 103 8.5. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 27 104 8.6. PATH-SETUP-TYPE-CAPABILITY Sub-TLV Type Indicators . . . 27 105 8.7. New Path Setup Type . . . . . . . . . . . . . . . . . . . 28 106 8.8. New Metric Type . . . . . . . . . . . . . . . . . . . . . 28 107 8.9. SR PCE Capability Flags . . . . . . . . . . . . . . . . . 28 108 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29 109 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 110 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 111 11.1. Normative References . . . . . . . . . . . . . . . . . . 29 112 11.2. Informative References . . . . . . . . . . . . . . . . . 30 113 Appendix A. Compatibility with Early Implementations . . . . . . 32 114 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 116 1. Introduction 118 Segment Routing (SR) leverages the source routing paradigm. Using 119 SR, a source node steers a packet through a path without relying on 120 hop-by-hop signaling protocols such as LDP or RSVP-TE. Each path is 121 specified as an ordered list of instructions called "segments". Each 122 segment is an instruction to route the packet to a specific place in 123 the network, or to perform a function on the packet. A database of 124 segments can be distributed through the network using a routing 125 protocol (such as IS-IS or OSPF) or by any other means. Several 126 types of segment are defined. A node segment uniquely identifies a 127 specific node in the SR domain. Each router in the SR domain 128 associates a node segment with an ECMP-aware shortest path to the 129 node that it identifies. An adjacency segment represents a 130 unidirectional adjacency. An adjacency segment is local to the node 131 which advertises it. Both node segments and adjacency segments can 132 be used for SR. 134 [RFC8402] describes the SR architecture. The corresponding IS-IS and 135 OSPF extensions are specified in 136 [I-D.ietf-isis-segment-routing-extensions] and 137 [I-D.ietf-ospf-segment-routing-extensions], respectively. 139 The SR architecture can be implemented using either an MPLS 140 forwarding plane [I-D.ietf-spring-segment-routing-mpls] or an IPv6 141 forwarding plane [I-D.ietf-6man-segment-routing-header]. The MPLS 142 forwarding plane can be applied to SR without any change, in which 143 case an SR path corresponds to an MPLS Label Switching Path (LSP). 144 This document is relevant to the MPLS forwarding plane only. In this 145 document, "Node-SID" and "Adjacency-SID" denote Node Segment 146 Identifier and Adjacency Segment Identifier respectively. 148 A Segment Routing path (SR path) can be derived from an IGP Shortest 149 Path Tree (SPT). SR-TE paths may not follow an IGP SPT. Such paths 150 may be chosen by a suitable network planning tool and provisioned on 151 the ingress node of the SR-TE path. 153 [RFC5440] describes the Path Computation Element Communication 154 Protocol (PCEP) for communication between a Path Computation Client 155 (PCC) and a Path Computation Element (PCE) or between a pair of PCEs. 156 A PCE computes paths for MPLS Traffic Engineering LSPs (MPLS-TE LSPs) 157 based on various constraints and optimization criteria. [RFC8231] 158 specifies extensions to PCEP that allow a stateful PCE to compute and 159 recommend network paths in compliance with [RFC4657] and defines 160 objects and TLVs for MPLS-TE LSPs. Stateful PCEP extensions provide 161 synchronization of LSP state between a PCC and a PCE or between a 162 pair of PCEs, delegation of LSP control, reporting of LSP state from 163 a PCC to a PCE, controlling the setup and path routing of an LSP from 164 a PCE to a PCC. Stateful PCEP extensions are intended for an 165 operational model in which LSPs are configured on the PCC, and 166 control over them is delegated to the PCE. 168 A mechanism to dynamically initiate LSPs on a PCC based on the 169 requests from a stateful PCE or a controller using stateful PCE is 170 specified in [RFC8281]. This mechanism is useful in Software Defined 171 Networking (SDN) applications, such as on-demand engineering, or 172 bandwidth calendaring [RFC8413]. 174 It is possible to use a stateful PCE for computing one or more SR-TE 175 paths taking into account various constraints and objective 176 functions. Once a path is chosen, the stateful PCE can initiate an 177 SR-TE path on a PCC using PCEP extensions specified in [RFC8281] 178 using the SR specific PCEP extensions specified in this document. 179 Additionally, using procedures described in this document, a PCC can 180 request an SR path from either a stateful or a stateless PCE. 182 This specification relies on the procedures specified in [RFC8408] to 183 exchange the segment routing capability and to specify that the path 184 setup type of an LSP is segment routing. This specification also 185 updates [RFC8408] to clarify the use of sub-TLVs in the PATH-SETUP- 186 TYPE-CAPABILITY TLV. See Section 4.1.1 for details. 188 This specification provides a mechanism for a network controller 189 (acting as a PCE) to instantiate candidate paths for an SR Policy 190 onto a head-end node (acting as a PCC) using PCEP. For more 191 information on the SR Policy Architecture, see 192 [I-D.ietf-spring-segment-routing-policy]. 194 2. Terminology 196 The following terminologies are used in this document: 198 ERO: Explicit Route Object 200 IGP: Interior Gateway Protocol 202 IS-IS: Intermediate System to Intermediate System 204 LSR: Label Switching Router 206 MSD: Base MPLS Imposition Maximum SID Depth, as defined in [RFC8491] 208 NAI: Node or Adjacency Identifier 210 OSPF: Open Shortest Path First 212 PCC: Path Computation Client 214 PCE: Path Computation Element 216 PCEP: Path Computation Element Communication Protocol 218 RRO: Record Route Object 220 SID: Segment Identifier 222 SR: Segment Routing 224 SR-DB: Segment Routing Database: the collection of SRGBs, SRLBs and 225 SIDs and the objects they map to, advertised by a link state IGP 227 SRGB: Segment Routing Global Block 229 SRLB: Segment Routing Local Block 231 SR-TE: Segment Routing Traffic Engineering 233 3. Overview of PCEP Operation in SR Networks 235 In an SR network, the ingress node of an SR path prepends an SR 236 header to all outgoing packets. The SR header consists of a list of 237 SIDs (or MPLS labels in the context of this document). The header 238 has all necessary information so that, in combination with the 239 information distributed by the IGP, the packets can be guided from 240 the ingress node to the egress node of the path; hence, there is no 241 need for any signaling protocol. 243 In PCEP messages, LSP route information is carried in the Explicit 244 Route Object (ERO), which consists of a sequence of subobjects. SR- 245 TE paths computed by a PCE can be represented in an ERO in one of the 246 following forms: 248 o An ordered set of IP addresses representing network nodes/links. 250 o An ordered set of SIDs, with or without the corresponding IP 251 addresses. 253 o An ordered set of MPLS labels, with or without corresponding IP 254 address. 256 The PCC converts these into an MPLS label stack and next hop, as 257 described in Section 5.2.2. 259 This document defines a new ERO subobject denoted by "SR-ERO 260 subobject" capable of carrying a SID as well as the identity of the 261 node/adjacency represented by the SID. SR-capable PCEP speakers 262 should be able to generate and/or process such ERO subobject. An ERO 263 containing SR-ERO subobjects can be included in the PCEP Path 264 Computation Reply (PCRep) message defined in [RFC5440], the PCEP LSP 265 Initiate Request message (PCInitiate) defined in [RFC8281], as well 266 as in the PCEP LSP Update Request (PCUpd) and PCEP LSP State Report 267 (PCRpt) messages defined in [RFC8231]. 269 When a PCEP session between a PCC and a PCE is established, both PCEP 270 speakers exchange their capabilities to indicate their ability to 271 support SR-specific functionality. 273 A PCE can update an LSP that is initially established via RSVP-TE 274 signaling to use an SR-TE path, by sending a PCUpd to the PCC that 275 delegated the LSP to it ([RFC8231]). A PCC can update an undelegated 276 LSP that is initially established via RSVP-TE signaling to use an SR- 277 TE path as follows. First, it requests an SR-TE Path from a PCE by 278 sending a PCReq message. If it receives a suitable path, it 279 establishes the path in the data plane, and then tears down the 280 original RSVP-TE path. If the PCE is stateful, then the PCC sends 281 PCRpt messages indicating that the new path is set up and the old 282 path is torn down, per [RFC8231]. 284 Similarly, a PCE or PCC can update an LSP initially created with an 285 SR-TE path to use RSVP-TE signaling, if necessary. This capability 286 is useful for rolling back a change when a network is migrated from 287 RSVP-TE to SR-TE technology. 289 A PCC MAY include an RRO containing the recorded LSP in PCReq and 290 PCRpt messages as specified in [RFC5440] and [RFC8231], respectively. 292 This document defines a new RRO subobject for SR networks. The 293 methods used by a PCC to record the SR-TE LSP are outside the scope 294 of this document. 296 In summary, this document: 298 o Defines a new ERO subobject, a new RRO subobject and new PCEP 299 error codes. 301 o Specifies how two PCEP speakers can establish a PCEP session that 302 can carry information about SR-TE paths. 304 o Specifies processing rules for the ERO subobject. 306 o Defines a new path setup type to be used in the PATH-SETUP-TYPE 307 and PATH-SETUP-TYPE-CAPABILITY TLVs ([RFC8408]). 309 o Defines a new sub-TLV for the PATH-SETUP-TYPE-CAPABILITY TLV. 311 The extensions specified in this document complement the existing 312 PCEP specifications to support SR-TE paths. As such, the PCEP 313 messages (e.g., Path Computation Request, Path Computation Reply, 314 Path Computation Report, Path Computation Update, Path Computation 315 Initiate, etc.,) are formatted according to [RFC5440], [RFC8231], 316 [RFC8281], and any other applicable PCEP specifications. 318 4. Object Formats 320 4.1. The OPEN Object 322 4.1.1. The Path Setup Type Capability TLV 324 [RFC8408] defines the PATH-SETUP-TYPE-CAPABILITY TLV for use in the 325 OPEN object. The PATH-SETUP-TYPE-CAPABILITY TLV contains an optional 326 list of sub-TLVs which are intended to convey parameters that are 327 associated with the path setup types supported by a PCEP speaker. 329 This specification updates [RFC8408], as follows. It creates a new 330 registry which defines the valid type indicators of the sub-TLVs of 331 the PATH-SETUP-TYPE-CAPABILITY TLV (see Section 8.6). A PCEP speaker 332 MUST NOT include a sub-TLV in the PATH-SETUP-TYPE-CAPABILITY TLV 333 unless it appears in this registry. If a PCEP speaker receives a 334 sub-TLV whose type indicator does not match one of those from the 335 registry, or else is not recognised by the speaker, then the speaker 336 MUST ignore the sub-TLV. 338 4.1.2. The SR PCE Capability sub-TLV 340 This document defines a new Path Setup Type (PST) for SR, as follows: 342 o PST = 1: Path is setup using Segment Routing Traffic Engineering. 344 A PCEP speaker SHOULD indicate its support of the function described 345 in this document by sending a PATH-SETUP-TYPE-CAPABILITY TLV in the 346 OPEN object with this new PST included in the PST list. 348 This document also defines the SR-PCE-CAPABILITY sub-TLV. PCEP 349 speakers use this sub-TLV to exchange information about their SR 350 capability. If a PCEP speaker includes PST=1 in the PST List of the 351 PATH-SETUP-TYPE-CAPABILITY TLV then it MUST also include the SR-PCE- 352 CAPABILITY sub-TLV inside the PATH-SETUP-TYPE-CAPABILITY TLV. 354 The format of the SR-PCE-CAPABILITY sub-TLV is shown in the following 355 figure: 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=TBD11 | Length=4 | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | Reserved | Flags |N|X| MSD | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 Figure 1: SR-PCE-CAPABILITY sub-TLV format 367 The code point for the TLV type is TBD11. The TLV length is 4 368 octets. 370 The 32-bit value is formatted as follows. 372 Reserved: MUST be set to zero by the sender and MUST be ignored by 373 the receiver. 375 Flags: This document defines the following flag bits. The other 376 bits MUST be set to zero by the sender and MUST be ignored by the 377 receiver. 379 * N: A PCC sets this flag bit to 1 to indicate that it is capable 380 of resolving a Node or Adjacency Identifier (NAI) to a SID. 382 * X: A PCC sets this flag bit to 1 to indicate that it does not 383 impose any limit on the MSD. 385 Maximum SID Depth (MSD): specifies the maximum number of SIDs (MPLS 386 label stack depth in the context of this document) that a PCC is 387 capable of imposing on a packet. Section 5.1 explains the 388 relationship between this field and the X flag. 390 4.2. The RP/SRP Object 392 To set up an SR-TE LSP using SR, the RP (Request Parameters) or SRP 393 (Stateful PCE Request Parameters) object MUST include the PATH-SETUP- 394 TYPE TLV, specified in [RFC8408], with the PST set to 1 (path setup 395 using SR-TE). 397 The LSP-IDENTIFIERS TLV MAY be present for the above PST type. 399 4.3. ERO 401 An SR-TE path consists of one or more SIDs where each SID MAY be 402 associated with the identifier that represents the node or adjacency 403 corresponding to the SID. This identifier is referred to as the 404 'Node or Adjacency Identifier' (NAI). As described later, a NAI can 405 be represented in various formats (e.g., IPv4 address, IPv6 address, 406 etc). Furthermore, a NAI is used for troubleshooting purposes and, 407 if necessary, to derive SID value as described below. 409 The ERO specified in [RFC5440] is used to carry SR-TE path 410 information. In order to carry SID and/or NAI, this document defines 411 a new ERO subobject referred to as "SR-ERO subobject" whose format is 412 specified in the following section. An ERO carrying an SR-TE path 413 consists of one or more ERO subobjects, and MUST carry only SR-ERO 414 subobjects. Note that an SR-ERO subobject does not need to have both 415 SID and NAI. However, at least one of them MUST be present. 417 When building the MPLS label stack from ERO, a PCC MUST assume that 418 SR-ERO subobjects are organized as a last-in-first-out stack. The 419 first subobject relative to the beginning of ERO contains the 420 information about the topmost label. The last subobject contains 421 information about the bottommost label. 423 4.3.1. SR-ERO Subobject 425 An SR-ERO subobject is formatted as shown in the following diagram. 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 |L| Type=36 | Length | NT | Flags |F|S|C|M| 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 | SID (optional) | 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 // NAI (variable, optional) // 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 Figure 2: SR-ERO subobject format 439 The fields in the SR-ERO Subobject are as follows: 441 The 'L' Flag: Indicates whether the subobject represents a loose-hop 442 in the LSP [RFC3209]. If this flag is set to zero, a PCC MUST NOT 443 overwrite the SID value present in the SR-ERO subobject. 444 Otherwise, a PCC MAY expand or replace one or more SID values in 445 the received SR-ERO based on its local policy. 447 Type: Set to 36. 449 Length: Contains the total length of the subobject in octets. The 450 Length MUST be at least 8, and MUST be a multiple of 4. An SR-ERO 451 subobject MUST contain at least one of a SID or an NAI. The flags 452 described below indicate whether the SID or NAI fields are absent. 454 NAI Type (NT): Indicates the type and format of the NAI contained in 455 the object body, if any is present. If the F bit is set to zero 456 (see below) then the NT field has no meaning and MUST be ignored 457 by the receiver. This document describes the following NT values: 459 NT=0 The NAI is absent. 461 NT=1 The NAI is an IPv4 node ID. 463 NT=2 The NAI is an IPv6 node ID. 465 NT=3 The NAI is an IPv4 adjacency. 467 NT=4 The NAI is an IPv6 adjacency with global IPv6 addresses. 469 NT=5 The NAI is an unnumbered adjacency with IPv4 node IDs. 471 NT=6 The NAI is an IPv6 adjacency with link-local IPv6 addresses. 473 Flags: Used to carry additional information pertaining to the SID. 474 This document defines the following flag bits. The other bits 475 MUST be set to zero by the sender and MUST be ignored by the 476 receiver. 478 * M: If this bit is set to 1, the SID value represents an MPLS 479 label stack entry as specified in [RFC3032]. Otherwise, the 480 SID value is an administratively configured value which 481 represents an index into an MPLS label space (either SRGB or 482 SRLB) per [RFC8402]. 484 * C: If the M bit and the C bit are both set to 1, then the TC, 485 S, and TTL fields in the MPLS label stack entry are specified 486 by the PCE. However, a PCC MAY choose to override these values 487 according its local policy and MPLS forwarding rules. If the M 488 bit is set to 1 but the C bit is set to zero, then the TC, S, 489 and TTL fields MUST be ignored by the PCC. The PCC MUST set 490 these fields according to its local policy and MPLS forwarding 491 rules. If the M bit is set to zero then the C bit MUST be set 492 to zero. 494 * S: When this bit is set to 1, the SID value in the subobject 495 body is absent. In this case, the PCC is responsible for 496 choosing the SID value, e.g., by looking up in the SR-DB using 497 the NAI which, in this case, MUST be present in the subobject. 498 If the S bit is set to 1 then the M and C bits MUST be set to 499 zero. 501 * F: When this bit is set to 1, the NAI value in the subobject 502 body is absent. The F bit MUST be set to 1 if NT=0, and 503 otherwise MUST be set to zero. The S and F bits MUST NOT both 504 be set to 1. 506 SID: The Segment Identifier. Depending on the M bit, it contains 507 either: 509 * A 4 octet index defining the offset into an MPLS label space 510 per [RFC8402]. 512 * A 4 octet MPLS Label Stack Entry, where the 20 most significant 513 bits encode the label value per [RFC3032]. 515 NAI: The NAI associated with the SID. The NAI's format depends on 516 the value in the NT field, and is described in the following 517 section. 519 At least one of the SID and the NAI MUST be included in the SR-ERO 520 subobject, and both MAY be included. 522 4.3.2. NAI Associated with SID 524 This document defines the following NAIs: 526 'IPv4 Node ID' is specified as an IPv4 address. In this case, the 527 NT value is 1 and the NAI field length is 4 octets. 529 'IPv6 Node ID' is specified as an IPv6 address. In this case, the 530 NT value is 2 and the NAI field length is 16 octets. 532 'IPv4 Adjacency' is specified as a pair of IPv4 addresses. In this 533 case, the NT value is 3 and the NAI field length is 8 octets. The 534 format of the NAI is shown in the following figure: 536 0 1 2 3 537 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 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 | Local IPv4 address | 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 | Remote IPv4 address | 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 Figure 3: NAI for IPv4 adjacency 546 'IPv6 Global Adjacency' is specified as a pair of global IPv6 547 addresses. It is used to describe an IPv6 adjacency for a link 548 that uses global IPv6 addresses. Each global IPv6 address is 549 configured on a specific router interface, so together they 550 identify an adjacency between a pair of routers. In this case, 551 the NT value is 4 and the NAI field length is 32 octets. The 552 format of the NAI is shown in the following figure: 554 0 1 2 3 555 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 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 // Local IPv6 address (16 octets) // 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 // Remote IPv6 address (16 octets) // 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 Figure 4: NAI for IPv6 global adjacency 564 'Unnumbered Adjacency with IPv4 NodeIDs' is specified as a pair of 565 (node ID, interface ID) tuples. In this case, the NT value is 5 566 and the NAI field length is 16 octets. The format of the NAI is 567 shown in the following figure: 569 0 1 2 3 570 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 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 | Local Node-ID | 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 | Local Interface ID | 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 | Remote Node-ID | 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 | Remote Interface ID | 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 Figure 5: NAI for Unnumbered adjacency with IPv4 Node IDs 583 'IPv6 Link-Local Adjacency' is specified as a pair of (global IPv6 584 address, interface ID) tuples. It is used to describe an IPv6 585 adjacency for a link that uses only link local IPv6 addresses. 586 Each global IPv6 address is configured on a specific router, so 587 together they identify a pair of adjacent routers. The interface 588 IDs identify the link that the adjacency is formed over. In this 589 case, the NT value is 6 and the NAI field length is 40 octets. 590 The format of the NAI is shown in the following figure: 592 0 1 2 3 593 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 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 // Local IPv6 address (16 octets) // 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 | Local Interface ID | 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 // Remote IPv6 address (16 octets) // 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 | Remote Interface ID | 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 Figure 6: NAI for IPv6 link-local adjacency 606 4.4. RRO 608 A PCC reports an SR-TE LSP to a PCE by sending a PCRpt message, per 609 [RFC8231]. The RRO on this message represents the SID list that was 610 applied by the PCC, that is, the actual path taken by the LSP. The 611 procedures of [RFC8231] with respect to the RRO apply equally to this 612 specification without change. 614 An RRO contains one or more subobjects called "SR-RRO subobjects" 615 whose format is shown below: 617 0 1 2 3 618 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 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 | Type=36 | Length | NT | Flags |F|S|C|M| 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 | SID | 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 // NAI (variable) // 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 Figure 7: SR-RRO Subobject format 629 The format of the SR-RRO subobject is the same as that of the SR-ERO 630 subobject, but without the L flag. 632 A PCC MUST order the SR-RRO subobjects such that the first subobject 633 relative to the beginning of the RRO identifies the first segment 634 visited by the SR-TE LSP, and the last subobject identifies the final 635 segment of the SR-TE LSP, that is, its endpoint. 637 4.5. METRIC Object 639 A PCC MAY request that PCE optimizes an individual path computation 640 request to minimize the SID depth of the computed path by using the 641 METRIC object defined in [RFC5440]. This document defines a new type 642 for the METRIC object to be used for this purpose, as follows: 644 o T = 11: Maximum SID Depth of the requested path. 646 If the PCC includes a METRIC object of this type on a path 647 computation request, then the PCE minimizes the SID depth of the 648 computed path. If the B (bound) bit is set to to 1 in the METRIC 649 object, then the PCE MUST NOT return a path whose SID depth exceeds 650 the given metric-value. If the PCC did not set the X flag in its SR- 651 PCE-CAPABILITY TLV, then it MUST set the B bit to 1. If the PCC set 652 the X flag in its SR-PCE-CAPABILITY TLV, then it MAY set the B bit to 653 1 or zero. 655 If a PCEP session is established with a non-zero default MSD value, 656 then the PCC MUST NOT send an MSD METRIC object with an MSD greater 657 than the session's default MSD. If the PCE receives a path 658 computation request with an MSD METRIC object on such a session that 659 is greater than the session's default MSD, then it MUST consider the 660 request invalid and send a PCErr with Error-Type = 10 ("Reception of 661 an invalid object") and Error-Value 9 ("MSD exceeds the default for 662 the PCEP session"). 664 5. Procedures 666 5.1. Exchanging the SR PCE Capability 668 A PCC indicates that it is capable of supporting the head-end 669 functions for SR-TE LSP by including the SR-PCE-CAPABILITY sub-TLV in 670 the Open message that it sends to a PCE. A PCE indicates that it is 671 capable of computing SR-TE paths by including the SR-PCE-CAPABILITY 672 sub-TLV in the Open message that it sends to a PCC. 674 If a PCEP speaker receives a PATH-SETUP-TYPE-CAPABILITY TLV with a 675 PST list containing PST=1, and supports that path setup type, then it 676 checks for the presence of the SR-PCE-CAPABILITY sub-TLV. If that 677 sub-TLV is absent, then the PCEP speaker MUST send a PCErr message 678 with Error-Type 10 (Reception of an invalid object) and Error-Value 679 TBD1 (Missing PCE-SR-CAPABILITY sub-TLV) and MUST then close the PCEP 680 session. If a PCEP speaker receives a PATH-SETUP-TYPE-CAPABILITY TLV 681 with a SR-PCE-CAPABILITY sub-TLV, but the PST list does not contain 682 PST=1, then the PCEP speaker MUST ignore the SR-PCE-CAPABILITY sub- 683 TLV. 685 If a PCC sets the N flag to 1, then the PCE MAY send an SR-ERO 686 subobject containing NAI and no SID (see Section 5.2). Otherwise, 687 the PCE MUST NOT send an SR-ERO subobject containing NAI and no SID. 689 The number of SIDs that can be imposed on a packet depends on the 690 PCC's data plane's capability. If a PCC sets the X flag to 1 then 691 the MSD is not used and MUST be set to zero. If a PCE receives an 692 SR-PCE-CAPABILITY sub-TLV with the X flag set to 1 then it MUST 693 ignore the MSD field and assumes that the sender can impose a SID 694 stack of any depth. If a PCC sets the X flag to zero, then it sets 695 the MSD field to the maximum number of SIDs that it can impose on a 696 packet. In this case, the PCC MUST set the MSD to a number greater 697 than zero. If a PCE receives an SR-PCE-CAPABILITY sub-TLV with the X 698 flag and MSD both set to zero then it MUST send a PCErr message with 699 Error-Type 10 (Reception of an invalid object) and Error-Value TBD10 700 (Maximum SID depth must be nonzero) and MUST then close the PCEP 701 session. 703 Note that the MSD value exchanged via the SR-PCE-CAPABILITY sub-TLV 704 indicates the SID/label imposition limit for the PCC node. It is 705 anticipated that, in many deployments, the PCCs will have network 706 interfaces that are homogeneous with respect to MSD (that is, each 707 interface has the same MSD). In such cases, having a per-node MSD on 708 the PCEP session is sufficient; the PCE SHOULD interpret this to mean 709 that all network interfaces on the PCC have the given MSD. However, 710 the PCE MAY also learn a per-node MSD and a per-interface MSD from 711 the routing protocols, as specified in: [RFC8491]; [RFC8476]; 713 [I-D.ietf-idr-bgp-ls-segment-routing-msd]. If the PCE learns the 714 per-node MSD of a PCC from a routing protocol, then it MUST ignore 715 the per-node MSD value in the SR-PCE-CAPABILITY sub-TLV and use the 716 per-node MSD learned from the routing protocol instead. If the PCE 717 learns the MSD of a network interface on a PCC from a routing 718 protocol, then it MUST use the per-interface MSD instead of the MSD 719 value in the SR-PCE-CAPABILITY sub-TLV when it computes a path that 720 uses that interface. 722 Once an SR-capable PCEP session is established with a non-zero MSD 723 value, the corresponding PCE MUST NOT send SR-TE paths with a number 724 of SIDs exceeding that MSD value. If a PCC needs to modify the MSD 725 value, it MUST close the PCEP session and re-establish it with the 726 new MSD value. If a PCEP session is established with a non-zero MSD 727 value, and the PCC receives an SR-TE path containing more SIDs than 728 specified in the MSD value, the PCC MUST send a PCErr message with 729 Error-Type 10 (Reception of an invalid object) and Error-Value 3 730 (Unsupported number of Segment ERO subobjects). If a PCEP session is 731 established with an MSD value of zero, then the PCC MAY specify an 732 MSD for each path computation request that it sends to the PCE, by 733 including a "maximum SID depth" metric object on the request, as 734 defined in Section 4.5. 736 The N flag, X flag and MSD value inside the SR-PCE-CAPABILITY sub-TLV 737 are meaningful only in the Open message sent from a PCC to a PCE. As 738 such, a PCE MUST set the N flag to zero, the X flag to 1 and MSD 739 value to zero in an outbound message to a PCC. Similarly, a PCC MUST 740 ignore any MSD value received from a PCE. If a PCE receives multiple 741 SR-PCE-CAPABILITY sub-TLVs in an Open message, it processes only the 742 first sub-TLV received. 744 5.2. ERO Processing 746 5.2.1. SR-ERO Validation 748 If a PCC does not support the SR PCE Capability and thus cannot 749 recognize the SR-ERO or SR-RRO subobjects, it will respond according 750 to the rules for a malformed object per [RFC5440]. 752 On receiving an SR-ERO, a PCC MUST validate that the Length field, 753 the S bit, the F bit and the NT field are consistent, as follows. 755 o If NT=0, the F bit MUST be 1, the S bit MUST be zero and the 756 Length MUST be 8. 758 o If NT=1, the F bit MUST be zero. If the S bit is 1, the Length 759 MUST be 8, otherwise the Length MUST be 12. 761 o If NT=2, the F bit MUST be zero. If the S bit is 1, the Length 762 MUST be 20, otherwise the Length MUST be 24. 764 o If NT=3, the F bit MUST be zero. If the S bit is 1, the Length 765 MUST be 12, otherwise the Length MUST be 16. 767 o If NT=4, the F bit MUST be zero. If the S bit is 1, the Length 768 MUST be 36, otherwise the Length MUST be 40. 770 o If NT=5, the F bit MUST be zero. If the S bit is 1, the Length 771 MUST be 20, otherwise the Length MUST be 24. 773 o If NT=6, the F bit MUST be zero. If the S bit is 1, the Length 774 MUST be 44, otherwise the Length MUST be 48. 776 If a PCC finds that the NT field, Length field, S bit and F bit are 777 not consistent, it MUST consider the entire ERO invalid and MUST send 778 a PCErr message with Error-Type = 10 ("Reception of an invalid 779 object") and Error-Value = 11 ("Malformed object"). 781 If a PCC does not recognise or support the value in the NT field, it 782 MUST consider the entire ERO invalid and MUST send a PCErr message 783 with Error-Type = 10 ("Reception of an invalid object") and Error- 784 Value = TBD2 ("Unsupported NAI Type in Segment ERO subobject"). 786 If a PCC receives an SR-ERO subobject in which the S and F bits are 787 both set to 1 (that is, both the SID and NAI are absent), it MUST 788 consider the entire ERO invalid and send a PCErr message with Error- 789 Type = 10 ("Reception of an invalid object") and Error-Value = 6 790 ("Both SID and NAI are absent in SR-ERO subobject"). 792 If a PCC receives an SR-ERO subobject in which the S bit is set to 1 793 and the F bit is set to zero (that is, the SID is absent and the NAI 794 is present), but the PCC does not support NAI resolution, it MUST 795 consider the entire ERO invalid and send a PCErr message with Error- 796 Type = 4 ("Not supported object") and Error-Value = 4 ("Unsupported 797 parameter"). 799 If a PCC receives an SR-ERO subobject in which the S bit is set to 1 800 and either or both of the M or C bits is set to 1, it MUST consider 801 the entire ERO invalid and send a PCErr message with Error-Type = 10 802 ("Reception of an invalid object") and Error-Value = 11 ("Malformed 803 object"). 805 If a PCC receives an SR-ERO subobject in which the S bit is set to 806 zero and the M bit is set to 1, then the subobject contains an MPLS 807 label. The PCC MAY choose not to accept a label provided by the PCE, 808 based on it local policy. The PCC MUST NOT accept MPLS label value 3 809 (Implicit NULL), but it MAY accept other special purpose MPLS label 810 values. If the PCC decides not to accept an MPLS label value, it 811 MUST send a PCErr message with Error-Type = 10 ("Reception of an 812 invalid object") and Error Value = 2 ("Bad label value"). 814 If both M and C bits of an SR-ERO subobject are set to 1, and if a 815 PCC finds erroneous setting in one or more of TC, S, and TTL fields, 816 it MAY overwrite those fields with values chosen according to its own 817 policy. If the PCC does not overwrite them, it MUST send a PCErr 818 message with Error-Type = 10 ("Reception of an invalid object") and 819 Error-Value = 4 ("Bad label format"). 821 If the M bit of an SR-ERO subobject is set to zero but the C bit is 822 set to 1, then the PCC MUST consider the entire ERO invalid and MUST 823 send a PCErr message with Error-Type = 10 ("Reception of an invalid 824 object") and Error-Value = 11 ("Malformed object"). 826 If a PCC receives an SR-ERO subobject in which the S bit is set to 827 zero and the M bit is set to zero, then the subobject contains a SID 828 index value. If the SID is an Adjacency-SID then the L flag MUST NOT 829 be set. If the L flag is set for an Adjacency-SID then the PCC MUST 830 send a PCErr message with Error-Type = 10 ("Reception of an invalid 831 object") and Error-Value = 11 ("Malformed object"). 833 If a PCC detects that the subobjects of an ERO are a mixture of SR- 834 ERO subobjects and subobjects of other types, then it MUST send a 835 PCErr message with Error-Type = 10 ("Reception of an invalid object") 836 and Error-Value = 5 ("ERO mixes SR-ERO subobjects with other 837 subobject types"). 839 The SR-ERO subobjects can be classified according to whether they 840 contain a SID representing an MPLS label value, a SID representing an 841 index value, or no SID. If a PCC detects that the SR-ERO subobjects 842 are a mixture of more than one of these types, then it MUST send a 843 PCErr message with Error-Type = 10 ("Reception of an invalid object") 844 and Error-Value = TBD9 ("Inconsistent SIDs in SR-ERO / SR-RRO 845 subobjects"). 847 If an ERO specifies a new SR-TE path for an existing LSP and the PCC 848 determines that the ERO contains SR-ERO subobjects that are not 849 valid, then the PCC MUST NOT update the LSP. 851 5.2.2. Interpreting the SR-ERO 853 The SR-ERO contains a sequence of subobjects. Each SR-ERO subobject 854 in the sequence identifies a segment that the traffic will be 855 directed to, in the order given. That is, the first subobject 856 identifies the first segment the traffic will be directed to, the 857 second subobject represents the second segment, and so on. 859 The PCC interprets the SR-ERO by converting it to an MPLS label stack 860 plus a next hop. The PCC sends packets along the segment routed path 861 by prepending the MPLS label stack onto the packets and sending the 862 resulting, modified packet to the next hop. 864 The PCC uses a different procedure to do this conversion, depending 865 on the information that the PCE has provided in the subobjects. 867 o If the subobjects contain SID index values, then the PCC converts 868 them into the corresponding MPLS labels by following the procedure 869 defined in [I-D.ietf-spring-segment-routing-mpls]. 871 o If the subobjects contain NAI only, the PCC first converts each 872 NAI into a SID index value and then proceeds as above. To convert 873 an NAI to a SID index, the PCC looks for a fully-specified prefix 874 or adjacency matching the fields in the NAI. If the PCC finds a 875 matching prefix/adjacency, and the matching prefix/adjacency has a 876 SID associated with it, then the PCC uses that SID. If the PCC 877 cannot find a matching prefix/adjacency, or if the matching 878 prefix/adjacency has no SID associated with it, the PCC behaves as 879 specified in Section 5.2.2.1. 881 o If the subobjects contain MPLS labels, then the PCC looks up the 882 offset of the first subobject's label in its SRGB or SRLB. This 883 gives the first SID. The PCC pushes the labels in any remaining 884 subobjects onto the packet (with the final subobject specifying 885 the bottom-of-stack label). 887 For all cases above, after the PCC has imposed the label stack on the 888 packet, it sends the packet to the segment identified by the first 889 SID. 891 5.2.2.1. Handling Errors During SR-ERO Conversion 893 There are several errors that can occur during the process of 894 converting an SR-ERO sequence to an MPLS label stack and a next hop. 895 The PCC deals with them as follows. 897 o If the PCC cannot find a SID index in the SR-DB, it MUST send a 898 PCErr message with Error-Type = 10 ("Reception of an invalid 899 object") and Error-Value = TBD3 ("Unknown SID"). 901 o If the PCC cannot find an NAI in the SR-DB, it MUST send a PCErr 902 message with Error-Type = 10 ("Reception of an invalid object") 903 and Error-Value = TBD4 ("NAI cannot be resolved to a SID"). 905 o If the PCC needs to convert a SID into an MPLS label value but 906 cannot find the corresponding router's SRGB in the SR-DB, it MUST 907 send a PCErr message with Error-Type = 10 ("Reception of an 908 invalid object") and Error-Value = TBD5 ("Could not find SRGB"). 910 o If the PCC finds that a router's SRGB is not large enough for a 911 SID index value, it MUST send a PCErr message with Error-Type = 10 912 ("Reception of an invalid object") and Error-Value = TBD6 ("SID 913 index exceeds SRGB size"). 915 o If the PCC needs to convert a SID into an MPLS label value but 916 cannot find the corresponding router's SRLB in the SR-DB, it MUST 917 send a PCErr message with Error-Type = 10 ("Reception of an 918 invalid object") and Error-Value = TBD7 ("Could not find SRLB"). 920 o If the PCC finds that a router's SRLB is not large enough for a 921 SID index value, it MUST send a PCErr message with Error-Type = 10 922 ("Reception of an invalid object") and Error-Value = TBD8 ("SID 923 index exceeds SRLB size"). 925 o If the number of labels in the computed label stack exceeds the 926 maximum number of SIDs that the PCC can impose on the packet, it 927 MUST send a PCErr message with Error-Type = 10 ("Reception of an 928 invalid object") and Error-Value = 3 ("Unsupported number of 929 Segment ERO subobjects"). 931 If an ERO specifies a new SR-TE path for an existing LSP and the PCC 932 encounters an error while processing the ERO, then the PCC MUST NOT 933 update the LSP. 935 5.3. RRO Processing 937 The syntax checking rules that apply to the SR-RRO subobject are 938 identical to those of the SR-ERO subobject, except as noted below. 940 If a PCEP speaker receives an SR-RRO subobject in which both SID and 941 NAI are absent, it MUST consider the entire RRO invalid and send a 942 PCErr message with Error-Type = 10 ("Reception of an invalid object") 943 and Error-Value = 7 ("Both SID and NAI are absent in SR-RRO 944 subobject"). 946 If a PCE detects that the subobjects of an RRO are a mixture of SR- 947 RRO subobjects and subobjects of other types, then it MUST send a 948 PCErr message with Error-Type = 10 ("Reception of an invalid object") 949 and Error-Value = 10 ("RRO mixes SR-RRO subobjects with other 950 subobject types"). 952 The SR-RRO subobjects can be classified according to whether they 953 contain a SID representing an MPLS label value or a SID representing 954 an index value, or no SID. If a PCE detects that the SR-RRO 955 subobjects are a mixture of more than one of these types, then it 956 MUST send a PCErr message with Error-Type = 10 ("Reception of an 957 invalid object") and Error-Value = TBD9 ("Inconsistent SIDs in SR-ERO 958 / SR-RRO subobjects"). 960 6. Management Considerations 962 This document adds a new path setup type to PCEP to allow LSPs to be 963 set up using segment routing techniques. This path setup type may be 964 used with PCEP alongside other path setup types, such as RSVP-TE, or 965 it may be used exclusively. 967 6.1. Controlling the Path Setup Type 969 The following factors control which path setup type is used for a 970 given LSP. 972 o The available path setup types are constrained to those that are 973 supported by, or enabled on, the PCEP speakers. The PATH-SETUP- 974 TYPE-CAPABILITY TLV indicates which path setup types a PCEP 975 speaker supports. To use segment routing as a path setup type, it 976 is a prerequisite that the PCC and PCE both include PST=1 in the 977 list of supported path setup types in this TLV, and also include 978 the SR-PCE-CAPABILITY sub-TLV. 980 o When a PCE initiates an LSP, it proposes which path setup type to 981 use by including it in the PATH-SETUP-TYPE TLV in the SRP object 982 of the PCInitiate message. The PCE chooses the path setup type 983 based on the capabilities of the network nodes on the path and on 984 its local policy. The PCC MAY choose to accept the proposed path 985 setup type, or to reject the PCInitiate request, based on its 986 local policy. 988 o When a PCC requests a path for an LSP, it can nominate a preferred 989 path setup type by including it in the PATH-SETUP-TYPE TLV in the 990 RP object of the PCReq message. The PCE MAY choose to reply with 991 a path of the requested type, or to reply with a path of a 992 different type, or to reject the request, based on the 993 capabilities of the network nodes on the path and on its local 994 policy. 996 The operator can influence the path setup type as follows. 998 o Implementations MUST allow the operator to enable and disable the 999 segment routing path setup type on a PCEP-speaking device. 1001 Implementations MAY also allow the operator to enable and disable 1002 the RSVP-TE path setup type. 1004 o PCE implementations MUST allow the operator to specify that an LSP 1005 should be instantiated using segment routing or RSVP-TE as the 1006 proposed path setup type. 1008 o PCE implementations MAY allow the operator to configure a 1009 preference for the PCE to propose paths using segment routing or 1010 RSVP-TE in the absence of a specified path setup type. 1012 o PCC implementations MUST allow the operator to specify that a path 1013 requested for an LSP nominates segment routing or RSVP-TE as the 1014 path setup type. 1016 o PCC implementations MAY allow the operator to configure a 1017 preference for the PCC to nominate segment routing or RSVP-TE as 1018 the path setup type if none is specified for an LSP. 1020 o PCC implementations SHOULD allow the operator to configure a PCC 1021 to refuse to set up an LSP using an undesired path setup type. 1023 6.2. Migrating a Network to Use PCEP Segment Routed Paths 1025 This section discusses the steps that the operator takes when 1026 migrating a network to enable PCEP to set up paths using segment 1027 routing as the path setup type. 1029 o The operator enables the segment routing PST on the PCE servers. 1031 o The operator enables the segment routing PST on the PCCs. 1033 o The operator resets each PCEP session. The PCEP sessions come 1034 back up with segment routing enabled. 1036 o If the operator detects a problem, they can roll the network back 1037 to its initial state by disabling the segment routing PST on the 1038 PCEP speakers and resetting the PCEP sessions. 1040 Note that the data plane is unaffected if a PCEP session is reset. 1041 Any LSPs that were set up before the session reset will remain in 1042 place and will still be present after the session comes back up. 1044 An implementation SHOULD allow the operator to manually trigger a 1045 PCEP session to be reset. 1047 An implementation MAY automatically reset a PCEP session when an 1048 operator reconfigures the PCEP speaker's capabilities. However, note 1049 that if the capabilities at both ends of the PCEP session are not 1050 reconfigured simultaneously, then the session could be reset twice, 1051 which could lead to unnecessary network traffic. Therefore, such 1052 implementations SHOULD allow the operator to override this behaviour 1053 and wait instead for a manual reset. 1055 Once segment routing is enabled on a PCEP session, it can be used as 1056 the path setup type for future LSPs. 1058 User traffic is not automatically migrated from existing LSPs onto 1059 segment routed LSPs just by enabling the segment routing PST in PCEP. 1060 The migration of user traffic from existing LSPs onto segment routing 1061 LSPs is beyond the scope of this document. 1063 6.3. Verification of Network Operation 1065 The operator needs the following information to verify that PCEP is 1066 operating correctly with respect to the segment routing path setup 1067 type. 1069 o An implementation SHOULD allow the operator to view whether the 1070 PCEP speaker sent the segment routing PST capability to its peer. 1071 If the PCEP speaker is a PCC, then the implementation SHOULD also 1072 allow the operator to view the values of the L and N flags that 1073 were sent, and the value of the MSD field that was sent. 1075 o An implementation SHOULD allow the operator to view whether the 1076 peer sent the segment routing PST capability. If the peer is a 1077 PCC, then the implementation SHOULD also allow the operator to 1078 view the values of the L and N flags and MSD fields that the peer 1079 sent. 1081 o An implementation SHOULD allow the operator to view whether the 1082 segment routing PST is enabled on the PCEP session. 1084 o If one PCEP speaker advertises the segment routing PST capability, 1085 but the other does not, then the implementation SHOULD create a 1086 log to inform the operator of the capability mismatch. 1088 o An implementation SHOULD allow the operator to view the PST that 1089 was proposed, or requested, for an LSP, and the PST that was 1090 actually used. 1092 o If a PCEP speaker decides to use a different PST to the one that 1093 was proposed, or requested, for an LSP, then the implementation 1094 SHOULD create a log to inform the operator that the expected PST 1095 has not been used. The log SHOULD give the reason for this choice 1096 (local policy, equipment capability etc.) 1098 o If a PCEP speaker rejects a segment routing path, then it SHOULD 1099 create a log to inform the operator, giving the reason for the 1100 decision (local policy, MSD exceeded etc.) 1102 6.4. Relationship to Existing Management Models 1104 The PCEP YANG module is defined in [I-D.ietf-pce-pcep-yang]. In 1105 future, this YANG module should be extended or augmented to provide 1106 the following additional information relating to segment routing: 1108 o The advertised PST capabilities and MSD per PCEP session. 1110 o The PST configured for, and used by, each LSP. 1112 The PCEP MIB [RFC7420] could also be updated to include this 1113 information. 1115 7. Security Considerations 1117 The security considerations described in [RFC5440], [RFC8231], 1118 [RFC8281] and [RFC8408] are applicable to this specification. No 1119 additional security measure is required. 1121 Note that this specification enables a network controller to 1122 instantiate a path in the network without the use of a hop-by-hop 1123 signaling protocol (such as RSVP-TE). This creates an additional 1124 vulnerability if the security mechanisms of [RFC5440], [RFC8231] and 1125 [RFC8281] are not used. If there is no integrity protection on the 1126 session, then an attacker could create a path which is not subjected 1127 to the further verification checks that would be performed by the 1128 signaling protocol. 1130 Note that this specification adds the MSD field to the OPEN message 1131 (see Section 4.1.2) which discloses how many MPLS labels the sender 1132 can push onto packets that it forwards into the network. If the 1133 security mechanisms of [RFC8231] and [RFC8281] are not used with 1134 strong encryption, then an attacker could use this new field to gain 1135 intelligence about the capabilities of the edge devices in the 1136 network. 1138 8. IANA Considerations 1140 8.1. PCEP ERO and RRO subobjects 1142 This document defines a new subobject type for the PCEP explicit 1143 route object (ERO), and a new subobject type for the PCEP record 1144 route object (RRO). The code points for subobject types of these 1145 objects is maintained in the RSVP parameters registry, under the 1146 EXPLICIT_ROUTE and ROUTE_RECORD objects. IANA is requested to 1147 confirm the early allocation of the following code points in the RSVP 1148 Parameters registry for each of the new subobject types defined in 1149 this document. 1151 Object Subobject Subobject Type 1152 --------------------- -------------------------- ------------------ 1153 EXPLICIT_ROUTE SR-ERO (PCEP-specific) 36 1154 ROUTE_RECORD SR-RRO (PCEP-specific) 36 1156 8.2. New NAI Type Registry 1158 IANA is requested to create a new sub-registry within the "Path 1159 Computation Element Protocol (PCEP) Numbers" registry called "PCEP 1160 SR-ERO NAI Types". The allocation policy for this new registry 1161 should be by IETF Review. The new registry should contain the 1162 following values: 1164 Value Description Reference 1166 0 NAI is absent. This document 1167 1 NAI is an IPv4 node ID. This document 1168 2 NAI is an IPv6 node ID. This document 1169 3 NAI is an IPv4 adjacency. This document 1170 4 NAI is an IPv6 adjacency with This document 1171 global IPv6 addresses. 1172 5 NAI is an unnumbered This document 1173 adjacency with IPv4 node IDs. 1174 6 NAI is an IPv6 adjacency with This document 1175 link-local IPv6 addresses. 1177 8.3. New SR-ERO Flag Registry 1179 IANA is requested to create a new sub-registry, named "SR-ERO Flag 1180 Field", within the "Path Computation Element Protocol (PCEP) Numbers" 1181 registry to manage the Flag field of the SR-ERO subobject. New 1182 values are to be assigned by Standards Action [RFC8126]. Each bit 1183 should be tracked with the following qualities: 1185 o Bit number (counting from bit 0 as the most significant bit) 1187 o Capability description 1189 o Defining RFC 1191 The following values are defined in this document: 1193 Bit Description Reference 1195 0-7 Unassigned 1196 8 NAI is absent (F) This document 1197 9 SID is absent (S) This document 1198 10 SID specifies TC, S This document 1199 and TTL in addition 1200 to an MPLS label (C) 1201 11 SID specifies an MPLS This document 1202 label (M) 1204 8.4. PCEP-Error Object 1206 IANA is requested to confirm the early allocation of the code-points 1207 in the PCEP-ERROR Object Error Types and Values registry for the 1208 following new error-values: 1210 Error-Type Meaning 1211 ---------- ------- 1212 10 Reception of an invalid object. 1214 Error-value = 2: Bad label value 1215 Error-value = 3: Unsupported number 1216 of SR-ERO 1217 subobjects 1218 Error-value = 4: Bad label format 1219 Error-value = 5: ERO mixes SR-ERO 1220 subobjects with 1221 other subobject 1222 types 1223 Error-value = 6: Both SID and NAI 1224 are absent in SR- 1225 ERO subobject 1226 Error-value = 7: Both SID and NAI 1227 are absent in SR- 1228 RRO subobject 1229 Error-value = 9: MSD exceeds the 1230 default for the 1231 PCEP session 1232 Error-value = 10: RRO mixes SR-RRO 1233 subobjects with 1234 other subobject 1235 types 1236 Error-value = TBD1: Missing PCE-SR- 1237 CAPABILITY sub-TLV 1239 Error-value = TBD2: Unsupported NAI 1240 Type in SR-ERO 1241 subobject 1242 Error-value = TBD3: Unknown SID 1243 Error-value = TBD4: NAI cannot be 1244 resolved to a SID 1245 Error-value = TBD5: Could not find SRGB 1246 Error-value = TBD6: SID index exceeds 1247 SRGB size 1248 Error-value = TBD7: Could not find SRLB 1249 Error-value = TBD8: SID index exceeds 1250 SRLB size 1251 Error-value = TBD9: Inconsistent SIDs 1252 in SR-ERO / SR-RRO 1253 subobjects 1254 Error-value = TBD10: MSD must be nonzero 1256 Note to IANA: this draft originally had an early allocation for 1257 Error-value=11 (Malformed object) in the above list. However, we 1258 have since moved the definition of that code point to RFC8408. 1260 Note to IANA: some Error-values in the above list were defined after 1261 the early allocation took place, and so do not currently have a code 1262 point assigned. Please assign code points from the indicated 1263 registry and replace each instance of "TBD1", "TBD2" etc. in this 1264 document with the respective code points. 1266 Note to IANA: some of the Error-value descriptive strings above have 1267 changed since the early allocation. Please refresh the registry. 1269 8.5. PCEP TLV Type Indicators 1271 IANA is requested to confirm the early allocation of the following 1272 code point in the PCEP TLV Type Indicators registry. Note that this 1273 TLV type indicator is deprecated but retained in the registry to 1274 ensure compatibility with early implementations of this 1275 specification. See Appendix A for details. 1277 Value Meaning Reference 1278 ------------------------- ---------------------------- -------------- 1279 26 SR-PCE-CAPABILITY This document 1280 (deprecated) 1282 8.6. PATH-SETUP-TYPE-CAPABILITY Sub-TLV Type Indicators 1284 IANA is requested to create a new sub-registry, named "PATH-SETUP- 1285 TYPE-CAPABILITY Sub-TLV Type Indicators", within the "Path 1286 Computation Element Protocol (PCEP) Numbers" registry to manage the 1287 type indicator space for sub-TLVs of the PATH-SETUP-TYPE-CAPABILITY 1288 TLV. New values are to be assigned by Standards Action [RFC8126]. 1289 The valid range of values in the registry is 0-65535. IANA is 1290 requested to initialize the registry with the following values. All 1291 other values in the registry should be marked as "Unassigned". 1293 Value Meaning Reference 1294 ------------------------- ---------------------------- -------------- 1295 0 Reserved This document 1296 TBD11 (recommended 26) SR-PCE-CAPABILITY This document 1298 Note to IANA: Please replace each instance of "TBD11" in this 1299 document with the allocated code point. We have recommended that 1300 value 26 be used for consistency with the deprecated value in the 1301 PCEP TLV Type Indicators registry. 1303 8.7. New Path Setup Type 1305 [RFC8408] created a sub-registry within the "Path Computation Element 1306 Protocol (PCEP) Numbers" registry called "PCEP Path Setup Types". 1307 IANA is requested to allocate a new code point within this registry, 1308 as follows: 1310 Value Description Reference 1311 ------------------------- ---------------------------- -------------- 1312 1 Traffic engineering path is This document 1313 setup using Segment Routing. 1315 8.8. New Metric Type 1317 IANA is requested to confirm the early allocation of the following 1318 code point in the PCEP METRIC object T field registry: 1320 Value Description Reference 1321 ------------------------- ---------------------------- -------------- 1322 11 Segment-ID (SID) Depth. This document 1324 8.9. SR PCE Capability Flags 1326 IANA is requested to create a new sub-registry, named "SR Capability 1327 Flag Field", within the "Path Computation Element Protocol (PCEP) 1328 Numbers" registry to manage the Flag field of the SR-PCE-CAPABILITY 1329 TLV. New values are to be assigned by Standards Action [RFC8126]. 1330 Each bit should be tracked with the following qualities: 1332 o Bit number (counting from bit 0 as the most significant bit) 1333 o Capability description 1334 o Defining RFC 1335 The following values are defined in this document: 1337 Bit Description Reference 1339 0-5 Unassigned 1340 6 Node or Adjacency This document 1341 Identifier (NAI) is 1342 supported (N) 1343 7 Unlimited Maximum SID This document 1344 Depth (X) 1346 Note to IANA: The name of bit 7 has changed from "Unlimited Maximum 1347 SID Depth (L)" to "Unlimited Maximum SID Depth (X)". 1349 9. Contributors 1351 The following people contributed to this document: 1353 - Lakshmi Sharma 1354 - Jan Medved 1355 - Edward Crabbe 1356 - Robert Raszuk 1357 - Victor Lopez 1359 10. Acknowledgements 1361 We thank Ina Minei, George Swallow, Marek Zavodsky, Dhruv Dhody, Ing- 1362 Wher Chen and Tomas Janciga for the valuable comments. 1364 11. References 1366 11.1. Normative References 1368 [I-D.ietf-spring-segment-routing-mpls] 1369 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., 1370 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 1371 data plane", draft-ietf-spring-segment-routing-mpls-18 1372 (work in progress), December 2018. 1374 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1375 Requirement Levels", BCP 14, RFC 2119, 1376 DOI 10.17487/RFC2119, March 1997, 1377 . 1379 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 1380 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 1381 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 1382 . 1384 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1385 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 1386 DOI 10.17487/RFC5440, March 2009, 1387 . 1389 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1390 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1391 May 2017, . 1393 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 1394 Computation Element Communication Protocol (PCEP) 1395 Extensions for Stateful PCE", RFC 8231, 1396 DOI 10.17487/RFC8231, September 2017, 1397 . 1399 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 1400 Computation Element Communication Protocol (PCEP) 1401 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 1402 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 1403 . 1405 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1406 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1407 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1408 July 2018, . 1410 [RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J. 1411 Hardwick, "Conveying Path Setup Type in PCE Communication 1412 Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408, 1413 July 2018, . 1415 [RFC8491] Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg, 1416 "Signaling Maximum SID Depth (MSD) Using IS-IS", RFC 8491, 1417 DOI 10.17487/RFC8491, November 2018, 1418 . 1420 11.2. Informative References 1422 [I-D.ietf-6man-segment-routing-header] 1423 Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and 1424 d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header 1425 (SRH)", draft-ietf-6man-segment-routing-header-16 (work in 1426 progress), February 2019. 1428 [I-D.ietf-idr-bgp-ls-segment-routing-msd] 1429 Tantsura, J., Chunduri, U., Mirsky, G., and S. Sivabalan, 1430 "Signaling MSD (Maximum SID Depth) using Border Gateway 1431 Protocol Link-State", draft-ietf-idr-bgp-ls-segment- 1432 routing-msd-02 (work in progress), August 2018. 1434 [I-D.ietf-isis-segment-routing-extensions] 1435 Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., 1436 Gredler, H., and B. Decraene, "IS-IS Extensions for 1437 Segment Routing", draft-ietf-isis-segment-routing- 1438 extensions-22 (work in progress), December 2018. 1440 [I-D.ietf-ospf-segment-routing-extensions] 1441 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 1442 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 1443 Extensions for Segment Routing", draft-ietf-ospf-segment- 1444 routing-extensions-27 (work in progress), December 2018. 1446 [I-D.ietf-pce-pcep-yang] 1447 Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A 1448 YANG Data Model for Path Computation Element 1449 Communications Protocol (PCEP)", draft-ietf-pce-pcep- 1450 yang-09 (work in progress), October 2018. 1452 [I-D.ietf-spring-segment-routing-policy] 1453 Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d., 1454 bogdanov@google.com, b., and P. Mattes, "Segment Routing 1455 Policy Architecture", draft-ietf-spring-segment-routing- 1456 policy-02 (work in progress), October 2018. 1458 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1459 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1460 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 1461 . 1463 [RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation 1464 Element (PCE) Communication Protocol Generic 1465 Requirements", RFC 4657, DOI 10.17487/RFC4657, September 1466 2006, . 1468 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 1469 Hardwick, "Path Computation Element Communication Protocol 1470 (PCEP) Management Information Base (MIB) Module", 1471 RFC 7420, DOI 10.17487/RFC7420, December 2014, 1472 . 1474 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1475 Writing an IANA Considerations Section in RFCs", BCP 26, 1476 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1477 . 1479 [RFC8413] Zhuang, Y., Wu, Q., Chen, H., and A. Farrel, "Framework 1480 for Scheduled Use of Resources", RFC 8413, 1481 DOI 10.17487/RFC8413, July 2018, 1482 . 1484 [RFC8476] Tantsura, J., Chunduri, U., Aldrin, S., and P. Psenak, 1485 "Signaling Maximum SID Depth (MSD) Using OSPF", RFC 8476, 1486 DOI 10.17487/RFC8476, December 2018, 1487 . 1489 Appendix A. Compatibility with Early Implementations 1491 An early implementation of this specification will send the SR- 1492 CAPABILITY-TLV as a top-level TLV in the OPEN object instead of 1493 sending the PATH-SETUP-TYPE-CAPABILITY TLV in the OPEN object. 1494 Implementations that wish to interoperate with such early 1495 implementations should also send the SR-CAPABILITY-TLV as a top-level 1496 TLV in their OPEN object and should interpret receiving this top- 1497 level TLV as though the sender had sent a PATH-SETUP-TYPE-CAPABILITY 1498 TLV with a PST list of (0, 1) (that is, both RSVP-TE and SR-TE PSTs 1499 are supported) with the SR-CAPABILITY-TLV as a sub-TLV. If a PCEP 1500 speaker receives an OPEN object in which both the SR-CAPABILITY-TLV 1501 and PATH-SETUP-TYPE-CAPABILITY TLV appear as top-level TLVs, then it 1502 should ignore the top-level SR-CAPABILITY-TLV and process only the 1503 PATH-SETUP-TYPE-CAPABILITY TLV. 1505 Authors' Addresses 1507 Siva Sivabalan 1508 Cisco Systems, Inc. 1509 2000 Innovation Drive 1510 Kanata, Ontario K2K 3E8 1511 Canada 1513 Email: msiva@cisco.com 1514 Clarence Filsfils 1515 Cisco Systems, Inc. 1516 Pegasus Parc 1517 De kleetlaan 6a, DIEGEM BRABANT 1831 1518 BELGIUM 1520 Email: cfilsfil@cisco.com 1522 Jeff Tantsura 1523 Apstra, Inc. 1524 333 Middlefield Rd #200 1525 Menlo Park, CA 94025 1526 USA 1528 Email: jefftant.ietf@gmail.com 1530 Wim Henderickx 1531 Nokia 1532 Copernicuslaan 50 1533 Antwerp 2018, CA 95134 1534 BELGIUM 1536 Email: wim.henderickx@alcatel-lucent.com 1538 Jon Hardwick 1539 Metaswitch Networks 1540 100 Church Street 1541 Enfield, Middlesex 1542 UK 1544 Email: jonathan.hardwick@metaswitch.com