idnits 2.17.1 draft-filsfils-rtgwg-segment-routing-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 has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 21, 2013) is 3812 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) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 5316 (Obsoleted by RFC 9346) == Outdated reference: A later version (-02) exists of draft-filsfils-rtgwg-segment-routing-use-cases-01 == Outdated reference: A later version (-03) exists of draft-minto-rsvp-lsp-egress-fast-protection-02 == Outdated reference: A later version (-05) exists of draft-previdi-isis-segment-routing-extensions-02 == Outdated reference: A later version (-03) exists of draft-sivabalan-pce-segment-routing-02 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Filsfils, Ed. 3 Internet-Draft S. Previdi, Ed. 4 Intended status: Standards Track A. Bashandy 5 Expires: April 24, 2014 Cisco Systems, Inc. 6 B. Decraene 7 S. Litkowski 8 Orange 9 M. Horneffer 10 Deutsche Telekom 11 I. Milojevic 12 Telekom Srbija 13 R. Shakir 14 British Telecom 15 S. Ytti 16 TDC Oy 17 W. Henderickx 18 Alcatel-Lucent 19 J. Tantsura 20 Ericsson 21 E. Crabbe 22 Google, Inc. 23 October 21, 2013 25 Segment Routing Architecture 26 draft-filsfils-rtgwg-segment-routing-01 28 Abstract 30 Segment Routing (SR) leverages the source routing paradigm. A node 31 steers a packet through a controlled set of instructions, called 32 segments, by prepending the packet with an SR header. A segment can 33 represent any instruction, topological or service-based. A segment 34 can have a local semantic to an SR node or global within an SR 35 domain. SR allows to enforce a flow through any topological path and 36 service chain while maintaining per-flow state only at the ingress 37 node to the SR domain. 39 The Segment Routing architecture can be directly applied to the MPLS 40 dataplane with no change on the forwarding plane. IGP-based segments 41 require minor extension to the existing link-state routing protocols. 42 Segment Routing can also be applied to IPv6 with a new type of 43 routing extension header. 45 Requirements Language 47 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 48 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 49 document are to be interpreted as described in RFC 2119 [RFC2119]. 51 Status of this Memo 53 This Internet-Draft is submitted in full conformance with the 54 provisions of BCP 78 and BCP 79. 56 Internet-Drafts are working documents of the Internet Engineering 57 Task Force (IETF). Note that other groups may also distribute 58 working documents as Internet-Drafts. The list of current Internet- 59 Drafts is at http://datatracker.ietf.org/drafts/current/. 61 Internet-Drafts are draft documents valid for a maximum of six months 62 and may be updated, replaced, or obsoleted by other documents at any 63 time. It is inappropriate to use Internet-Drafts as reference 64 material or to cite them other than as "work in progress." 66 This Internet-Draft will expire on April 24, 2014. 68 Copyright Notice 70 Copyright (c) 2013 IETF Trust and the persons identified as the 71 document authors. All rights reserved. 73 This document is subject to BCP 78 and the IETF Trust's Legal 74 Provisions Relating to IETF Documents 75 (http://trustee.ietf.org/license-info) in effect on the date of 76 publication of this document. Please review these documents 77 carefully, as they describe your rights and restrictions with respect 78 to this document. Code Components extracted from this document must 79 include Simplified BSD License text as described in Section 4.e of 80 the Trust Legal Provisions and are provided without warranty as 81 described in the Simplified BSD License. 83 Table of Contents 85 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 86 1.1. Illustration . . . . . . . . . . . . . . . . . . . . . . . 4 87 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 88 1.3. Properties . . . . . . . . . . . . . . . . . . . . . . . . 8 89 1.4. Companion Documents . . . . . . . . . . . . . . . . . . . 9 90 1.5. Relationship with MPLS and IPv6 . . . . . . . . . . . . . 9 91 2. Abstract Routing Model . . . . . . . . . . . . . . . . . . . . 10 92 2.1. Traffic Engineering with SR . . . . . . . . . . . . . . . 12 93 2.2. Segment Routing Database . . . . . . . . . . . . . . . . . 13 94 3. Link-State IGP Segments . . . . . . . . . . . . . . . . . . . 13 95 3.1. Illustration . . . . . . . . . . . . . . . . . . . . . . . 14 96 3.1.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 15 97 3.1.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 15 98 3.1.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . 15 99 3.1.4. Example 4 . . . . . . . . . . . . . . . . . . . . . . 15 100 3.1.5. Example 5 . . . . . . . . . . . . . . . . . . . . . . 16 101 3.2. IGP Segment Terminology . . . . . . . . . . . . . . . . . 16 102 3.2.1. IGP Segment, IGP SID . . . . . . . . . . . . . . . . . 16 103 3.2.2. IGP-Prefix Segment, Prefix-SID . . . . . . . . . . . . 17 104 3.2.3. IGP-Node Segment, Node-SID . . . . . . . . . . . . . . 17 105 3.2.4. IGP-Anycast Segment, Anycast SID . . . . . . . . . . . 18 106 3.2.5. IGP-Adjacency Segment, Adj-SID . . . . . . . . . . . . 18 107 3.2.6. Finally . . . . . . . . . . . . . . . . . . . . . . . 19 108 3.3. IGP Segment Allocation, Advertisement and SRDB 109 Maintenance . . . . . . . . . . . . . . . . . . . . . . . 19 110 3.3.1. Prefix-SID . . . . . . . . . . . . . . . . . . . . . . 19 111 3.3.2. Adj-SID . . . . . . . . . . . . . . . . . . . . . . . 20 112 3.4. Inter-Area Considerations . . . . . . . . . . . . . . . . 22 113 3.5. IGP Mirroring Context Segment . . . . . . . . . . . . . . 23 114 4. Service Segments . . . . . . . . . . . . . . . . . . . . . . . 23 115 5. OAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 116 6. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 24 117 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 118 8. Manageability Considerations . . . . . . . . . . . . . . . . . 24 119 9. Security Considerations . . . . . . . . . . . . . . . . . . . 24 120 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 121 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 122 11.1. Normative References . . . . . . . . . . . . . . . . . . . 25 123 11.2. Informative References . . . . . . . . . . . . . . . . . . 25 124 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 126 1. Introduction 128 In this section, we illustrate the key properties of the SR 129 architecture, introduce the companion documents to this note and 130 relate SR to the MPLS and IPv6 architectures. 132 Section 2 defines the SR abstract routing model. Section 3 defines 133 the IGP-based segments. Section 4 defines the Service Segments. 135 1.1. Illustration 137 In the context of Figure 1 where all the links have the same IGP 138 cost, let us assume that a packet P enters the SR domain at an 139 ingress edge router I and that the operator requests the following 140 requirements for packet P: 142 The local service S offered by node B must be applied to packet P. 144 The links AB and CE cannot be used to transport the packet P. 146 Any node N along the journey of the packet should be able to 147 determine where the packet P entered the SR domain and where it 148 will exit. The intermediate node should be able to determine the 149 paths from the ingress edge router to itself, and from itsef to 150 the egress edge router. 152 Per-flow State for packet P should only be created at the ingress 153 edge router. 155 State for packet P can only be created at the ingress edge router. 157 The operator can forbid, for security reasons, anyone outside the 158 operator domain to exploit its intra-domain SR capabilities. 160 I---A---B---C---E 161 \ | / \ / 162 \ | / F 163 \|/ 164 D 166 Figure 1: An illustration of SR properties 168 All these properties may be realized by instructing the ingress SR 169 edge router I to push the following abstract SR header on the packet 170 P. 172 +---------------------------------------------------------------+ 173 | | | 174 | Abstract SR Header | | 175 | | | 176 | {SD, SB, SS, SF, SE}, Ptr, SI, SE | Transported | 177 | ^ | | Packet | 178 | | | | P | 179 | +---------------------+ | | 180 | | | 181 +---------------------------------------------------------------+ 183 Figure 2: Packet P at node I 185 The abstract SR header contains a source route encoded as a list of 186 segments {SD, SB, SS, SF, SE}, a pointer (Ptr) and the identification 187 of the ingress and egress SR edge routers (segments SI and SE). 189 A segment is a 32-bit identification either for a topological 190 instruction or a service instruction. A segment can either be global 191 or local. The instruction associated with a global segment is 192 recognized and executed by any SR-capable node in the domain. The 193 instruction associated with a local segment is only supported by the 194 specific node that originates it. 196 Let us assume some ISIS/OSPF extensions to define a "Node Segment" as 197 a global instruction within the IGP domain to forward a packet along 198 the shortest path to the specified node. Let us further assume that 199 within the SR domain illustrated in Figure 1, segments SI, SD, SB, SE 200 and SF respectively identify IGP node segments to I, D, B, E and F. 202 Let us assume that node B identifies its local service S with local 203 segment SS. 205 With all of this in mind, let us describe the journey of the packet 206 P. 208 The packet P reaches the ingress SR edge router. I pushes the SR 209 header illustrated in Figure 2 and sets the pointer to the first 210 segment of the list (SD). 212 SD is an instruction recognized by all the nodes in the SR domain 213 which causes the packet to be forwarded along the shortest path to D. 215 Once at D, the pointer is incremented and the next segment is 216 executed (SB). 218 SB is an instruction recognized by all the nodes in the SR domain 219 which causes the packet to be forwarded along the shortest path to B. 221 Once at B, the pointer is incremented and the next segment is 222 executed (SS). 224 SS is an instruction only recognized by node B which causes the 225 packet to receive service S. 227 Once the service applied, the next segment is executed (SF) which 228 causes the packet to be forwarded along the shortest path to F. 230 Once at F, the pointer is incremented and the next segment is 231 executed (SE). 233 SE is an instruction recognized by all the nodes in the SR domain 234 which causes the packet to be forwarded along the shortest path to E. 236 E then removes the SR header and the packet continues its journey 237 outside the SR domain. 239 All of the requirements are met. 241 First, the packet P has not used links AB and CE: the shortest-path 242 from I to D is I-A-D, the shortest-path from D to B is D-B, the 243 shortest-path from B to F is B-C-F and the shortest-path from F to E 244 is F-E, hence the packet path through the SR domain is I-A-D-B-C-F-E 245 and the links AB and CE have been avoided. 247 Second, the service S supported by B has been applied on packet P. 249 Third, any node along the packet path is able to identify the service 250 and topological journey of the packet within the SR domain. For 251 example, node C receives the packet illustrated in Figure 3 and hence 252 is able to infer where the packet entered the SR domain (SI), how it 253 got up to itself {SD, SB, SS, SE}, where it will exit the SR domain 254 (SE) and how it will do so {SF, SE}. 255 +---------------------------------------------------------------+ 256 | | | 257 | SR Header | | 258 | | | 259 | {SD, SB, SS, SF, SE}, Ptr, SI, SE | Transported | 260 | ^ | | Packet | 261 | | | | P | 262 | +--------+ | | 263 | | | 264 +---------------------------------------------------------------+ 266 Figure 3: Packet P at node C 268 Fourth, only node I maintains per-flow state for packet P. The entire 269 program of topological and service instructions to be executed by the 270 SR domain on packet P is encoded by the ingress edge router I in the 271 SR header in the form of a list of segments where each segment 272 identifies a specific instruction. No further per-flow state is 273 required along the packet path. The per-flow state is in the SR 274 header and travels with the packet. Intermediate nodes only hold 275 states related to the IGP global node segments and the local IGP 276 adjacency segments. These segments are not per-flow specific and 277 hence scale very well. Typically, an intermediate node would 278 maintain in the order of 100's to 1000's global node segments and in 279 the order of 10's to 100 of local adjacency segments. Typically the 280 SR IGP forwarding table is expected to be much less than 10000 281 entries. 283 Fifth, the SR header is inserted at the entrance to the domain and 284 removed at the exit of the operator domain. For security reasons, 285 the operator can forbid anyone outside its domain to use its intra- 286 domain SR capability. 288 1.2. Terminology 290 The following terminology is defined: 292 +---------------+---------------------------------------------------+ 293 | Term | Definition | 294 +---------------+---------------------------------------------------+ 295 | Segment | A segment that identifies an instruction | 296 +---------------+---------------------------------------------------+ 297 | SID | A 32-bit identification for a segment | 298 +---------------+---------------------------------------------------+ 299 | Segment List | Ordered list of segments encoding the topological | 300 | | and service source route of the packet | 301 +---------------+---------------------------------------------------+ 302 | Active | The segment that MUST be used by the receiving | 303 | Segment | router to process the packet. It is identified | 304 | | by the pointer | 305 +---------------+---------------------------------------------------+ 306 | SR-Pointer or | In the SR header, it indicates the active segment | 307 | pointer | in the segment list | 308 +---------------+---------------------------------------------------+ 309 | Global | The related instruction is supported by all the | 310 | Segment | SR-capable nodes in the local domain | 311 +---------------+---------------------------------------------------+ 312 | SRGB | SR Global Block: the set of global segments in | 313 | | the local SR domain | 314 +---------------+---------------------------------------------------+ 315 | Local Segment | The related instruction is supported only by the | 316 | | node originating it | 317 | IGP Segment | The generic names for a segment attached to a | 318 | or IGP SID | piece of information advertised by a link-state | 319 | | IGP, e.g. an IGP prefix or an IGP adjacency | 320 +---------------+---------------------------------------------------+ 321 | IGP-Prefix | An IGP-Prefix Segment is an IGP segment attached | 322 | Segment or | to an IGP prefix. An IGP-Prefix Segment is | 323 | Prefix-SID | always global within the SR/IGP domain and | 324 | | identifies the ECMP-aware shortest-path computed | 325 | | by the IGP to the related prefix. The Prefix-SID | 326 | | is the SID of the IGP-Prefix Segment | 327 +---------------+---------------------------------------------------+ 328 | IGP-Node | An IGP-Node Segment is a an IGP-Prefix Segment | 329 | Segment or | which identifies a specific router (e.g. a | 330 | Node Segment | loopback). The terms "Node Segment" or Node-SID" | 331 | or Node-SID | are often used as an abbreviation | 332 +---------------+---------------------------------------------------+ 333 | IGP-Anycast | An IGP-Anycast Segment is an IGP-prefix segment | 334 | Segment or | which does not identify a specific router, but a | 335 | Anycast | set of routers. The terms "Anycast Segment" or | 336 | Segment or | "Anycast-SID" are often used as an abbreviation | 337 | Anycast-SID | | 338 +---------------+---------------------------------------------------+ 339 | IGP-Adjacency | An IGP-Adjacency Segment is an IGP segment | 340 | Segment or | attached to an unidirectional adjacency or a set | 341 | Adjacency | of unidirectional adjacencies. An IGP-Adjacency | 342 | Segment or | Segment is local to the node which advertises it | 343 | Adj-SID | | 344 +---------------+---------------------------------------------------+ 345 | SRDB | The SR Database. Each entry is indexed by a | 346 | | segment value. Each entry must list the SR | 347 | | header operation to apply and the next-hop to | 348 | | forward the packet to | 349 +---------------+---------------------------------------------------+ 350 | SR Header | Push, Continue and Next are operations applied on | 351 | Operation | the SR segment list | 352 +---------------+---------------------------------------------------+ 354 Table 1: Segment Routing Terminology 356 1.3. Properties 358 Assuming a packet flow F entering an SR domain at ingress SR edge 359 router I, the properties offered by the SR architecture are: 361 Per-Flow state for F is only maintained by node I. 363 Any topological path through the SR domain can be enforced. 365 Any chain of services through the SR domain can be enforced. 367 Any mix of topological paths and chain of services can be 368 enforced. 370 Any node along the flow path can determine where flow entered the 371 SR domain, how it got up to that node, where it will exit the SR 372 domain and how it will get there. 374 1.4. Companion Documents 376 This document defines the SR architecture, its routing model, the 377 IGP-based segments and the service segments. 379 Use cases are described in 380 [I-D.filsfils-rtgwg-segment-routing-use-cases]. 382 The support of SR by the MPLS dataplane is documented in 383 [draft-filsfils-spring-segment-routing-mpls-00]. 385 The support of SR on the Ipv6 dataplane will be documented in a 386 future document. 388 IS-IS protocol extensions for Segment Routing are described in 389 [I-D.previdi-isis-segment-routing-extensions]. 391 OSPF protocol extensions for Segment Routing are described in 392 [I-D.psenak-ospf-segment-routing-extensions] and 393 [I-D.psenak-ospf-segment-routing-ospfv3-extension]. 395 The FRR solution for SR is documented in [I-D.francois-sr-frr]. 397 The PCEP protocol extensions for Segment Routing are defined in 398 [I-D.sivabalan-pce-segment-routing]. 400 The interaction between SR/MPLS with other MPLS Signaling planes is 401 documented in [draft-filsfils-spring-segment-routing-ldp-interop-00]. 403 1.5. Relationship with MPLS and IPv6 405 The source routing model is inherited from the one proposed by and 406 [RFC1940] and [RFC2460]. 408 The notion of abstract segment identifier which can represent any 409 instruction is inherited from MPLS ([RFC3031]). 411 Deployment experiences has shown the need to limit the number of per- 412 flow states maintained in the network while preserving information on 413 the topological and service journey of a packet (e.g. the ingress to 414 the domain for accounting/billing purpose). 416 The main differences from the IPv6 source route model are: 418 The source route is encoded as an ordered list of segments instead 419 of IP addresses. 421 A segment can represent any instruction either a service or a 422 topological path. Topologically, the path to an IP address is 423 often limited to the shortest-path to that address. A segment can 424 represent any path (e.g. an adjacency segment forces a packet to a 425 nexthop through a specific adjacency even if the shortest-path to 426 the next-hop does not use that adjacency). 428 The ingress and egress egde routers are identified and always 429 available, allowing for interesting accounting and policy 430 applications. 432 The source route functionality cannot be controlled from outside 433 the SR domain. 435 The main differences from the current MPLS model are: 437 Globally indexed segments are introduced (e.g. IGP Prefix 438 segments). 440 LDP and RSVP MPLS signaling protocols are not required. If 441 present, SR can coexist and interwork with LDP and RSVP. 442 [draft-filsfils-spring-segment-routing-ldp-interop-00]. 444 Per-flow states are only maintained at the ingress edge router. 446 SR can be instantiated on the IPv6 dataplane. A future document will 447 detail the new routing extension header which carry all the elements 448 of the abstract SR header. All the SR properties are preserved. 450 SR can be instantiated on the MPLS dataplane as detailed in 451 [draft-filsfils-spring-segment-routing-mpls-00]. 453 2. Abstract Routing Model 455 Segment Routing (SR) leverages the source routing paradigm. 457 At the entrance of the SR domain, the ingress SR edge router pushes 458 the SR header on top of the packet. At the exit of the SR domain, 459 the egress SR edge router removes the SR header. 461 The SR header contains an ordered list of segments, a pointer 462 identifying the next segment to process and the identifications of 463 the ingress and egress SR edge routers on the path of this packet. 464 The pointer identifies the segment that MUST be used by the receiving 465 router to process the packet. This segment is called the active 466 segment. 468 A property of the architecture is that the entire source route of the 469 packet, including the identity of the ingress and egress edge routers 470 is always available with the packet. This allows for interesting 471 accounting and service applications. 473 We define three SR-header operations: 475 "PUSH": an SR header is pushed on an IP packet, or additional 476 segments are added at the head of the segment list. The pointer 477 is moved to the first entry of the added segments. 479 "NEXT": the active segment is completed, the pointer is moved to 480 the next segment in the list. 482 "CONTINUE": the active segment is not completed, the pointer is 483 left unchanged. 485 In the future, other SR-header management operations may be defined. 487 As the packet travels through the SR domain, the pointer is 488 incremented through the ordered list of segments and the source route 489 encoded by the SR ingress edge node is executed. 491 A node processes an incoming packet according to the instruction 492 associated with the active segment. 494 Any instruction might be associated with a segment: for example, an 495 intra or inter-domain topological strict or loose forwarding 496 instruction, a service instruction, etc. 498 At minimum, a segment instruction must define two elements: the 499 identity of the next-hop to forward the packet to (this could be the 500 same node or a context within the node) and which SR-header 501 management operation to execute. 503 Each segment is known in the network through a Segment Identifier 504 (SID), a value allocated from the 32-bit Segment IDentifier space. 505 The first 16 values are reserved. The terms "segment" and "SID" are 506 interchangeable. 508 Within an SR domain, all the SR-capable nodes are configured with the 509 Segment Routing Global Block (SRGB). The SRGB is a subset of the 32- 510 bit SID space. SRGB can be a non-contiguous set of segments. 512 All global segments must be allocated from the SRGB. Any SR capable 513 node MUST be able to process any global segment advertised by any 514 other node within the SR domain. 516 Any segment outside the SRGB has a local significance and is called a 517 "local segment". An SR-capable node MUST be able to process the 518 local segments it originates. An SR-capable node MUST NOT support 519 the instruction associated with a local segment originated by a 520 remote node. 522 2.1. Traffic Engineering with SR 524 An SR Traffic Engineering policy is composed of two elements: a flow 525 classification and a segment-list to prepend on the packets of the 526 flow. 528 In the SR architecture, this per-flow state only exists at the 529 ingress egde router whether the policy is defined and the SR header 530 is pushed. 532 It is outside the scope of the document to define the process that 533 leads to the instantiation at a node N of an SR Traffic Engineering 534 policy. 536 [I-D.filsfils-rtgwg-segment-routing-use-cases] illustrates various 537 alternatives: 539 N is deriving this policy automatically (e.g. FRR). 541 N is provisioned explicitly by the operator. 543 N is provisioned by a stateful PCE server. 545 N is provisioned by the operator with a high-level policy which is 546 mapped into a path thanks to a local CSPF-based computation (e.g. 547 affinity/SRLG exclusion). 549 Any architecture that involves the insertion of information onto a 550 packet involves performance consideration. 551 [I-D.filsfils-rtgwg-segment-routing-use-cases]explains why the 552 majority of use-cases require very short segment-lists. 554 A stateful PCE server, which desires to instantiate at node N an SR 555 Traffic Engineering policy, collects the SR capability of node N such 556 as to ensure that the policy meets its capability 557 [I-D.sivabalan-pce-segment-routing]. 559 2.2. Segment Routing Database 561 The Segment routing Database (SRDB) is a set of entries where each 562 entry is identified by a segment value. The instruction associated 563 with each entry at least defines the identity of the next-hop to 564 which the packet should be forwarded and what operation should be 565 performed on the SR header (PUSH, CONTINUE, NEXT). 566 +---------+-----------+---------------------------------+ 567 | Segment | Next-Hop | SR Header operation | 568 +---------+-----------+---------------------------------+ 569 | Sk | M | CONTINUE | 570 | Sj | N | NEXT | 571 | Sl | NAT Srvc | NEXT | 572 | Sm | FW srvc | NEXT | 573 | Sn | Q | NEXT | 574 | etc. | etc. | etc. | 575 +---------+-----------+---------------------------------+ 577 Figure 4: SR Database 579 Each SR-capable node maintains its local SRDB. SRDB entries can 580 either derive from local policy or or from protocol segment 581 advertisement. The next section will detail segment advertisement by 582 IGP protocols." 584 3. Link-State IGP Segments 586 Within a link-state IGP domain, an SR-capable IGP node advertises 587 segments for its attached prefixes and adjacencies. These segments 588 are called IGP segments or IGP SIDs. They play a key role in the 589 Segment Routing architecture and use-cases 590 [I-D.filsfils-rtgwg-segment-routing-use-cases] as they enable the 591 expression of any topological path throughout the IGP domain. Such a 592 topological path is either expressed as a single IGP segment or a 593 list of multiple IGP segments. 595 In the first sub-section, we introduce a terminology for a set of IGP 596 segments which are very frequently seen in the SR use-cases. The 597 second sub-section details the IGP segment allocation and SRDB 598 construction rules. 600 3.1. Illustration 602 Assuming the network diagram of Figure 5 and the IP address and IGP 603 Segment allocation of Figure 6, the following examples can be 604 constructed. 605 +--------+ 606 / \ 607 R1-----R2----------R3-----R8 608 | \ / | 609 | +--R4--+ | 610 | | 611 +-----R5-----+ 613 Figure 5: IGP Segments - Illustration 615 +-----------------------------------------------------------+ 616 | IP address allocated by the operator: | 617 | 192.0.2.1/32 as a loopback of R1 | 618 | 192.0.2.2/32 as a loopback of R2 | 619 | 192.0.2.3/32 as a loopback of R3 | 620 | 192.0.2.4/32 as a loopback of R4 | 621 | 192.0.2.5/32 as a loopback of R5 | 622 | 192.0.2.8/32 as a loopback of R8 | 623 | 198.51.100.9/32 as an anycast loopback of R4 | 624 | 198.51.100.9/32 as an anycast loopback of R5 | 625 | | 626 | SRGB defined by the operator as 1000-5000 | 627 | | 628 | Global IGP SID allocated by the operator: | 629 | 1001 allocated to 192.0.2.1/32 | 630 | 1002 allocated to 192.0.2.2/32 | 631 | 1003 allocated to 192.0.2.3/32 | 632 | 1004 allocated to 192.0.2.4/32 | 633 | 1008 allocated to 192.0.2.8/32 | 634 | 2009 allocated to 198.51.100.9/32 | 635 | | 636 | Local IGP SID allocated dynamically by R2 | 637 | for its "north" adjacency to R3: 9001 | 638 | for its "north" adjacency to R3: 9003 | 639 | for its "south" adjacency to R3: 9002 | 640 | for its "south" adjacency to R3: 9003 | 641 +-----------------------------------------------------------+ 643 Figure 6: IGP Address and Segment Allocation - Illustration 645 3.1.1. Example 1 647 R1 may send a packet P1 to R8 simply by pushing an SR header with 648 segment list {1008}. 650 1008 is a global IGP segment attached to the IP prefix 192.0.2.8/32. 651 Its semantic is global within the IGP domain: any router forwards a 652 packet received with active segment 1008 to the next-hop along the 653 ECMP-aware shortest-path to the related prefix. 655 In conclusion, the path followed by P1 is R1-R2--R3-R8. The ECMP- 656 awareness ensures that the traffic be load-shared between any ECMP 657 path, in this case the two north and south links between R2 and R3. 659 3.1.2. Example 2 661 R1 may send a packet P2 to R8 by pushing an SR header with segment 662 list {1002, 9001, 1008}. 664 1002 is a global IGP segment attached to the IP prefix 192.0.2.2/32. 665 Its semantic is global within the IGP domain: any router forwards a 666 packet received with active segment 1002 to the next-hop along the 667 shortest-path to the related prefix. 669 9001 is a local IGP segment attached by node R2 to its north link to 670 R3. Its semantic is local to node R2: R2 switches a packet received 671 with active segment 9001 towards the north link to R3. 673 In conclusion, the path followed by P2 is R1-R2-north-link-R3-R8. 675 3.1.3. Example 3 677 R1 may send a packet P3 along the same exact path as P1 using a 678 different segment list {1002, 9003, 1008}. 680 9003 is a local IGP segment attached by node R2 to both its north and 681 south links to R3. Its semantic is local to node R2: R2 switches a 682 packet received with active segment 9003 towards either the north or 683 south links to R3 (e.g. per-flow loadbalancing decision). 685 In conclusion, the path followed by P3 is R1-R2-any-link-R3-R8. 687 3.1.4. Example 4 689 R1 may send a packet P4 to R8 while avoiding the links between R2 and 690 R3 by pushing an SR header with segment list {1004, 1008}. 692 1004 is a global IGP segment attached to the IP prefix 192.0.2.4/32. 694 Its semantic is global within the IGP domain: any router forwards a 695 packet received with active segment 1004 to the next-hop along the 696 shortest-path to the related prefix. 698 In conclusion, the path followed by P4 is R1-R2-R4-R3-R8. 700 3.1.5. Example 5 702 R1 may send a packet P5 to R8 while avoiding the links between R2 and 703 R3 while still benefitting from all the remaining shortest paths (via 704 R4 and R5) by pushing an SR header with segment list {2009, 1008}. 706 2009 is a global IGP segment attached to the anycast IP prefix 707 198.51.100.9/32. Its semantic is global within the IGP domain: any 708 router forwards a packet received with active segment 2009 to the 709 next-hop along the shortest-path to the related prefix. 711 In conclusion, the path followed by P5 is either R1-R2-R4-R3-R8 or 712 R1-R2-R5-R3-R8 . 714 3.2. IGP Segment Terminology 716 3.2.1. IGP Segment, IGP SID 718 The terms "IGP Segment" and "IGP SID" are the generic names for a 719 segment attached to a piece of information advertised by a link-state 720 IGP, e.g. an IGP prefix or an IGP adjacency. 722 The IGP signaling extension to advertise an IGP segment includes the 723 G-Flag indicating whether the IGP segment is global or local. 724 IGP-SID 725 +--+--+ 726 / | \ 727 Prefix-SID x Adj-SID 728 +----+---+ 729 / | \ 730 Node-SID y Anycast-SID 732 Figure 7: IGP SID Terminology 734 The IGP Segment terminology is introduced to ease the documentation 735 of SR use-cases and hence does not propose a name for any possible 736 variation of IGP segment supported by the architecture. For example, 737 y in Figure 7 could represent a local IGP segment attached to an IGP 738 Prefix. This variation, while supported by the SR architecture is 739 not seen in the SR use-cases and hence does not receive a specific 740 name. 742 In Figure 5 and Figure 6, SIDs 1001, 1002, 1003, 1004, 1008, 2009, 743 9001, 9002 and 9003 are called IGP SIDs. 745 3.2.2. IGP-Prefix Segment, Prefix-SID 747 An IGP-Prefix Segment is an IGP segment attached to an IGP prefix. 748 An IGP-Prefix Segment is always global within the SR/IGP domain and 749 identifies the ECMP-aware shortest-path computed by the IGP to the 750 related prefix. The G-Flag MUST be set. The Prefix-SID is the SID 751 of the IGP-Prefix Segment. 753 A packet injected anywhere within the SR/IGP domain with an active 754 Prefix-SID will be forwarded along the shortest-path to that prefix. 756 The IGP signaling extension for IGP-Prefix segment includes the 757 P-Flag. A Node N advertising a Prefix-SID SID-R for its attached 758 prefix R resets the P-Flag to allow its connected neighbors to 759 perform the NEXT operation while processing SID-R. This behavior is 760 equivalent to Pen-ultimate Hop Popping in MPLS. When set, the 761 neighbors of N must perform the CONTINUE operation while processing 762 SID-R. 764 While the architecture allows to attach a local segment to an IGP 765 prefix, we specifically assume that when the terms "IGP-Prefix 766 Segment" and "Prefix-SID" are used then the segment is global (the 767 SID is allocated from the SRGB). This is consistent with 768 [I-D.filsfils-rtgwg-segment-routing-use-cases] as all the described 769 use-cases require global segments attached to IGP prefix. 771 In Figure 5 and Figure 6, SIDs 1001, 1002, 1003, 1004, 1008, 2009 are 772 called Prefix-SIDs. 774 3.2.3. IGP-Node Segment, Node-SID 776 An IGP-Node Segment is a an IGP-Prefix Segment which identifies a 777 specific router (e.g. a loopback). The terms "Node Segment" or 778 "Node-SID" are often used as an abbreviation. 780 A "Node Segment" or "Node-SID" is fundamental to the SR architecture. 781 From anywhere in the network, it enforces the ECMP-aware shortest- 782 path forwarding of the packet towards the related node as explained 783 in [I-D.filsfils-rtgwg-segment-routing-use-cases]. 785 In Figure 5 and Figure 6, SIDs 1001, 1002, 1003, 1004 and 1008 are 786 called Node-SIDs. 788 3.2.4. IGP-Anycast Segment, Anycast SID 790 An IGP-Anycast Segment is an IGP-prefix segment which does not 791 identify a specific router, but a set of routers. The terms "Anycast 792 Segment" or "Anycast-SID" are often used as an abbreviation. 794 An "Anycast Segment" or "Anycast SID" enforces the ECMP-aware 795 shortest-path forwarding towards the closest node of the anycast set. 796 This is useful to express macro-engineering policies as described in 797 [I-D.filsfils-rtgwg-segment-routing-use-cases]. 799 In Figure 5 and Figure 6, SID 2009 is called Anycast SID. 801 3.2.5. IGP-Adjacency Segment, Adj-SID 803 An IGP-Adjacency Segment is an IGP segment attached to an 804 unidirectional adjacency or a set of unidirectional adjacencies. An 805 IGP-Adjacency Segment is local to the node which advertises it. The 806 SID of the IGP-Adjacency Segment is called the Adj-SID. The G-Flag 807 must be reset. 809 The adjacency is formed by the local node (i.e.: the node advertising 810 the adjacency in the IGP) and the remote node (i.e.: the other end of 811 the adjacency). The local node MUST be an IGP node. The remote node 812 MAY be: 814 An adjacent IGP node (i.e.: an IGP neighbor). 816 A non-adjacent neighbor (e.g.: a Forwarding Adjacency, [RFC4206]). 818 A virtual neighbor outside the IGP domain (e.g.: an interface 819 connecting another AS) as defined in [RFC5316]. 821 A packet injected anywhere within the SR/IGP domain with a segment 822 list {SN, SNL}, where SN is the Node-SID of node N and SNL is an Adj- 823 Sid attached by node N to its adjacency over link L, will be 824 forwarded along the shortest-path to N and then be switched by N, 825 without any IP shortest-path consideration, towards link L. If the 826 Adj-Sid identifies a set of adjacencies, then the node N load- 827 balances the traffic along the various members of the set. 829 An "IGP Adjacency Segment" or "Adj-SID" enforces the switching of the 830 packet from a note towards a defined interface or set of interfaces. 831 This is key to theoretically prove that any path can be expressed as 832 a list of segments as explained in 833 [I-D.filsfils-rtgwg-segment-routing-use-cases]. 835 In Figure 5 and Figure 6, SIDs 9001, 9002 and 9003 are called Adj- 836 SIDs. 838 3.2.6. Finally 840 Figure 8 summarizes the different terms that can be used to refer to 841 the SID's used in the example illustrated by Figure 5 and Figure 6. 842 "Y" means that the term can be used to refer to the SID, "N" means 843 that the term cannot be used to refer to the SID. 844 +---------------------------------------------------------------+ 845 | SID | IGP SID | Prefix-SID | Node-SID| Anycast SID| Adj-SID | 846 | Value | | | | | | 847 +---------------------------------------------------------------+ 848 | 1001 | Y | Y | Y | N | N | 849 | 1002 | Y | Y | Y | N | N | 850 | 1003 | Y | Y | Y | N | N | 851 | 1004 | Y | Y | Y | N | N | 852 | 1005 | Y | Y | Y | N | N | 853 | 1008 | Y | Y | Y | N | N | 854 | 2009 | Y | Y | N | Y | N | 855 | 9001 | Y | N | N | N | Y | 856 | 9002 | Y | N | N | N | Y | 857 | 9003 | Y | N | N | N | Y | 858 +---------------------------------------------------------------+ 860 Figure 8: Terminology Example 862 3.3. IGP Segment Allocation, Advertisement and SRDB Maintenance 864 3.3.1. Prefix-SID 866 Multiple Prefix-SID's may be allocated to the same IGP Prefix (e.g. 867 for class of service purpose). Typically a single Prefix-SID is 868 allocated to an IGP Prefix. 870 A Prefix-SID is allocated from the SRGB according to a similar 871 process to IP address allocation. Typically the Prefix-SID is 872 allocated by policy by the operator (or NMS) and the SID very rarely 873 changes. 875 The allocation process MUST NOT allocate the same Prefix-SID to 876 different IP prefixes. 878 If a node learns a Prefix-SID having a value that falls outside the 879 locally configured SRGB range, then the node MUST NOT use the Prefix- 880 SID and SHOULD issue an error log warning for misconfiguration. 882 The required IGP protocol extensions are defined in 883 [I-D.previdi-isis-segment-routing-extensions], 885 [I-D.psenak-ospf-segment-routing-extensions] and 886 [I-D.psenak-ospf-segment-routing-ospfv3-extension]. 888 A node N attaching a Prefix-SID SID-R to its attached prefix R MUST 889 maintain the following SRDB entry: 890 Incoming Active Segment: SID-R 891 Ingress Operation: NEXT 892 Egress interface: NULL 894 A remote node M MUST maintain the following SRDB entry for any 895 learned Prefix-SID SID-R attached to IP prefix R: 896 Incoming Active Segment: SID-R 897 Ingress Operation: 898 If the next-hop of R is the originator of R 899 and instructed to remove the active segment: NEXT 900 Else: CONTINUE 901 Egress interface: the interface towards the next-hop along 902 the shortest-path to prefix R. 904 3.3.2. Adj-SID 906 The Adjacency Segment SID (Adj-SID) identifies a unidirectional 907 adjacency or a set of unidirectional adjacencies. 908 A node SHOULD allocate one Adj-SIDs for each of its adjacencies. 909 A node MAY allocate multiple Adj-SIDs to the same adjacency. 910 A node MAY allocate the same Adj-SID to multiple adjacencies. 912 Adjacency suppression MUST NOT be performed by the IGP. 914 A node MUST install an SRDB entry for any Adj-SID of value V attached 915 to data-link L: 916 Incoming Active Segment: V 917 Operation: NEXT 918 Egress Interface: L 920 When associated to a Forwarding Adjacency ([RFC4206]), the Adj-SID 921 MAY also include the necessary information in order to describe the 922 path to the remote end of the Forwarding Adjacency in the form of an 923 Explicit Route Object. 925 The Adj-SID implies, from the router advertising it, the forwarding 926 of the packet through the adjacency identified by the Adj-SID, 927 regardless its IGP/SPF cost. In other words, the use of Adjacency 928 Segments overrides the routing decision made by SPF algorithm. 930 3.3.2.1. Parallel Adjacencies 932 Adj-SIDs can be used in order to represent a set of parallel 933 interfaces between two adjacent routers. For example, SID 9003 in 934 figures 5 and 6 identify the set of interfaces between R2 and R3. 936 A node MUST install an SRDB entry for any locally originated 937 Adjacency Segment (Adj-SID) of value W attached to a set of link B 938 with: 939 Incoming Active Segment: W 940 Ingress Operation: NEXT 941 Egress interface: loadbalance between any data-link within set B 943 3.3.2.2. LAN Adjacency Segments 945 In LAN subnetworks, link-state protocols define the concept of 946 Designated Router (DR, in OSPF) or Designated Intermediate System 947 (DIS, in IS-IS) that conduct flooding in broadcast subnetworks and 948 that describe the LAN topology in a special routing update (OSPF 949 Type2 LSA or IS-IS Pseudonode LSP). 951 The difficulty with LANs is that each router only advertises its 952 connectivity to the DR/DIS and not to each other individual nodes in 953 the LAN. Therefore, additional protocol mechanisms (IS-IS and OSPF) 954 are necessary in order for each router in the LAN to advertise an 955 Adj-SID associated to each neighbor in the LAN. These extensions are 956 defined in [I-D.previdi-isis-segment-routing-extensions], 957 [I-D.psenak-ospf-segment-routing-extensions] and 958 [I-D.psenak-ospf-segment-routing-ospfv3-extension]. 960 3.3.2.3. External Adjacencies Considerations 962 IGPs have been extended in order to advertise virtual adjacencies 963 that represent external links ([RFC5316]). 965 Segment Routing allows to allocate an Adj-SID to these external 966 links. 968 AS1 ) ( AS2 969 IGP-1 ) eBGP ( IGP-2 970 ) ( 971 B------C--)-------(--F-----G 972 / | ) ( | | 973 S---A/ | ) ( | | 974 \ | ) ( | | 975 \D------E--)-------(--H-----I----Z 976 ) ( 977 ) ( 979 Figure 9: External Adjacency Example 981 In the diagram above, C advertises in the IGP an adjacency to peer F 982 of AS2 together with an associated Adj-SID. When S wants to force an 983 inter-domain path to Z via the peering link CF, S encapsulates the 984 packets with the list {Prefix-SID(C), Adj-SID(C,F, AS2)}. 986 [I-D.filsfils-rtgwg-segment-routing-use-cases] provides an external- 987 adjacency use-case. 989 3.4. Inter-Area Considerations 991 In the following example diagram we assume an IGP deployed using 992 areas and where SR has been deployed. 993 ! ! 994 ! ! 995 B------C-----F----G-----K 996 / | | | 997 S---A/ | | | 998 \ | | | 999 \D------I----------J-----L----Z (192.0.2.1/32, Node-SID: 150) 1000 ! ! 1001 Area-1 ! Backbone ! Area 2 1002 ! area ! 1004 Figure 10: Inter-Area Topology Example 1006 In area 2, node Z allocates Node-SID 150 to his local prefix 1007 192.0.2.1/32. ABRs G and J will propagate the prefix into the 1008 backbone area by creating a new instance of the prefix according to 1009 normal inter-area/level IGP propagation rules. 1011 Nodes C and I will apply the same behavior when leaking prefixes from 1012 the backbone area down to area 1. Therefore, node S will see prefix 1013 192.0.2.1/32 with Prefix-SID 150 and advertised by nodes C and I. 1015 It therefore results that a Prefix-SID remains attached to its 1016 related IGP Prefix through the inter-area process. 1018 When node S sends traffic to 192.0.2.1/32, it pushes Node-SID(150) as 1019 active segment and forward it to A. 1021 When packet arrives at ABR I (or C), the ABR forwards the packet 1022 according to the active segment (Node-SID(150)). Forwarding 1023 continues across area borders, using the same Node-SID(150), until 1024 the packet reaches its destination. 1026 When an ABR propagates a prefix from one area to another it MUST set 1027 the R-Flag. 1029 3.5. IGP Mirroring Context Segment 1031 It is beneficial for an IGP node to be able to advertise its ability 1032 to process traffic originally destined to another IGP node, called 1033 the Mirrored node and identified by an IP address or a Node-SID, 1034 provided that a "Mirroring Context" segment be inserted in the 1035 segment list prior to any service segment local to the mirrored node. 1037 [I-D.filsfils-rtgwg-segment-routing-use-cases] illustrates such a 1038 use-case where two IGP nodes offer the same set of services (e.g. 1039 BGP VPN) and mirror each other upon their failure. A similar 1040 behavior is described in [I-D.minto-rsvp-lsp-egress-fast-protection]. 1042 IS-IS and OSPF Router Capability extensions are described in 1043 [I-D.previdi-isis-segment-routing-extensions], 1044 [I-D.psenak-ospf-segment-routing-extensions] and 1045 [I-D.psenak-ospf-segment-routing-ospfv3-extension]. 1047 4. Service Segments 1049 A service segment refers to a service offered by a node (e.g. 1050 firewall, vpn, etc.). 1052 Further informations will be included in future revisions. 1054 5. OAM 1056 SR offers an interesting capability to monitor SR domains: 1058 Any path can be monitored by setting the segment list accordingly. 1060 A path can be expressed with ECMP-awareness or not. 1062 The probe travels along the desired path while staying at the 1063 forwarding level. 1065 A monitoring system is able to check any element of the entire SR 1066 domain, even if it located multiple hops away. 1068 Some elements of the SR/OAM functionality will require 1069 standardization and a related independent draft will eventually be 1070 submitted. 1072 SR/OAM use-cases are described in 1073 [I-D.filsfils-rtgwg-segment-routing-use-cases]. 1075 6. Multicast 1077 The text will be added in future revision. 1079 7. IANA Considerations 1081 TBD 1083 8. Manageability Considerations 1085 TBD 1087 9. Security Considerations 1089 TBD 1091 10. Acknowledgements 1093 We would like to thank Dave Ward, Dan Frost, Stewart Bryant, Pierre 1094 Francois, Thomas Telkamp, Les Ginsberg, Ruediger Geib and Hannes 1095 Gredler for their contribution to the content of this document. 1097 11. References 1098 11.1. Normative References 1100 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1101 Requirement Levels", BCP 14, RFC 2119, March 1997. 1103 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1104 (IPv6) Specification", RFC 2460, December 1998. 1106 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 1107 Label Switching Architecture", RFC 3031, January 2001. 1109 [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) 1110 Hierarchy with Generalized Multi-Protocol Label Switching 1111 (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. 1113 [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in 1114 Support of Inter-Autonomous System (AS) MPLS and GMPLS 1115 Traffic Engineering", RFC 5316, December 2008. 1117 11.2. Informative References 1119 [I-D.filsfils-rtgwg-segment-routing-use-cases] 1120 Filsfils, C., Francois, P., Previdi, S., Decraene, B., 1121 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 1122 Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, 1123 "Segment Routing Use Cases", 1124 draft-filsfils-rtgwg-segment-routing-use-cases-01 (work in 1125 progress), July 2013. 1127 [I-D.francois-sr-frr] 1128 Francois, P., Filsfils, C., Bashandy, A., Previdi, S., and 1129 B. Decraene, "Segment Routing Fast Reroute", 1130 draft-francois-sr-frr-00 (work in progress), July 2013. 1132 [I-D.minto-rsvp-lsp-egress-fast-protection] 1133 Jeganathan, J., Gredler, H., and Y. Shen, "RSVP-TE LSP 1134 egress fast-protection", 1135 draft-minto-rsvp-lsp-egress-fast-protection-02 (work in 1136 progress), April 2013. 1138 [I-D.previdi-isis-segment-routing-extensions] 1139 Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., and 1140 S. Litkowski, "IS-IS Extensions for Segment Routing", 1141 draft-previdi-isis-segment-routing-extensions-02 (work in 1142 progress), July 2013. 1144 [I-D.psenak-ospf-segment-routing-extensions] 1145 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., and R. 1147 Shakir, "OSPF Extensions for Segment Routing", 1148 draft-psenak-ospf-segment-routing-extensions-02 (work in 1149 progress), July 2013. 1151 [I-D.psenak-ospf-segment-routing-ospfv3-extension] 1152 Psenak, P. and S. Previdi, "OSPFv3 Extensions for Segment 1153 Routing", October 2013. 1155 [I-D.sivabalan-pce-segment-routing] 1156 Sivabalan, S., Medved, J., Filsfils, C., Crabbe, E., and 1157 R. Raszuk, "PCEP Extensions for Segment Routing", 1158 draft-sivabalan-pce-segment-routing-02 (work in progress), 1159 October 2013. 1161 [RFC1940] Estrin, D., Li, T., Rekhter, Y., Varadhan, K., and D. 1162 Zappala, "Source Demand Routing: Packet Format and 1163 Forwarding Specification (Version 1)", RFC 1940, May 1996. 1165 [draft-filsfils-spring-segment-routing-ldp-interop-00] 1166 Filsfils, C. and S. Previdi, "Segment Routing 1167 interoperability with LDP", October 2013. 1169 [draft-filsfils-spring-segment-routing-mpls-00] 1170 Filsfils, C. and S. Previdi, "Segment Routing with MPLS 1171 data plane", October 2013. 1173 Authors' Addresses 1175 Clarence Filsfils (editor) 1176 Cisco Systems, Inc. 1177 Brussels, 1178 BE 1180 Email: cfilsfil@cisco.com 1182 Stefano Previdi (editor) 1183 Cisco Systems, Inc. 1184 Via Del Serafico, 200 1185 Rome 00142 1186 Italy 1188 Email: sprevidi@cisco.com 1189 Ahmed Bashandy 1190 Cisco Systems, Inc. 1191 170, West Tasman Drive 1192 San Jose, CA 95134 1193 US 1195 Email: bashandy@cisco.com 1197 Bruno Decraene 1198 Orange 1199 FR 1201 Email: bruno.decraene@orange.com 1203 Stephane Litkowski 1204 Orange 1205 FR 1207 Email: stephane.litkowski@orange.com 1209 Martin Horneffer 1210 Deutsche Telekom 1211 Hammer Str. 216-226 1212 Muenster 48153 1213 DE 1215 Email: Martin.Horneffer@telekom.de 1217 Igor Milojevic 1218 Telekom Srbija 1219 Takovska 2 1220 Belgrade 1221 RS 1223 Email: igormilojevic@telekom.rs 1225 Rob Shakir 1226 British Telecom 1227 London 1228 UK 1230 Email: rob.shakir@bt.com 1231 Saku Ytti 1232 TDC Oy 1233 Mechelininkatu 1a 1234 TDC 00094 1235 FI 1237 Email: saku@ytti.fi 1239 Wim Henderickx 1240 Alcatel-Lucent 1241 Copernicuslaan 50 1242 Antwerp 2018 1243 BE 1245 Email: wim.henderickx@alcatel-lucent.com 1247 Jeff Tantsura 1248 Ericsson 1249 300 Holger Way 1250 San Jose, CA 95134 1251 US 1253 Email: Jeff.Tantsura@ericsson.com 1255 Edward Crabbe 1256 Google, Inc. 1257 1600 Amphitheatre Parkway 1258 Mountain View, CA 94043 1259 US 1261 Email: edc@google.com