idnits 2.17.1 draft-rodrigueznatal-lisp-srv6-04.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 document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 26, 2020) is 1367 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-13) exists of draft-ietf-lisp-eid-mobility-06 == Outdated reference: A later version (-15) exists of draft-ietf-lisp-pubsub-06 == Outdated reference: A later version (-31) exists of draft-ietf-lisp-rfc6833bis-27 == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-16 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LISP Working Group A. Rodriguez-Natal 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Experimental V. Ermagan 5 Expires: January 27, 2021 Google 6 F. Maino 7 D. Dukes 8 P. Camarillo 9 C. Filsfils 10 Cisco Systems, Inc. 11 July 26, 2020 13 LISP Control Plane for SRv6 Endpoint Mobility 14 draft-rodrigueznatal-lisp-srv6-04 16 Abstract 18 This document describes the use of the LISP Control Plane to support 19 endpoint mobility and Location/ID separation in Segment Routing v6 20 (SRv6) deployments. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on January 27, 2021. 39 Copyright Notice 41 Copyright (c) 2020 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3.1. Provisioning . . . . . . . . . . . . . . . . . . . . . . 4 60 3.2. Endpoint Registration . . . . . . . . . . . . . . . . . . 5 61 3.3. Endpoint Resolution . . . . . . . . . . . . . . . . . . . 6 62 3.4. SR Policy Resolution . . . . . . . . . . . . . . . . . . 6 63 3.4.1. Decentralized . . . . . . . . . . . . . . . . . . . . 7 64 3.4.2. Centralized . . . . . . . . . . . . . . . . . . . . . 7 65 3.5. Traffic Encapsulation . . . . . . . . . . . . . . . . . . 8 66 3.6. Endpoint Mobility . . . . . . . . . . . . . . . . . . . . 9 67 4. Segment Routing LCAF (SR LCAF) . . . . . . . . . . . . . . . 9 68 4.1. SR-MPLS . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 4.2. SRv6 . . . . . . . . . . . . . . . . . . . . . . . . . . 11 70 4.3. Traffic Steering Tag . . . . . . . . . . . . . . . . . . 12 71 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 72 5.1. Normative References . . . . . . . . . . . . . . . . . . 12 73 5.2. Informative References . . . . . . . . . . . . . . . . . 13 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 76 1. Introduction 78 This document defines how to use the LISP Control Plane 79 [I-D.ietf-lisp-rfc6833bis] to support endpoint mobility and Location/ 80 ID separation in those IPv6 deployments that are using SRv6 Network 81 Programming [I-D.ietf-spring-srv6-network-programming]. The LISP 82 control plane is used to lookup "where" an endpoint is located, while 83 SRv6 specifies "how" to program the SRv6 network infrastructure to 84 transport traffic to that location. 86 To enable this, the egress Provider Edge (PE) nodes register via LISP 87 control plane their local SRv6 Segment IDs (SIDs) to be used to reach 88 endpoints attached to them. Ingress PE nodes retrieve via LISP 89 control plane this mapping information, and use SRv6 network 90 programming to encapsulate and steer the traffic towards the 91 destination egress PE node. 93 The LISP control plane provides on-demand endpoint-to-SID mapping, as 94 well as support for anchorless dynamic endpoint mobility. 96 2. Overview 98 The ingress PE nodes receive traffic from endpoints in their local 99 networks, encapsulate it in IPv6 packets following SRv6 policies and 100 forward it to the SRv6 domain. Similarly, egress PE nodes receive 101 SRv6 traffic from the SRv6 domain, remove the SRv6 encapsulation and 102 forward the traffic to one of their locally attached networks 103 according to the decapsulation SID received in the packets. Ingress 104 PE nodes and egress PE nodes can be co-located in the same node, in 105 this document we use "PE node" to refer to those collocated nodes. 107 This specification leverages the LISP Mapping System to store 108 mappings of endpoints to decapsulation SIDs. Endpoints are neither 109 LISP nor SRv6 aware and can roam freely across different PE nodes. 110 The mappings in the LISP Mapping System can be used by PE nodes to 111 know to which PE node an endpoint is currently connected. The LISP 112 Mapping System is composed of LISP Map-Resolvers and Map-Servers but, 113 for convenience, this document refers to the Mapping System as a 114 single logical entity. 116 To use the LISP Mapping System, in this specification the PE nodes 117 also implement the control-plane logic of LISP Ingress/Egress Tunnel 118 Routers (xTRs). As a LISP xTR, a PE node keeps a local database of 119 all the endpoints that are attached to its local network(s). It also 120 keeps a list of local decapsulation function SIDs that map to each of 121 its local network(s). A PE node registers into the LISP Mapping 122 System its local endpoint-to-SID mappings. These mappings also 123 contain the traffic steering tag associated with the endpoint. In 124 addition to its local mappings, a PE node also keeps a local map- 125 cache of remote endpoint-to-SID mappings that it uses to find the SID 126 to use to encapsulate traffic towards a remote endpoint. 128 This specification also assumes an SR Path Computation Element (PCE) 129 [RFC4655] that can compute and provide SRv6 paths from a given 130 ingress PE node to a given egress PE node. The paths are based on 131 the ingress and egress PE nodes and on the traffic steering tag that 132 is associated with the destination endpoint. Figure 1 shows an 133 example diagram to be used as a reference for the architecture 134 described in this document. 136 +----------+ +----------------+ 137 | | | LISP | 138 | SR PCE | | Mapping System | 139 | | | | 140 +----------+ +----------------+ 142 XXXXXXXXXXXXXXXXXXXXXXXXX 143 XXX XXX 144 XX XX 145 +------+ +------+ +----+-+ +------+ 146 | UE A +----+ PE 1 | SRv6 Network | PE 2 +------+ UE B | 147 +------+ +------+ +------+ +------+ 148 XX XX 149 XXX XXX 150 XXXXXXXXXXXXXXXXXXXXXXXXX 152 Figure 1: Reference Architecture 154 3. Operation 156 3.1. Provisioning 158 Each PE node is connected to the SRv6 domain and to one or more local 159 networks. These local networks may represent different tenants/VPNs. 160 Each tenant network is globally identified via a unique Instance 161 Identifier (IID). Locally, these tenant networks are identified at 162 each PE node by the local IP table assigned to them. While the IID 163 for a tenant network is global across the domain, the local IP table 164 assigned to it in a given PE node is local to that PE node. Each PE 165 node needs to be provisioned with the one-to-one mapping of global 166 IID to local IP table per each tenant network it is serving. The 167 provisioning of the IID to the local IP table is out of the scope of 168 this document. PE nodes use this IID to local IP table information 169 to know which IID they need to use when requesting mappings for 170 traffic coming from a particular tenant network (i.e. from a 171 particular local IP table). 173 Per each local IP table, each PE node has a local SRv6 "End.DT46" 174 function (see [I-D.ietf-spring-srv6-network-programming]) that 175 decapsulates SRv6 traffic and forwards the inner traffic for lookup 176 into that particular IP table. The PE node concatenates one of its 177 local SRv6 locators with each of these decapsulation functions to 178 create SIDs that point to each of the different tenant networks it is 179 serving. These SIDs are kept onto the "My local SIDs table" of the 180 PE node and they are used to decapsulate incoming SRv6 traffic into 181 the appropriate local IP table. 183 Beyond SRv6 state, each PE node has to be provisioned with the 184 address of at least one Map-Resolver it will use to retrieve remote 185 endpoint-to-SID mappings from the Mapping System. Similarly, it has 186 to be provisioned with the address of the Map-Server to which it is 187 going to register their local endpoint-to-SID mappings. 189 3.2. Endpoint Registration 191 Endpoints attach to the local networks served by PE nodes. Upon 192 attachment of an endpoint, the PE node will correlate the local IP 193 table that corresponds to the local network where the endpoint 194 attached to a global IID. It does so by using its local information 195 of global IID to local IP table. The local IP table also correlates 196 with the local SID that remote PE nodes need to use to send SRv6 197 encapsulated traffic towards the endpoint. The local SID directly 198 translates into which local IP table the PE node should use to lookup 199 for the endpoint when receiving traffic for it. 201 It should be noted that the endpoint does not need to attach to the 202 PE node directly (i.e. it can attach to another network device 203 downlink) as long as the PE node is notified (e.g. via off-band 204 orchestration) of the following: 206 o Which endpoint has been attached (i.e. Endpoint EID) 208 o Which tenant network (if any) the endpoint belongs to (i.e. 209 Endpoint IID) 211 For this version of the specification, it is assumed that the 212 endpoint only attaches to a single PE node and that all traffic 213 steering will be handled by SRv6. Therefore, for this version of the 214 specification, a PE only register one SID per endpoint (or group of 215 endpoints) into the Mapping System. Future versions of this 216 specification will describe how to an endpoint can be served by more 217 than one PE node and/or by more than one SID per PE node. 219 For SRv6 operation, endpoints need to be associated with a particular 220 tag to be used for traffic steering policies. This means that the 221 traffic addressed towards the endpoint may need to be steered through 222 a particular path in the SRv6 domain. This draft assumes that a PE 223 node knows the tag associated to endpoints attached to the local 224 networks it is serving. How a PE node knows which tag corresponds to 225 a particular endpoint is out of the scope of this document. In 226 addition to the endpoint tag, to compute the path through the SRv6 227 network the loopback address of the egress PE node is also used. 229 Therefore, to make all this information available to the LISP-SRv6 230 deployment, the PE node will register into the Mapping System the 231 mapping of endpoint address and IID to endpoint's tag, PE node local 232 SID and PE node loopback. To do so, the egress PE node will send a 233 Map-Register as specified in [I-D.ietf-lisp-rfc6833bis] with the 234 appropriate IID and endpoint address as EID. The endpoint's tag, the 235 PE node local SID and the PE node loopback are encoded using the SR 236 LCAF described in Section 4 as an RLOC in the Map-Register. 238 3.3. Endpoint Resolution 240 When a PE node needs to encapsulate traffic from a local endpoint 241 towards a remote endpoint served by a remote PE node, it looks up in 242 its map-cache to find the appropriate destination SID (and SR policy) 243 to use to reach the remote endpoint. This lookup takes into 244 consideration the local IP table serving the local endpoint (i.e the 245 IID of the mapping). If no entry is found for that remote endpoint, 246 the PE node has to retrieve it from the Mapping System. To do so, it 247 follows the procedures described in [I-D.ietf-lisp-rfc6833bis] and 248 sends a Map-Request towards the Mapping System. In the Map-Request 249 the PE node encodes its loopback address as ITR RLOC and as 250 destination EID the address of the remote endpoint for which a 251 destination SID is needed. It uses the IID associated with the local 252 IP table serving the local endpoint that triggered the request. 254 What the Mapping System replies via a Map-Reply depends on how the SR 255 policy is resolved. The Mapping System can reply with either the 256 destination SID only (along with egress PE loopback address and 257 endpoint tag) or with the complete SID list to be applied in the SRv6 258 underlay. This two options are discussed in detail in Section 3.4. 259 Note that the Map-Reply may return a prefix as returned EID, which 260 means all the endpoints within the prefix can be reached through the 261 same SID. Optionally, the PE node can request to also be subscribed 262 to updates in the endpoint(s) mapping following 263 [I-D.ietf-lisp-pubsub]. 265 Alternatively, it is also possible for a PE node to subscribe in 266 advance for endpoint(s) mappings for a set (or sets) of endpoint 267 EIDs. That way the map-cache will be pre-populated for those 268 destination endpoint(s), avoiding the need for an on-demand Map- 269 Request/Map-Reply. This optimization is at the cost of keeping more 270 state in the PE node and Mapping System. 272 3.4. SR Policy Resolution 274 Besides retrieving the destination SID for a remote endpoint, a PE 275 node also needs to find a suitable SR policy to send the traffic 276 towards the destination SID through the SRv6 underlay. The 277 architecture discussed in this document offers different options to 278 make the SR policy available at the PE node. 280 3.4.1. Decentralized 282 +----------+ +----------------+ 283 | | | LISP | 284 | SR PCE | | Mapping System | 285 | | | | 286 +----------+ +----------------+ 287 | | | 288 | | | 289 | +-----------------------+ | 290 | | | 291 | | XXXXXXXXXXXXXXXXXXXXXXXXX | 292 | | XXX XXX | 293 | | XX XX | 294 +------+ +------+ +------+ +------+ 295 | UE A +----+ PE 1 | SRv6 Network | PE 2 +------+ UE B | 296 +------+ +------+ +------+ +------+ 297 XX XX 298 XXX XXX 299 XXXXXXXXXXXXXXXXXXXXXXXXX 301 Figure 2: Decentralized SR Policy Resolution 303 With the decentralized approach, the SR policies are resolved 304 independently of the endpoint resolution. In this case, the Mapping 305 System will reply to the ingress PE node that sent the Map-Request 306 with a Map-Reply carrying the SR LCAF described in Section 4 as RLOC. 307 This SR LCAF contains the destination SID, egress PE loopback 308 address, and endpoint's tag for the requested endpoint. The ingress 309 PE will then use the loopback of the egress PE along with the tag 310 associated with the endpoint to request a path to the SR PCE 311 component via [RFC5440]. The SR PCE will return an SR policy (i.e. a 312 SID list) to the ingress PE node for that egress PE node and 313 endpoint's traffic steering tag. The ingress PE node will use that 314 SID list received from the SR PCE (along with the destination SID 315 retrieved from the LISP Mapping System) when encapsulating SRv6 316 traffic towards the endpoint. 318 3.4.2. Centralized 319 +----------+ +----------------+ 320 | | | LISP | 321 | SR PCE |------------| Mapping System | 322 | | | | 323 +----------+ +----------------+ 324 | | 325 | | 326 +-----------------------+ | 327 | | 328 | XXXXXXXXXXXXXXXXXXXXXXXXX | 329 | XXX XXX | 330 | XX XX | 331 +------+ +------+ +----+-+ +------+ 332 | UE A +----+ PE 1 | SRv6 Network | PE 2 +------+ UE B | 333 +------+ +------+ +------+ +------+ 334 XX XX 335 XXX XXX 336 XXXXXXXXXXXXXXXXXXXXXXXXX 338 Figure 3: Centralized SR Policy Resolution 340 With the centralized approach the SR policies are resolved at the 341 Mapping System when the mapping is requested by the PE node. Upon 342 receiving a Map-Request for an endpoint from a PE node, the Mapping 343 System queries the SR PCE to find the SR policy using [RFC5440]. To 344 query the SR PCE, the Mapping System uses the ingress and egress PE 345 nodes loopback addresses and the traffic steering tag of the 346 requested endpoint. The Mapping System obtains the loopback address 347 of the ingress PE node from the ITR-RLOC field of the Map-Request. 348 In this case, the Mapping System returns not only the destination SID 349 of the remote endpoint, but also the rest of the SIDs that the 350 traffic has to go through from the ingress PE node to the egress PE 351 node. The SR policy SID list along with the destination egress PE 352 node decapsulation SID are encoded as an Explicit Locator Path (ELP) 353 [RFC8060] in the Map-Reply returned. The ingress PE node can 354 directly use this ELP to build the SRv6 packets and does not need to 355 query the PCE to obtain the SR policy. 357 3.5. Traffic Encapsulation 359 Once the destination SID and SR policy for a given endpoint EID are 360 known by a PE node, the PE node will use this information to build 361 the Segment Routing Header (SRH), if needed, and encapsulate the 362 traffic through the SRv6 domain towards the egress PE node. Note 363 that if there is no SR policy for a particular endpoint, no SRH is 364 needed and the packets can be encapsulated using a vanilla IPv6 365 header with the destination SID as destination address. This follows 366 common SRv6 operation as specified in 367 [I-D.ietf-spring-srv6-network-programming]. 369 When the SRv6 traffic reaches the destination, the destination SID 370 points to the local IP table where the decapsulated traffic has to be 371 delivered. Once decapsulated, the traffic will be routed towards the 372 intended endpoint via lookup in that local IP table. 374 3.6. Endpoint Mobility 376 LISP-SRv6 deployment relies on the LISP mechanisms defined in 377 [I-D.ietf-lisp-eid-mobility] to support mobility of endpoints. 378 Following that specification, when a PE node registers an endpoint 379 mapping, the previous PE node that had registered a mapping for the 380 same endpoint will be notified. This serves to (1) notify the former 381 egress PE node for the endpoint that the endpoint has moved and (2) 382 to let former PE node know the new egress PE node for the endpoint. 383 Once the former PE node receives the notification, it (1) stops 384 registrations for the endpoint, (2) re-encapsulates any traffic 385 received for the endpoint towards the new egress PE node, and (3) 386 sends a Solicit-Map-Request message to any ingress PE node from which 387 it receives traffic for the endpoint to let them know that they 388 should trigger a Map-Request to update their map-caches. 390 In addition, if the Mapping System supports the Publish/Subscribe 391 mechanisms described in [I-D.ietf-lisp-pubsub], a PE node can ask the 392 Mapping System to be notified of changes in the mapping for a 393 particular destination endpoint when it requests the mapping. This 394 way a PE node subscribed to a particular endpoint will receive a 395 mapping update with the new destination SID for the endpoint whenever 396 the endpoint moves to a new PE node. 398 4. Segment Routing LCAF (SR LCAF) 400 The following Segment Routing LISP Canonical Address Format (SR LCAF) 401 [RFC8060] is introduced to support the operation of LISP-SR 402 deployments. 404 0 1 2 3 405 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 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | AFI = 16387 | Rsvd1 | Flags | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | Type = SR | SR-Type | Length | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 Figure 4: Segment Routing LCAF 414 The SR LCAF defines the SR-Type field to indicate the type of Segment 415 Routing and the specific format of the SR LCAF. The following values 416 are defined: 418 0: Reserved 420 1: SR-MPLS 422 2: SRv6 424 For definitions of the rest of the LCAF fields please refer to 425 [RFC8060]. 427 4.1. SR-MPLS 429 When the SR-Type is SR-MPLS (SR-Type = 1) the SR LCAF has the 430 following format: 432 0 1 2 3 433 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 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 | AFI = 16387 | Rsvd1 | Flags | 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | Type = SR | SR-Type = 1 | Length | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | Rsvd3 | MPLS label | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | Tag Type | Tag Flags | Traffic Steering Tag ... 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | AFI = x | SR Next Hop ... 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 Figure 5: SR-MPLS Segment Routing LCAF 448 The SR-MPLS SR LCAF defines the following fields: 450 MPLS label: MPLS VPN label associated with the EID. 452 Tag Type: Type of traffic steering tag associated with the EID. 453 Details on this traffic steering tag and different Tag Types are 454 discussed in Section 4.3. 456 Tag Flags: Flags for the particular type of traffic steering tag 457 associated with the EID. 459 Traffic Steering Tag: Tag associated with the EID that is used to 460 compute SR paths. 462 SR Next Hop: Loopback address of the egress PE node associated 463 with the EID. 465 4.2. SRv6 467 When the SR-Type is SR-SRv6 (SR-Type = 2) the SR LCAF has the 468 following format: 470 0 1 2 3 471 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 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 | AFI = 16387 | Rsvd1 | Flags | 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 | Type = SR | SR-Type = 2 | Length | 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 | | 478 | | 479 | SRv6-VPN-SID | 480 | | 481 | (128 bits) | 482 | | 483 | | 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 | Tag Type | Tag Flags | Traffic Steering Tag ... 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | AFI = x | SR Next Hop ... 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 Figure 6: SRv6 Segment Routing LCAF 492 The SRv6 SR LCAF defines the following fields: 494 SRv6-VPN-SID: The SRv6 VPN SID associated with the EID. 496 See Section 4.1 for definitions of the rest of the fields of the SRv6 497 SR LCAF. 499 4.3. Traffic Steering Tag 501 The SR LCAF supports different traffic steering tags to be associated 502 with the EID and be used in the operation of the SR deployment. The 503 following values are defined for the Tag Type field: 505 0: No tag. When the Tag Type is 0 the Tag Flags are 0 and the Tag 506 field has length of 0 octets. 508 1: Color. When the Tag Type is 0 the Tag Flags and Tag field have 509 the following format. 511 0 1 2 3 512 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 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 | Tag Type = 1 | Rsvd4 |C|O| Color ... | 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 | ... Color ... | 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 | ... Color | 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 Figure 7: Color Tag 523 2: Slice. The tag format and flags for this Tag Type are to be 524 defined in future versions of this document. 526 5. References 528 5.1. Normative References 530 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 531 Element (PCE)-Based Architecture", RFC 4655, 532 DOI 10.17487/RFC4655, August 2006, 533 . 535 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 536 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 537 DOI 10.17487/RFC5440, March 2009, 538 . 540 [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 541 Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, 542 February 2017, . 544 5.2. Informative References 546 [I-D.ietf-lisp-eid-mobility] 547 Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino, 548 F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a 549 Unified Control Plane", draft-ietf-lisp-eid-mobility-06 550 (work in progress), May 2020. 552 [I-D.ietf-lisp-pubsub] 553 Rodriguez-Natal, A., Ermagan, V., Cabellos-Aparicio, A., 554 Barkai, S., and M. Boucadair, "Publish/Subscribe 555 Functionality for LISP", draft-ietf-lisp-pubsub-06 (work 556 in progress), July 2020. 558 [I-D.ietf-lisp-rfc6833bis] 559 Farinacci, D., Maino, F., Fuller, V., and A. Cabellos- 560 Aparicio, "Locator/ID Separation Protocol (LISP) Control- 561 Plane", draft-ietf-lisp-rfc6833bis-27 (work in progress), 562 January 2020. 564 [I-D.ietf-spring-srv6-network-programming] 565 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 566 Matsushima, S., and Z. Li, "SRv6 Network Programming", 567 draft-ietf-spring-srv6-network-programming-16 (work in 568 progress), June 2020. 570 Authors' Addresses 572 Alberto Rodriguez-Natal 573 Cisco Systems, Inc. 574 United States of America 576 Email: natal@cisco.com 578 Vina Ermagan 579 Google 580 United States of America 582 Email: ermagan@gmail.com 583 Fabio Maino 584 Cisco Systems, Inc. 585 United States of America 587 Email: fmaino@cisco.com 589 Darren Dukes 590 Cisco Systems, Inc. 591 Canada 593 Email: ddukes@cisco.com 595 Pablo Camarillo 596 Cisco Systems, Inc. 597 Spain 599 Email: pcamaril@cisco.com 601 Clarence Filsfils 602 Cisco Systems, Inc. 603 Belgium 605 Email: cf@cisco.com