idnits 2.17.1 draft-xuclad-spring-sr-service-programming-01.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 both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 1127: '...e defined in this document. SHOULD be...' RFC 2119 keyword, line 1128: '...transmission and MUST be ignored on re...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 22, 2018) is 1984 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 1021 == Missing Reference: 'SL' is mentioned on line 1023, but not defined == Outdated reference: A later version (-07) exists of draft-filsfils-spring-srv6-network-programming-05 == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-14 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-14 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-01 == Outdated reference: A later version (-09) exists of draft-filsfils-spring-sr-policy-considerations-02 == Outdated reference: A later version (-07) exists of draft-ietf-mpls-sfc-03 == Outdated reference: A later version (-09) exists of draft-xu-mpls-payload-protocol-identifier-05 Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING F. Clad, Ed. 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Standards Track X. Xu, Ed. 5 Expires: April 25, 2019 Alibaba 6 C. Filsfils 7 Cisco Systems, Inc. 8 D. Bernier 9 Bell Canada 10 C. Li 11 Huawei 12 B. Decraene 13 Orange 14 S. Ma 15 Juniper 16 C. Yadlapalli 17 AT&T 18 W. Henderickx 19 Nokia 20 S. Salsano 21 Universita di Roma "Tor Vergata" 22 October 22, 2018 24 Service Programming with Segment Routing 25 draft-xuclad-spring-sr-service-programming-01 27 Abstract 29 This document defines data plane functionality required to implement 30 service segments and achieve service programming in SR-enabled MPLS 31 and IP networks, as described in the Segment Routing architecture. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on April 25, 2019. 50 Copyright Notice 52 Copyright (c) 2018 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3. Classification and steering . . . . . . . . . . . . . . . . . 4 70 4. Service segments . . . . . . . . . . . . . . . . . . . . . . 5 71 4.1. SR-aware services . . . . . . . . . . . . . . . . . . . . 5 72 4.2. SR-unaware services . . . . . . . . . . . . . . . . . . . 6 73 5. SR service policies . . . . . . . . . . . . . . . . . . . . . 7 74 5.1. SR-MPLS data plane . . . . . . . . . . . . . . . . . . . 8 75 5.2. SRv6 data plane . . . . . . . . . . . . . . . . . . . . . 10 76 6. SR proxy behaviors . . . . . . . . . . . . . . . . . . . . . 11 77 6.1. Static SR proxy . . . . . . . . . . . . . . . . . . . . . 14 78 6.1.1. SR-MPLS pseudocode . . . . . . . . . . . . . . . . . 16 79 6.1.2. SRv6 pseudocode . . . . . . . . . . . . . . . . . . . 17 80 6.2. Dynamic SR proxy . . . . . . . . . . . . . . . . . . . . 19 81 6.2.1. SR-MPLS pseudocode . . . . . . . . . . . . . . . . . 19 82 6.2.2. SRv6 pseudocode . . . . . . . . . . . . . . . . . . . 20 83 6.3. Shared memory SR proxy . . . . . . . . . . . . . . . . . 21 84 6.4. Masquerading SR proxy . . . . . . . . . . . . . . . . . . 21 85 6.4.1. SRv6 masquerading proxy pseudocode . . . . . . . . . 22 86 6.4.2. Variant 1: Destination NAT . . . . . . . . . . . . . 23 87 6.4.3. Variant 2: Caching . . . . . . . . . . . . . . . . . 23 88 7. Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . 23 89 7.1. MPLS data plane . . . . . . . . . . . . . . . . . . . . . 23 90 7.2. IPv6 data plane . . . . . . . . . . . . . . . . . . . . . 24 91 7.2.1. SRH TLV objects . . . . . . . . . . . . . . . . . . . 24 92 7.2.2. SRH tag . . . . . . . . . . . . . . . . . . . . . . . 25 93 8. Implementation status . . . . . . . . . . . . . . . . . . . . 25 94 8.1. SR-aware services . . . . . . . . . . . . . . . . . . . . 26 95 8.2. Proxy behaviors . . . . . . . . . . . . . . . . . . . . . 26 96 9. Related works . . . . . . . . . . . . . . . . . . . . . . . . 26 97 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 98 10.1. SRv6 Endpoint Behaviors . . . . . . . . . . . . . . . . 27 99 10.2. Segment Routing Header TLVs . . . . . . . . . . . . . . 27 100 11. Security Considerations . . . . . . . . . . . . . . . . . . . 27 101 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 102 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 28 103 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 104 14.1. Normative References . . . . . . . . . . . . . . . . . . 28 105 14.2. Informative References . . . . . . . . . . . . . . . . . 29 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 108 1. Introduction 110 Segment Routing (SR) is an architecture based on the source routing 111 paradigm that seeks the right balance between distributed 112 intelligence and centralized programmability. SR can be used with an 113 MPLS or an IPv6 data plane to steer packets through an ordered list 114 of instructions, called segments. These segments may encode simple 115 routing instructions for forwarding packets along a specific network 116 path, but also steer them through VNFs or physical service appliances 117 available in the network. 119 In an SR network, each of these services, running either on a 120 physical appliance or in a virtual environment, are associated with a 121 segment identifier (SID). These service SIDs are then leveraged as 122 part of a SID-list to steer packets through the corresponding 123 services. Service SIDs may be combined together in a SID-list to 124 achieve service programming, but also with other types of segments as 125 defined in [RFC8402]. SR thus provides a fully integrated solution 126 for overlay, underlay and service programming. Furthermore, the IPv6 127 instantiation of SR (SRv6) supports metadata transportation in the 128 Segment Routing header [I-D.ietf-6man-segment-routing-header], either 129 natively in the tag field or with extensions such as TLVs. 131 This document describes how a service can be associated with a SID, 132 including legacy services with no SR capabilities, and how these 133 service SIDs are integrated within an SR policy. The definition of 134 an SR Policy and the traffic steering mechanisms are covered in 135 [I-D.ietf-spring-segment-routing-policy] and hence outside the scope 136 of this document. 138 The definition of control plane components, such as service segment 139 discovery, is outside the scope of this data plane document. For 140 reference, the option of using BGP extensions to support SR service 141 programming is proposed in [I-D.dawra-idr-bgp-sr-service-chaining]. 143 2. Terminology 145 This document leverages the terminology proposed in [RFC8402] and 146 [I-D.ietf-spring-segment-routing-policy]. It also introduces the 147 following new terms. 149 Service segment: A segment associated with a service. The service 150 may either run on a physical appliance or in a virtual environment 151 such as a virtual machine or container. 153 SR-aware service: A service that is fully capable of processing SR 154 traffic. An SR-aware service can be directly associated with a 155 service segment. 157 SR-unaware service: A service that is unable to process SR traffic or 158 may behave incorrectly due to presence of SR information in the 159 packet headers. An SR-unaware service can be associated with a 160 service segment through an SR proxy function. 162 3. Classification and steering 164 Classification and steering mechanisms are defined in section 8 of 165 [I-D.ietf-spring-segment-routing-policy] and are independent from the 166 purpose of the SR policy. From the perspective of a headend node 167 classifying and steering traffic into an SR policy, there is no 168 difference whether this policy contains IGP, BGP, peering, VPN or 169 service segments, or any combination of these. 171 As documented in the above reference, traffic is classified when 172 entering an SR domain. The SR policy headend may, depending on its 173 capabilities, classify the packets on a per-destination basis, via 174 simple FIB entries, or apply more complex policy routing rules 175 requiring to look deeper into the packet. These rules are expected 176 to support basic policy routing such as 5-tuple matching. In 177 addition, the IPv6 SRH tag field defined in 178 [I-D.ietf-6man-segment-routing-header] can be used to identify and 179 classify packets sharing the same set of properties. Classified 180 traffic is then steered into the appropriate SR policy and forwarded 181 as per the SID-list(s) of the active candidate path. 183 SR traffic can be re-classified by an SR endpoint along the original 184 SR policy (e.g., DPI service) or a transit node intercepting the 185 traffic. This node is the head-end of a new SR policy that is 186 imposed onto the packet, either as a stack of MPLS labels or as an 187 IPv6 SRH. 189 4. Service segments 191 In the context of this document, the term service refers to a 192 physical appliance running on dedicated hardware, a virtualized 193 service inside an isolated environment such as a VM, container or 194 namespace, or any process running on a compute element. A service 195 may also comprise multiple sub-components running in different 196 processes or containers. Unless otherwise stated, this document does 197 not make any assumption on the type or execution environment of a 198 service. 200 The execution of a service can be integrated as part of an SR policy 201 by assigning a segment identifier, or SID, to the service and 202 including this service SID in the SR policy SID-list. Such a service 203 SID may be of local or global significance. In the former case, 204 other segments, such as prefix or adjacency segments, can be used to 205 steer the traffic up to the node where the service segment is 206 instantiated. In the latter case, the service is directly reachable 207 from anywhere in the routing domain. This is realized with SR-MPLS 208 by assigning a SID from the global label block 209 ([I-D.ietf-spring-segment-routing-mpls]), or with SRv6 by advertising 210 the SID locator in the routing protocol 211 ([I-D.filsfils-spring-srv6-network-programming]). It is up to the 212 network operator to define the scope and reachability of each service 213 SID. This decision can be based on various considerations such as 214 infrastructure dynamicity, available control plane or orchestration 215 system capabilities. 217 This document categorizes services in two types, depending on whether 218 they are able to behave properly in the presence of SR information or 219 not. These are respectively named SR-aware and SR-unaware services. 221 4.1. SR-aware services 223 An SR-aware service can process the SR information in the packets it 224 receives. This means being able to identify the active segment as a 225 local instruction and move forward in the segment list, but also that 226 the service's own behavior is not hindered due to the presence of SR 227 information. For example, an SR-aware firewall filtering SRv6 228 traffic based on its final destination must retrieve that information 229 from the last entry in the SRH rather than the Destination Address 230 field of the IPv6 header. 232 An SR-aware service is associated with a locally instantiated service 233 segment, which is used to steer traffic through it. 235 If the service is configured to intercept all the packets passing 236 through the appliance, the underlying routing system only has to 237 implement a default SR endpoint behavior (SR-MPLS node segment or 238 SRv6 End function), and the corresponding SID will be used to steer 239 traffic through the service. 241 If the service requires the packets to be directed to a specific 242 virtual interface, networking queue or process, a dedicated SR 243 behavior may be required to steer the packets to the appropriate 244 location. The definition of such service-specific functions is out 245 of the scope of this document. 247 SR-aware services also enable advanced network programming 248 functionalities such as conditional branching and jumping to 249 arbitrary SIDs in the segment list. In addition, SRv6 provides 250 several ways of passing and exchanging information between services 251 (e.g., SID arguments, tag field and TLVs). An example scenario 252 involving these features is described in [IFIP18], which discusses 253 the implementation of an SR-aware Intrusion Detection System. 255 Examples of SR-aware services are provided in section Section 8.1. 257 4.2. SR-unaware services 259 Any service that does not meet the above criteria for SR-awareness is 260 considered as SR-unaware. 262 An SR-unaware service is not able to process the SR information in 263 the traffic that it receives. It may either drop the traffic or take 264 erroneous decisions due to the unrecognized routing information. In 265 order to include such services in an SR policy, it is thus required 266 to remove the SR information as well as any other encapsulation 267 header before the service receives the packet, or to alter it in such 268 a way that the service can correctly process the packet. 270 In this document, we define the concept of an SR proxy as an entity, 271 separate from the service, that performs these modifications and 272 handle the SR processing on behalf of a service. The SR proxy can 273 run as a separate process on the service appliance, on a virtual 274 switch or router on the compute node or on a different host. 276 An SR-unaware service is associated with a service segment 277 instantiated on the SR proxy, which is used to steer traffic through 278 the service. Section 6 describes several SR proxy behaviors to 279 handle the encapsulation headers and SR information under various 280 circumstances. 282 5. SR service policies 284 An SR service policy is an SR policy, as defined in 285 [I-D.ietf-spring-segment-routing-policy], that includes at least one 286 service. This service is represented in the SID-list by its 287 associated service SID. In case the policy should include several 288 services, the service traversal order is indicated by the relative 289 position of each service SID in the SID-list. Using the mechanisms 290 described in [I-D.ietf-spring-segment-routing-policy], it is possible 291 to load balance the traffic over several services, or instances of 292 the same service, by associating with the SR service policy a 293 weighted set of SID-lists, each containing a possible sequence of 294 service SIDs to be traversed. Similarly, several candidate paths can 295 be specified for the SR service policy, each with its own set of SID- 296 lists, for resiliency purposes. 298 Furthermore, binding SIDs (BSIDs) can be leveraged in the context of 299 service policies to reduce the number of SIDs imposed by the headend, 300 provide opacity between domains and improve scalability, as described 301 in [I-D.filsfils-spring-sr-policy-considerations]. For example, a 302 network operator may want a policy in its core domain to include 303 services that are running in one of its datacenters. One option is 304 to define an SR policy at ingress edge of the core domain that 305 explicitly includes all the SIDs needed to steer the traffic through 306 the core and in the DC, but that may result in a long SID-list and 307 requires to update the ingress edge configuration every time the DC 308 part of the policy is modified. Alternatively, a separate policy can 309 be defined at the ingress edge of the datacenter with only the SIDs 310 that needs to be executed there and its BSID included in the core 311 domain policy. That BSID remains stable when the DC policy is 312 modified and can even be shared among several core domain policies 313 that would require the same type of processing in the DC. 315 This section describes how services can be integrated within an SR- 316 MPLS or SRv6 service policy. 318 +------------------------------------------+ 319 | SR network | 320 | | 321 +----+----+ +---------+ +----+-----+ 322 | H +----------+ S +-----------+ E | 323 |(headend)| |(service)| |(endpoint)| 324 +----+----+ +---------+ +----+-----+ 325 | =====================================> | 326 | P1(H,E,C) | 327 +------------------------------------------+ 329 Figure 1: SR service policy 331 Figure 1 illustrates a basic SR service policy instantiated on a 332 headend node H towards an endpoint E and traversing a service S. The 333 SR policy may also include additional requirements, such as traffic 334 engineering or VPN. On the head-end H, the SR policy P1 is created 335 with a color C and endpoint E and associated with an SR path that can 336 either be explicitly configured, dynamically computed on H or 337 provisioned by a network controller. 339 In its most basic form, the SR policy P1 would be resolved into the 340 SID-list < SID(S), SID(E) >. This is assuming that SID(S) and SID(E) 341 are directly reachable from H and S, respectively, and that the 342 forwarding path meets the policy requirement. However, depending on 343 the dataplane and the segments available in the network, additional 344 SIDs may be required to enforce the SR policy. 346 This model applies regardless of the SR-awareness of the service. If 347 it is SR-unaware, then S simply represents the proxy that takes care 348 of transmitting the packet to the actual service. 350 Traffic can then be steered into this policy using any of the 351 mechanisms described in [I-D.ietf-spring-segment-routing-policy]. 353 The following subsections describe the specificities of each SR 354 dataplane. 356 5.1. SR-MPLS data plane 357 +-----------------------------------------------+ 358 | SR-MPLS network | 359 | | 360 +----+----+ ------> +---------+ ------> +----+-----+ 361 | H +-------------+ S +-------------+ E | 362 |(headend)| |(service)| |(endpoint)| 363 +----+----+ +---------+ +----+-----+ 364 | (1) (2) (3) (4) | 365 |+---------+ +---------+ +---------+ +---------+| 366 || ... | | L(S) | | ... | | L(E) || 367 |+---------+ +---------+ +---------+ +---------+| 368 || L(S) | | ... | | L(E) | |Inner pkt|| 369 |+---------+ +---------+ +---------+ +---------+| 370 || ... | | L(E) | |Inner pkt| | 371 |+---------+ +---------+ +---------+ | 372 || L(E) | |Inner pkt| | 373 |+---------+ +---------+ | 374 ||Inner pkt| | 375 |+---------+ | 376 +-----------------------------------------------+ 378 Figure 2: Packet walk in an SR-MPLS network 380 In an SR-MPLS network, the SR policy SID-list is encoded as a stack 381 of MPLS labels[I-D.ietf-spring-segment-routing-mpls] and pushed on 382 top of the packet. 384 In the example shown on Figure 2, the SR policy should steer the 385 traffic from the head-end H to the endpoint E via a service S. This 386 translates into an MPLS label stack that includes at least a label 387 L(S) associated to service S and a label L(E) associated to the 388 endpoint E. The label stack may also include additional intermediate 389 segments if these are required for traffic engineering (e.g., to 390 encode a low latency path between H and S and / or between S and E) 391 or simply for reachability purposes. Indeed, the service SID L(S) 392 may be taken from the global or local SID block of node S and, in the 393 latter case, one or more SIDs might be needed before L(S) in order 394 for the packet to reach node S (e.g., a prefix-SID of S), where L(S) 395 can be interpreted. The same applies for the segment L(E) at the SR 396 policy endpoint. 398 Special consideration must be taken into account when using Local 399 SIDs for service identification due to increased label stack depth 400 and the associated impacts. 402 When the packet arrives at S, this node determines how to process the 403 packet based on the semantic locally associated to the top label 404 L(S). If S is an SR-aware service, the SID L(S) may provide 405 additional context or indication on how to process the packet (e.g., 406 payload type or a firewall SID may indicate which rule set should be 407 applied onto the packet). If S is a proxy in front of an SR-unaware 408 service, L(S) indicates how and to which service attached to this 409 proxy the packet should be transmitted. At some point in the 410 process, L(S) is also popped from the label stack in order to expose 411 the next SID, which may be L(E) or another intermediate segment. 413 5.2. SRv6 data plane 415 +-----------------------------------------------+ 416 | SRv6 network | 417 | | 418 +----+----+ ------> +---------+ ------> +----+-----+ 419 | H +-------------+ S +-------------+ E | 420 |(headend)| |(service)| |(endpoint)| 421 +----+----+ +---------+ +----+-----+ 422 | (1) (2) (3) (2) | 423 |+---------+ +---------+ +---------+ +---------+| 424 ||IP6(H,..)| |IP6(H, S)| |IP6(H,..)| |IP6(H, E)|| 425 |+---------+ +---------+ +---------+ +---------+| 426 ||SRH(E,..,| |SRH(E,..,| |SRH(E,..,| |SRH(E,..,|| 427 || S,..;| | S,..;| | S,..;| | S,..;|| 428 || SL=i)| | SL=j)| | SL=k)| | SL=0)|| 429 |+---------+ +---------+ +---------+ +---------+| 430 ||Inner pkt| |Inner pkt| |Inner pkt| |Inner pkt|| 431 |+---------+ +---------+ +---------+ +---------+| 432 +-----------------------------------------------+ 434 Figure 3: Packet walk in an SRv6 network 436 In an SRv6 network, the SR Policy is encoded into the packet as an 437 IPv6 header possibly followed by a Segment Routing header (SRH) 438 [I-D.ietf-6man-segment-routing-header]. 440 In the example shown on Figure 3, the SR policy should steer the 441 traffic from the head-end H to the endpoint E via a service S. This 442 translates into an SRH that includes at least a segment SID(S) to the 443 service, or service proxy, S and a segment SID(E) to the endpoint E. 444 The SRH may also include additional intermediate segments if these 445 are required for traffic engineering (e.g., the encode a low latency 446 path between H and S and / or between S and E) or simply for 447 reachability purposes. Indeed, the service segment locator may or 448 may not be advertised in the routing protocol and, in the latter 449 case, one or more SIDs might be needed before SID(S) in order to 450 bring the packet up to node S, where SID(S) can be interpreted. The 451 same applies for the segment SID(E) at the SR policy endpoint. 453 When the packet arrives at S, this node determines how to process the 454 packet based on the semantic locally associated to the active segment 455 SID(S). If S is an SR-aware service, then SID(S) may provide 456 additional context or indication on how to process the packet (e.g., 457 a firewall SID may indicate which rule set should be applied onto the 458 packet). If S is a proxy in front of an SR-unaware service, SID(S) 459 indicates how and to which service attached to this proxy the packet 460 should be transmitted. At some point in the process, the SRv6 End 461 function is also applied in order to make the next SID, which may be 462 SID(E) or another intermediate segment, active. 464 The "Inner pkt" on Figure 3 represents the SRv6 payload, which may be 465 an encapsulated IP packet, an Ethernet frame or a transport-layer 466 payload, for example. 468 6. SR proxy behaviors 470 This section describes several SR proxy behaviors designed to enable 471 SR service programming through SR-unaware services. A system 472 implementing one of these functions may handle the SR processing on 473 behalf of an SR-unaware service and allows the service to properly 474 process the traffic that is steered through it. 476 A service may be located at any hop in an SR policy, including the 477 last segment. However, the SR proxy behaviors defined in this 478 section are dedicated to supporting SR-unaware services at 479 intermediate hops in the segment list. In case an SR-unaware service 480 is at the last segment, it is sufficient to ensure that the SR 481 information is ignored (IPv6 routing extension header with Segments 482 Left equal to 0) or removed before the packet reaches the service 483 (MPLS PHP, SRv6 End.D or PSP). 485 As illustrated on Figure 4, the generic behavior of an SR proxy has 486 two parts. The first part is in charge of passing traffic from the 487 network to the service. It intercepts the SR traffic destined for 488 the service via a locally instantiated service segment, modifies it 489 in such a way that it appears as non-SR traffic to the service, then 490 sends it out on a given interface, IFACE-OUT, connected to the 491 service. The second part receives the traffic coming back from the 492 service on IFACE-IN, restores the SR information and forwards it 493 according to the next segment in the list. IFACE-OUT and IFACE-IN 494 are respectively the proxy interface used for sending traffic to the 495 service and the proxy interface that receives the traffic coming back 496 from the service. These can be physical interfaces or sub-interfaces 497 (VLANs) and, unless otherwise stated, IFACE-OUT and IFACE-IN can 498 represent the same interface. 500 +----------------------------+ 501 | | 502 | Service | 503 | | 504 +----------------------------+ 505 ^ Non SR | 506 | traffic | 507 | v 508 +-----------+----------+ 509 +--| IFACE OUT | IFACE IN |--+ 510 SR traffic | +-----------+----------+ | SR traffic 511 ---------->| SR proxy |----------> 512 | | 513 +----------------------------+ 515 Figure 4: Generic SR proxy 517 In the next subsections, the following SR proxy mechanisms are 518 defined: 520 o Static proxy 522 o Dynamic proxy 524 o Shared-memory proxy 526 o Masquerading proxy 528 Each mechanism has its own characteristics and constraints, which are 529 summarized in the below table. It is up to the operator to select 530 the best one based on the proxy node capabilities, the service 531 behavior and the traffic type. It is also possible to use different 532 proxy mechanisms within the same service policy. 534 +-----+-----+-----+-----+ 535 | | | | M | 536 | | | S | a | 537 | | | h | s | 538 | | | a | q | 539 | | | r | u | 540 | | D | e | e | 541 | S | y | d | r | 542 | t | n | | a | 543 | a | a | m | d | 544 | t | m | e | i | 545 | i | i | m | n | 546 | c | c | . | g | 547 +---------------------------------------+-----+-----+-----+-----+ 548 | | SR-MPLS | Y | Y | Y | - | 549 | | | | | | | 550 | SR flavors | SRv6 insertion | P | P | P | Y | 551 | | | | | | | 552 | | SRv6 encapsulation | Y | Y | Y | - | 553 +----------------+----------------------+-----+-----+-----+-----+ 554 | Chain agnostic configuration | N | N | Y | Y | 555 +---------------------------------------+-----+-----+-----+-----+ 556 | Transparent to chain changes | N | Y | Y | Y | 557 +----------------+----------------------+-----+-----+-----+-----+ 558 | | DA modification | Y | Y | Y | NAT | 559 | | | | | | | 560 | | Payload modification | Y | Y | Y | Y | 561 | | | | | | | 562 |Service support | Packet generation | Y | Y |cache|cache| 563 | | | | | | | 564 | | Packet deletion | Y | Y | Y | Y | 565 | | | | | | | 566 | | Transport endpoint | Y | Y |cache|cache| 567 +----------------+----------------------+-----+-----+-----+-----+ 568 | | Ethernet | Y | Y | Y | - | 569 | Supported | | | | | | 570 | traffic | IPv4 | Y | Y | Y | - | 571 | | | | | | | 572 | | IPv6 | Y | Y | Y | Y | 573 +----------------+----------------------+-----+-----+-----+-----+ 575 Figure 5: SR proxy summary 577 Note: The use of a shared memory proxy requires both the service 578 (VNF) and the proxy to be running on the same node. 580 6.1. Static SR proxy 582 The static proxy is an SR endpoint behavior for processing SR-MPLS or 583 SRv6 encapsulated traffic on behalf of an SR-unaware service. This 584 proxy thus receives SR traffic that is formed of an MPLS label stack 585 or an IPv6 header on top of an inner packet, which can be Ethernet, 586 IPv4 or IPv6. 588 A static SR proxy segment is associated with the following mandatory 589 parameters 591 o INNER-TYPE: Inner packet type 593 o NH-ADDR: Next hop Ethernet address (only for inner type IPv4 and 594 IPv6) 596 o IFACE-OUT: Local interface for sending traffic towards the service 598 o IFACE-IN: Local interface receiving the traffic coming back from 599 the service 601 o CACHE: SR information to be attached on the traffic coming back 602 from the service, including at least 604 * CACHE.SA: IPv6 source address (SRv6 only) 606 * CACHE.LIST: Segment list expressed as MPLS labels or IPv6 607 address 609 A static SR proxy segment is thus defined for a specific service, 610 inner packet type and cached SR information. It is also bound to a 611 pair of directed interfaces on the proxy. These may be both 612 directions of a single interface, or opposite directions of two 613 different interfaces. The latter is recommended in case the service 614 is to be used as part of a bi-directional SR SC policy. If the proxy 615 and the service both support 802.1Q, IFACE-OUT and IFACE-IN can also 616 represent sub-interfaces. 618 The first part of this behavior is triggered when the proxy node 619 receives a packet whose active segment matches a segment associated 620 with the static proxy behavior. It removes the SR information from 621 the packet then sends it on a specific interface towards the 622 associated service. This SR information corresponds to the full 623 label stack for SR-MPLS or to the encapsulation IPv6 header with any 624 attached extension header in the case of SRv6. 626 The second part is an inbound policy attached to the proxy interface 627 receiving the traffic returning from the service, IFACE-IN. This 628 policy attaches to the incoming traffic the cached SR information 629 associated with the SR proxy segment. If the proxy segment uses the 630 SR-MPLS data plane, CACHE contains a stack of labels to be pushed on 631 top of the packets. With the SRv6 data plane, CACHE is defined as a 632 source address, an active segment and an optional SRH (tag, segments 633 left, segment list and metadata). The proxy encapsulates the packets 634 with an IPv6 header that has the source address, the active segment 635 as destination address and the SRH as a routing extension header. 636 After the SR information has been attached, the packets are forwarded 637 according to the active segment, which is represented by the top MPLS 638 label or the IPv6 Destination Address. An MPLS TTL or IPv6 Hop Limit 639 value may also be configured in CACHE. If it is not, the proxy 640 should set these values according to the node's default setting for 641 MPLS or IPv6 encapsulation. 643 In this scenario, there are no restrictions on the operations that 644 can be performed by the service on the stream of packets. It may 645 operate at all protocol layers, terminate transport layer 646 connections, generate new packets and initiate transport layer 647 connections. This behavior may also be used to integrate an 648 IPv4-only service into an SRv6 policy. However, a static SR proxy 649 segment can be used in only one service policy at a time. As opposed 650 to most other segment types, a static SR proxy segment is bound to a 651 unique list of segments, which represents a directed SR SC policy. 652 This is due to the cached SR information being defined in the segment 653 configuration. This limitation only prevents multiple segment lists 654 from using the same static SR proxy segment at the same time, but a 655 single segment list can be shared by any number of traffic flows. 656 Besides, since the returning traffic from the service is re- 657 classified based on the incoming interface, an interface can be used 658 as receiving interface (IFACE-IN) only for a single SR proxy segment 659 at a time. In the case of a bi-directional SR SC policy, a different 660 SR proxy segment and receiving interface are required for the return 661 direction. 663 The static proxy behavior may also be used for sending traffic 664 through "bump in the wire" services that are transparent to the IP 665 and Ethernet layers. This type of processing is assumed when the 666 inner traffic type is Ethernet, since the original destination 667 address of the Ethernet frame is preserved when the packet is steered 668 into the SR Policy and likely associated with a node downstream of 669 the policy tail-end. In case the inner type is IP (IPv4 or IPv6), 670 the NH-ADDR parameter may be set to a dummy or broadcast Ethernet 671 address, or simply to the address of the proxy receiving interface 672 (IFACE-IN). 674 6.1.1. SR-MPLS pseudocode 676 6.1.1.1. Static proxy for inner type Ethernet 678 Upon receiving an MPLS packet with top label L, where L is an MPLS L2 679 static proxy segment, a node N does: 681 1. Pop all labels 682 2. IF payload type is Ethernet THEN 683 3. Forward the exposed frame on IFACE-OUT 684 4. ELSE 685 5. Drop the packet 687 Upon receiving on IFACE-IN an Ethernet frame with a destination 688 address different than the interface address, a node N does: 690 1. Push labels in CACHE on top of the frame Ethernet header 691 2. Lookup the top label and proceed accordingly 693 The receiving interface must be configured in promiscuous mode in 694 order to accept those Ethernet frames. 696 6.1.1.2. Static proxy for inner type IPv4 698 Upon receiving an MPLS packet with top label L, where L is an MPLS 699 IPv4 static proxy segment, a node N does: 701 1. Pop all labels 702 2. IF payload type is IPv4 THEN 703 3. Forward the exposed packet on IFACE-OUT towards NH-ADDR 704 4. ELSE 705 5. Drop the packet 707 Upon receiving a non-link-local IPv4 packet on IFACE-IN, a node N 708 does: 710 1. Decrement TTL and update checksum 711 2. Push labels in CACHE on top of the packet IPv4 header 712 3. Lookup the top label and proceed accordingly 714 6.1.1.3. Static proxy for inner type IPv6 716 Upon receiving an MPLS packet with top label L, where L is an MPLS 717 IPv6 static proxy segment, a node N does: 719 1. Pop all labels 720 2. IF payload type is IPv6 THEN 721 3. Forward the exposed packet on IFACE-OUT towards NH-ADDR 722 4. ELSE 723 5. Drop the packet 725 Upon receiving a non-link-local IPv6 packet on IFACE-IN, a node N 726 does: 728 1. Decrement Hop Limit 729 2. Push labels in CACHE on top of the packet IPv6 header 730 3. Lookup the top label and proceed accordingly 732 6.1.2. SRv6 pseudocode 734 6.1.2.1. Static proxy for inner type Ethernet 736 Upon receiving an IPv6 packet destined for S, where S is an IPv6 737 static proxy segment for Ethernet traffic, a node N does: 739 1. IF ENH == 59 THEN ;; Ref1 740 2. Remove the (outer) IPv6 header and its extension headers 741 3. Forward the exposed frame on IFACE-OUT 742 4. ELSE 743 5. Drop the packet 745 Ref1: 59 refers to "no next header" as defined by IANA allocation for 746 Internet Protocol Numbers. 748 Upon receiving on IFACE-IN an Ethernet frame with a destination 749 address different than the interface address, a node N does: 751 1. Retrieve CACHE entry matching IFACE-IN and traffic type 752 2. Push SRH with CACHE.LIST on top of the Ethernet header ;; Ref2 753 3. Push IPv6 header with 754 SA = CACHE.SA 755 DA = CACHE.LIST[0] ;; Ref3 756 Next Header = 43 ;; Ref4 757 4. Set outer payload length and flow label 758 5. Lookup outer DA in appropriate table and proceed accordingly 760 Ref2: Unless otherwise specified, the segments in CACHE.LIST should 761 be encoded in reversed order, Segment Left and Last Entry values 762 should be set of the length of CACHE.LIST minus 1, and Next Header 763 should be set to 59. 765 Ref3: CACHE.LIST[0] represents the first IPv6 SID in CACHE.LIST. 767 Ref4: If CACHE.LIST contains a single entry, the SRH can be omitted 768 and the Next Header value must be set to 59. 770 The receiving interface must be configured in promiscuous mode in 771 order to accept those Ethernet frames. 773 6.1.2.2. Static proxy for inner type IPv4 775 Upon receiving an IPv6 packet destined for S, where S is an IPv6 776 static proxy segment for IPv4 traffic, a node N does: 778 1. IF ENH == 4 THEN ;; Ref1 779 2. Remove the (outer) IPv6 header and its extension headers 780 3. Forward the exposed packet on IFACE-OUT towards NH-ADDR 781 4. ELSE 782 5. Drop the packet 784 Ref1: 4 refers to IPv4 encapsulation as defined by IANA allocation 785 for Internet Protocol Numbers. 787 Upon receiving a non-link-local IPv4 packet on IFACE-IN, a node N 788 does: 790 1. Decrement TTL and update checksum 791 2. IF CACHE.SRH THEN ;; Ref2 792 3. Push CACHE.SRH on top of the existing IPv4 header 793 4. Set NH value of the pushed SRH to 4 794 5. Push outer IPv6 header with SA, DA and traffic class from CACHE 795 6. Set outer payload length and flow label 796 7. Set NH value to 43 if an SRH was added, or 4 otherwise 797 8. Lookup outer DA in appropriate table and proceed accordingly 799 Ref2: CACHE.SRH represents the SRH defined in CACHE, if any, for the 800 static SR proxy segment associated with IFACE-IN. 802 6.1.2.3. Static proxy for inner type IPv6 804 Upon receiving an IPv6 packet destined for S, where S is an IPv6 805 static proxy segment for IPv6 traffic, a node N does: 807 1. IF ENH == 41 THEN ;; Ref1 808 2. Remove the (outer) IPv6 header and its extension headers 809 3. Forward the exposed packet on IFACE-OUT towards NH-ADDR 810 4. ELSE 811 5. Drop the packet 813 Ref1: 41 refers to IPv6 encapsulation as defined by IANA allocation 814 for Internet Protocol Numbers. 816 Upon receiving a non-link-local IPv6 packet on IFACE-IN, a node N 817 does: 819 1. Decrement Hop Limit 820 2. IF CACHE.SRH THEN ;; Ref2 821 3. Push CACHE.SRH on top of the existing IPv6 header 822 4. Set NH value of the pushed SRH to 41 823 5. Push outer IPv6 header with SA, DA and traffic class from CACHE 824 6. Set outer payload length and flow label 825 7. Set NH value to 43 if an SRH was added, or 41 otherwise 826 8. Lookup outer DA in appropriate table and proceed accordingly 828 Ref2: CACHE.SRH represents the SRH defined in CACHE, if any, for the 829 static SR proxy segment associated with IFACE-IN. 831 6.2. Dynamic SR proxy 833 The dynamic proxy is an improvement over the static proxy that 834 dynamically learns the SR information before removing it from the 835 incoming traffic. The same information can then be re-attached to 836 the traffic returning from the service. As opposed to the static SR 837 proxy, no CACHE information needs to be configured. Instead, the 838 dynamic SR proxy relies on a local caching mechanism on the node 839 instantiating this segment. 841 Upon receiving a packet whose active segment matches a dynamic SR 842 proxy function, the proxy node pops the top MPLS label or applies the 843 SRv6 End behavior, then compares the updated SR information with the 844 cache entry for the current segment. If the cache is empty or 845 different, it is updated with the new SR information. The SR 846 information is then removed and the inner packet is sent towards the 847 service. 849 The cache entry is not mapped to any particular packet, but instead 850 to an SR SC policy identified by the receiving interface (IFACE-IN). 851 Any non-link-local IP packet or non-local Ethernet frame received on 852 that interface will be re-encapsulated with the cached headers as 853 described in Section 6.1. The service may thus drop, modify or 854 generate new packets without affecting the proxy. 856 6.2.1. SR-MPLS pseudocode 858 The dynamic proxy SR-MPLS pseudocode is obtained by inserting the 859 following instructions at the beginning of the static SR-MPLS 860 pseudocode (Section 6.1.1). 862 1. IF top label S bit is 0 THEN ;; Ref1 863 2. Pop top label 864 3. IF C(IFACE-IN) different from remaining labels THEN ;; Ref2 865 4. Copy all remaining labels into C(IFACE-IN) ;; Ref3 866 5. ELSE 867 6. Drop the packet 869 Ref1: As mentioned at the beginning of Section 6, an SR proxy is not 870 needed to include an SR-unaware service at the end of an SR policy. 872 Ref2: A TTL margin can be configured for the top label stack entry to 873 prevent constant cache updates when multiple equal-cost paths with 874 different hop counts are used towards the SR proxy node. In that 875 case, a TTL difference smaller than the configured margin should not 876 trigger a cache update (provided that the labels are the same). 878 Ref3: C(IFACE-IN) represents the cache entry associated to the 879 dynamic SR proxy segment. It is identified with IFACE-IN in order to 880 efficiently retrieve the right SR information when a packet arrives 881 on this interface. 883 In addition, the inbound policy should check that C(IFACE-IN) has 884 been defined before attempting to restore the MPLS label stack and 885 drop the packet otherwise. 887 6.2.2. SRv6 pseudocode 889 The dynamic proxy SRv6 pseudocode is obtained by inserting the 890 following instructions between lines 1 and 2 of the static proxy SRv6 891 pseudocode. 893 1. IF NH=SRH & SL > 0 THEN ;; Ref1 894 2. Decrement SL and update the IPv6 DA with SRH[SL] 895 3. IF C(IFACE-IN) different from IPv6 encaps THEN ;; Ref2 896 4. Copy the IPv6 encaps into C(IFACE-IN) ;; Ref3 897 5. ELSE 898 6. Drop the packet 900 Ref1: As mentioned at the beginning of Section 6, an SR proxy is not 901 needed to include an SR-unaware service at the end of an SR policy. 903 Ref2: "IPv6 encaps" represents the IPv6 header and any attached 904 extension header. 906 Ref3: C(IFACE-IN) represents the cache entry associated to the 907 dynamic SR proxy segment. It is identified with IFACE-IN in order to 908 efficiently retrieve the right SR information when a packet arrives 909 on this interface. 911 In addition, the inbound policy should check that C(IFACE-IN) has 912 been defined before attempting to restore the IPv6 encapsulation and 913 drop the packet otherwise. 915 6.3. Shared memory SR proxy 917 The shared memory proxy is an SR endpoint behavior for processing SR- 918 MPLS or SRv6 encapsulated traffic on behalf of an SR-unaware service. 919 This proxy behavior leverages a shared-memory interface with a 920 virtualized service (VNF) in order to hide the SR information from an 921 SR-unaware service while keeping it attached to the packet. We 922 assume in this case that the proxy and the VNF are running on the 923 same compute node. A typical scenario is an SR-capable vrouter 924 running on a container host and forwarding traffic to VNFs isolated 925 within their respective container. 927 More details will be added in a future revision of this document. 929 6.4. Masquerading SR proxy 931 The masquerading proxy is an SR endpoint behavior for processing SRv6 932 traffic on behalf of an SR-unaware service. This proxy thus receives 933 SR traffic that is formed of an IPv6 header and an SRH on top of an 934 inner payload. The masquerading behavior is independent from the 935 inner payload type. Hence, the inner payload can be of any type but 936 it is usually expected to be a transport layer packet, such as TCP or 937 UDP. 939 A masquerading SR proxy segment is associated with the following 940 mandatory parameters: 942 o S-ADDR: Ethernet or IPv6 address of the service 944 o IFACE-OUT: Local interface for sending traffic towards the service 946 o IFACE-IN: Local interface receiving the traffic coming back from 947 the service 949 A masquerading SR proxy segment is thus defined for a specific 950 service and bound to a pair of directed interfaces or sub-interfaces 951 on the proxy. As opposed to the static and dynamic SR proxies, a 952 masquerading segment can be present at the same time in any number of 953 SR SC policies and the same interfaces can be bound to multiple 954 masquerading proxy segments. The only restriction is that a 955 masquerading proxy segment cannot be the last segment in an SR SC 956 policy. 958 The first part of the masquerading behavior is triggered when the 959 proxy node receives an IPv6 packet whose Destination Address matches 960 a masquerading proxy segment. The proxy inspects the IPv6 extension 961 headers and substitutes the Destination Address with the last segment 962 in the SRH attached to the IPv6 header, which represents the final 963 destination of the IPv6 packet. The packet is then sent out towards 964 the service. 966 The service receives an IPv6 packet whose source and destination 967 addresses are respectively the original source and final destination. 968 It does not attempt to inspect the SRH, as RFC8200 specifies that 969 routing extension headers are not examined or processed by transit 970 nodes. Instead, the service simply forwards the packet based on its 971 current Destination Address. In this scenario, we assume that the 972 service can only inspect, drop or perform limited changes to the 973 packets. For example, Intrusion Detection Systems, Deep Packet 974 Inspectors and non-NAT Firewalls are among the services that can be 975 supported by a masquerading SR proxy. Variants of the masquerading 976 behavior are defined in Section 6.4.2 and Section 6.4.3 to support a 977 wider range of services. 979 The second part of the masquerading behavior, also called de- 980 masquerading, is an inbound policy attached to the proxy interface 981 receiving the traffic returning from the service, IFACE-IN. This 982 policy inspects the incoming traffic and triggers a regular SRv6 983 endpoint processing (End) on any IPv6 packet that contains an SRH. 984 This processing occurs before any lookup on the packet Destination 985 Address is performed and it is sufficient to restore the right active 986 segment as the Destination Address of the IPv6 packet. 988 6.4.1. SRv6 masquerading proxy pseudocode 990 Masquerading: Upon receiving a packet destined for S, where S is an 991 IPv6 masquerading proxy segment, a node N processes it as follows. 993 1. IF NH=SRH & SL > 0 THEN 994 2. Update the IPv6 DA with SRH[0] 995 3. Forward the packet on IFACE-OUT 996 4. ELSE 997 5. Drop the packet 999 De-masquerading: Upon receiving a non-link-local IPv6 packet on 1000 IFACE-IN, a node N processes it as follows. 1002 1. IF NH=SRH & SL > 0 THEN 1003 2. Decrement SL 1004 3. Update the IPv6 DA with SRH[SL] ;; Ref1 1005 4. Lookup DA in appropriate table and proceed accordingly 1006 Ref1: This pseudocode can be augmented to support the Penultimate 1007 Segment Popping (PSP) endpoint flavor. The exact pseudocode 1008 modification are provided in 1009 [I-D.filsfils-spring-srv6-network-programming]. 1011 6.4.2. Variant 1: Destination NAT 1013 Services modifying the destination address in the packets they 1014 process, such as NATs, can be supported by a masquerading proxy with 1015 the following modification to the de-masquerading pseudocode. 1017 De-masquerading - NAT: Upon receiving a non-link-local IPv6 packet on 1018 IFACE-IN, a node N processes it as follows. 1020 1. IF NH=SRH & SL > 0 THEN 1021 2. Update SRH[0] with the IPv6 DA 1022 3. Decrement SL 1023 4. Update the IPv6 DA with SRH[SL] 1024 5. Lookup DA in appropriate table and proceed accordingly 1026 6.4.3. Variant 2: Caching 1028 Services generating packets or acting as endpoints for transport 1029 connections can be supported by adding a dynamic caching mechanism 1030 similar to the one described in Section 6.2. 1032 More details will be added in a future revision of this document. 1034 7. Metadata 1036 7.1. MPLS data plane 1038 Metadata can be carried for SR-MPLS traffic in a Segment Routing 1039 header inserted between the last MPLS label and the MPLS payload. 1040 When used solely as a metadata container, the SRH does not carry any 1041 segment but only the mandatory header fields, including the tag and 1042 flags, and any TLVs that is required for transporting the metadata. 1044 Since the MPLS encapsulation has no explicit protocol identifier 1045 field to indicate the protocol type of the MPLS payload, how to 1046 indicate the presence of metadata in an MPLS packet is a potential 1047 issue to be addressed. One possible solution is to add the 1048 indication about the presence of metadata in the semantic of the 1049 SIDs. Note that only the SIDs whose behavior involves looking at the 1050 metadata or the MPLS payload would need to include such semantic 1051 (e.g., service segments). Other segments, such as traffic 1052 engineering segments, are not affected by the presence of metadata. 1053 Another, more generic, solution is to introduce a protocol identifier 1054 field within the MPLS packet as described in 1055 [I-D.xu-mpls-payload-protocol-identifier]. 1057 7.2. IPv6 data plane 1059 7.2.1. SRH TLV objects 1061 The IPv6 SRH TLV objects are designed to carry all sorts of metadata. 1062 In particular, the NSH carrier TLV is defined as a container for NSH 1063 metadata. 1065 TLV objects can be imposed by the ingress edge router that steers the 1066 traffic into the SR SC policy. 1068 An SR-aware service may impose, modify or remove any TLV object 1069 attached to the first SRH, either by directly modifying the packet 1070 headers or via a control channel between the service and its 1071 forwarding plane. 1073 An SR-aware service that re-classifies the traffic and steers it into 1074 a new SR SC policy (e.g. DPI) may attach any TLV object to the new 1075 SRH. 1077 Metadata imposition and handling will be further discussed in a 1078 future version of this document. 1080 7.2.1.1. Opaque Metadata TLV 1082 This document defines an SRv6 TLV called Opaque Metadata TLV. This 1083 is a fixed-length container to carry any type of Service Metadata. 1084 No assumption is made by this document on the structure or the 1085 content of the carried metadata. The Opaque Metadata TLV has the 1086 following format: 1088 0 1 2 3 1089 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 1090 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1091 | Type | Length | | 1092 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1093 | | 1094 | Service Metadata | 1095 | | 1096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1098 where: 1100 o Type: to be assigned by IANA. 1102 o Length: 14. 1104 o Service Metadata: 14 octets of opaque data. 1106 7.2.1.2. NSH Carrier TLV 1108 This document defines an SRv6 TLV called NSH Carrier TLV. It is a 1109 container to carry Service Metadata in the form of Variable-Length 1110 Metadata as defined in [RFC8300] for NSH MD Type 2. The NSH Carrier 1111 TLV has the following format: 1113 0 1 2 3 1114 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 1115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1116 | Type | Length | Flags | 1117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1118 // Service Metadata // 1119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1121 where: 1123 o Type: to be assigned by IANA. 1125 o Length: the total length of the TLV. 1127 o Flags: 8 bits. No flags are defined in this document. SHOULD be 1128 set to 0 on transmission and MUST be ignored on receipt. 1130 o Service Metadata: a list of Service Metadata TLV as defined in 1131 [RFC8300] for NSH MD Type 2. 1133 7.2.2. SRH tag 1135 The SRH tag identifies a packet as part of a group or class of 1136 packets [I-D.ietf-6man-segment-routing-header]. 1138 In the context of service programming, this field can be used to 1139 encode basic metadata in the SRH. An example use case would be to 1140 leverage the SRH tag to encode a policy ID which could be leveraged 1141 in an SR-aware function to determine which processing policy to apply 1142 rather than having doing local classification or leverage alternate 1143 encapsulations. 1145 8. Implementation status 1147 This section is to be removed prior to publishing as an RFC. 1149 8.1. SR-aware services 1151 Specific SRv6 support has been implemented for the below open-source 1152 services: 1154 o Iptables (1.6.2 and later) 1156 o Nftables (0.8.4 and later) 1158 o Snort 1160 In addition, any service relying on the Linux kernel, version 4.10 1161 and later, or FD.io VPP for packet forwarding can be considered as 1162 SR-aware. 1164 8.2. Proxy behaviors 1166 The static SR proxy is available for SR-MPLS and SRv6 on various 1167 Cisco hardware and software platforms. Furthermore, the following 1168 proxies are available on open-source software. 1170 +-------------+-------------+ 1171 | VPP | Linux | 1172 +---+-----------------------------------+-------------+-------------+ 1173 | M | Static proxy | Available | In progress | 1174 | P | | | | 1175 | L | Dynamic proxy | In progress | In progress | 1176 | S | | | | 1177 | | Shared memory proxy | In progress | In progress | 1178 +---+-----------------------------------+-------------+-------------+ 1179 | | Static proxy | Available | In progress | 1180 | S | | | | 1181 | R | Dynamic proxy | Available | Available | 1182 | v | | | | 1183 | 6 | Shared memory proxy | In progress | In progress | 1184 | | | | | 1185 | | Masquerading proxy | Available | Available | 1186 +---+-----------------------------------+-------------+-------------+ 1188 Figure 6: Open-source implementation status table 1190 9. Related works 1192 The Segment Routing solution addresses a wide problem that covers 1193 both topological and service policies. The topological and service 1194 instructions can be either deployed in isolation or in combination. 1195 SR has thus a wider applicability than the architecture defined in 1196 [RFC7665]. Furthermore, the inherent property of SR is a stateless 1197 network fabric. In SR, there is no state within the fabric to 1198 recognize a flow and associate it with a policy. State is only 1199 present at the ingress edge of the SR domain, where the policy is 1200 encoded into the packets. This is completely different from other 1201 proposals such as [RFC8300] and the MPLS label swapping mechanism 1202 described in [I-D.ietf-mpls-sfc], which rely on state configured at 1203 every hop of the service chain. 1205 10. IANA Considerations 1207 10.1. SRv6 Endpoint Behaviors 1209 This I-D requests the IANA to allocate, within the "SRv6 Endpoint 1210 Behaviors" sub-registry belonging to the top-level "Segment-routing 1211 with IPv6 dataplane (SRv6) Parameters" registry, the following 1212 allocations: 1214 Value Description Reference 1215 -------------------------------------------------------------- 1216 TBA1 End.AN - SR-aware function (native) [This.ID] 1217 TBA2 End.AS - Static proxy [This.ID] 1218 TBA3 End.AD - Dynamic proxy [This.ID] 1219 TBA4 End.AM - Masquerading proxy [This.ID] 1221 10.2. Segment Routing Header TLVs 1223 This I-D requests the IANA to allocate, within the "Segment Routing 1224 Header TLVs" registry, the following allocations: 1226 Value Description Reference 1227 ---------------------------------------------- 1228 TBA1 Opaque Metadata TLV [This.ID] 1229 TBA2 NSH Carrier TLV [This.ID] 1231 11. Security Considerations 1233 The security requirements and mechanisms described in [RFC8402], 1234 [I-D.ietf-6man-segment-routing-header] and 1235 [I-D.filsfils-spring-srv6-network-programming] also apply to this 1236 document. 1238 This document does not introduce any new security vulnerabilities. 1240 12. Acknowledgements 1242 The authors would like to thank Thierry Couture, Ketan Talaulikar, 1243 Loa Andersson, Andrew G. Malis, Adrian Farrel, Alexander Vainshtein 1244 and Joel M. Halpern for their valuable comments and suggestions on 1245 the document. 1247 13. Contributors 1249 P. Camarillo (Cisco), B. Peirens (Proximus), D. Steinberg 1250 (Steinberg Consulting), A. AbdelSalam (Gran Sasso Science 1251 Institute), G. Dawra (LinkedIn), S. Bryant (Huawei), H. Assarpour 1252 (Broadcom), H. Shah (Ciena), L. Contreras (Telefonica I+D), J. 1253 Tantsura (Individual), M. Vigoureux (Nokia) and J. Bhattacharya 1254 (Cisco) substantially contributed to the content of this document. 1256 14. References 1258 14.1. Normative References 1260 [I-D.filsfils-spring-srv6-network-programming] 1261 Filsfils, C., Camarillo, P., Leddy, J., 1262 daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6 1263 Network Programming", draft-filsfils-spring-srv6-network- 1264 programming-05 (work in progress), July 2018. 1266 [I-D.ietf-6man-segment-routing-header] 1267 Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and 1268 d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header 1269 (SRH)", draft-ietf-6man-segment-routing-header-14 (work in 1270 progress), June 2018. 1272 [I-D.ietf-spring-segment-routing-mpls] 1273 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., 1274 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 1275 data plane", draft-ietf-spring-segment-routing-mpls-14 1276 (work in progress), June 2018. 1278 [I-D.ietf-spring-segment-routing-policy] 1279 Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d., 1280 bogdanov@google.com, b., and P. Mattes, "Segment Routing 1281 Policy Architecture", draft-ietf-spring-segment-routing- 1282 policy-01 (work in progress), June 2018. 1284 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1285 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1286 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1287 July 2018, . 1289 14.2. Informative References 1291 [I-D.dawra-idr-bgp-sr-service-chaining] 1292 Dawra, G., Filsfils, C., daniel.bernier@bell.ca, d., 1293 Uttaro, J., Decraene, B., Elmalky, H., Xu, X., Clad, F., 1294 and K. Talaulikar, "BGP Control Plane Extensions for 1295 Segment Routing based Service Chaining", draft-dawra-idr- 1296 bgp-sr-service-chaining-02 (work in progress), January 1297 2018. 1299 [I-D.filsfils-spring-sr-policy-considerations] 1300 Filsfils, C., Talaulikar, K., Krol, P., Horneffer, M., and 1301 P. Mattes, "SR Policy Implementation and Deployment 1302 Considerations", draft-filsfils-spring-sr-policy- 1303 considerations-02 (work in progress), October 2018. 1305 [I-D.ietf-mpls-sfc] 1306 Farrel, A., Bryant, S., and J. Drake, "An MPLS-Based 1307 Forwarding Plane for Service Function Chaining", draft- 1308 ietf-mpls-sfc-03 (work in progress), October 2018. 1310 [I-D.xu-mpls-payload-protocol-identifier] 1311 Xu, X., Assarpour, H., Ma, S., and F. Clad, "MPLS Payload 1312 Protocol Identifier", draft-xu-mpls-payload-protocol- 1313 identifier-05 (work in progress), August 2018. 1315 [IFIP18] Abdelsalam, A., Salsano, S., Clad, F., Camarillo, P., and 1316 C. Filsfils, "SEgment Routing Aware Firewall For Service 1317 Function Chaining scenarios", IFIP Networking conference , 1318 May 2018. 1320 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 1321 Chaining (SFC) Architecture", RFC 7665, 1322 DOI 10.17487/RFC7665, October 2015, 1323 . 1325 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 1326 "Network Service Header (NSH)", RFC 8300, 1327 DOI 10.17487/RFC8300, January 2018, 1328 . 1330 Authors' Addresses 1332 Francois Clad (editor) 1333 Cisco Systems, Inc. 1334 France 1336 Email: fclad@cisco.com 1337 Xiaohu Xu (editor) 1338 Alibaba 1340 Email: xiaohu.xxh@alibaba-inc.com 1342 Clarence Filsfils 1343 Cisco Systems, Inc. 1344 Belgium 1346 Email: cf@cisco.com 1348 Daniel Bernier 1349 Bell Canada 1350 Canada 1352 Email: daniel.bernier@bell.ca 1354 Cheng Li 1355 Huawei 1357 Email: chengli13@huawei.com 1359 Bruno Decraene 1360 Orange 1361 France 1363 Email: bruno.decraene@orange.com 1365 Shaowen Ma 1366 Juniper 1368 Email: mashaowen@gmail.com 1370 Chaitanya Yadlapalli 1371 AT&T 1372 USA 1374 Email: cy098d@att.com 1375 Wim Henderickx 1376 Nokia 1377 Belgium 1379 Email: wim.henderickx@nokia.com 1381 Stefano Salsano 1382 Universita di Roma "Tor Vergata" 1383 Italy 1385 Email: stefano.salsano@uniroma2.it