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