idnits 2.17.1 draft-filsfils-rtgwg-segment-routing-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document 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 (June 28, 2013) is 3955 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 (-03) exists of draft-minto-rsvp-lsp-egress-fast-protection-02 Summary: 2 errors (**), 0 flaws (~~), 2 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: December 30, 2013 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 June 28, 2013 25 Segment Routing Architecture 26 draft-filsfils-rtgwg-segment-routing-00 28 Abstract 30 Segment Routing (SR) leverages the source routing and tunneling 31 paradigms. A node steers a packet through a controlled set of 32 instructions, called segments, by prepending the packet with an SR 33 header. A segment can represent any instruction, topological or 34 service-based. A segment can have a local semantic to an SR node or 35 global within an SR domain. SR allows to enforce a flow through any 36 topological path and service chain while maintaining per-flow state 37 only at the ingress 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. It requires minor 41 extension to the existing link-state routing protocols. Segment 42 Routing can also be applied to IPv6 with a new type of routing 43 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 December 30, 2013. 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 . . . . . . . . . . . . . . . . . . . . . . . 13 96 3.1.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 14 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 . . . . . . . . . . . 17 106 3.2.5. IGP-Adjacency Segment, Adj-SID . . . . . . . . . . . . 18 107 3.2.6. Finally . . . . . . . . . . . . . . . . . . . . . . . 18 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 . . . . . . . . . . . . . . 22 114 4. Service Segments . . . . . . . . . . . . . . . . . . . . . . . 23 115 5. MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 116 6. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 117 7. OAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 118 8. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 24 119 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 120 10. Manageability Considerations . . . . . . . . . . . . . . . . . 25 121 11. Security Considerations . . . . . . . . . . . . . . . . . . . 25 122 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 123 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 124 13.1. Normative References . . . . . . . . . . . . . . . . . . . 25 125 13.2. Informative References . . . . . . . . . . . . . . . . . . 25 126 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 128 1. Introduction 130 In this section, we illustrate the key properties of the SR 131 architecture, introduce the companion documents to this note and 132 relate SR to the MPLS and IPv6 architectures. 134 Section 2 defines the SR abstract routing model. Section 3 defines 135 the IGP-based segments. Section 4 defines the Service Segments. 136 Section 5 and Section 6 define the instantiations of SR in MPLS and 137 IPv6. 139 1.1. Illustration 141 In the context of Figure 1 where all the links have the same IGP 142 cost, let us assume that a packet P enters the SR domain at an 143 ingress edge router I and that the operator requests the following 144 requirements for packet P: 146 The local service S offered by node B must be applied to packet P. 148 The links AB and CE cannot be used to transport the packet P. 150 Any node N along the journey of the packet should be able to 151 determine where the packet P entered the SR domain and where it 152 will exit. The intermediate node should be able to determine the 153 paths from the ingress edge router to itself, and from itsef to 154 the egress edge router. 156 Per-flow State for packet P should only be created at the ingress 157 edge router. 159 State for packet P can only be created at the ingress edge router. 161 The operator can forbid, for security reasons, anyone outside the 162 operator domain to exploit its intra-domain SR capabilities. 164 I---A---B---C---E 165 \ | / \ / 166 \ | / F 167 \|/ 168 D 170 Figure 1: An illustration of SR properties 172 All these properties may be realized by instructing the ingress SR 173 edge router I to push the following SR header on the packet P. 175 +---------------------------------------------------------------+ 176 | | | 177 | SR Header | | 178 | | | 179 | {SD, SB, SS, SF, SE}, Ptr, SI, SE | Transported | 180 | ^ | | Packet | 181 | | | | P | 182 | +---------------------+ | | 183 | | | 184 +---------------------------------------------------------------+ 186 Figure 2: Packet P at node I 188 The SR header contains a source route encoded as a list of segments 189 {SD, SB, SS, SF, SE}, a pointer (Ptr) and the identification of the 190 ingress and egress SR edge routers (segments SI and SE). 192 A segment is a 32-bit identification either for a topological 193 instruction or a service instruction. A segment can either be global 194 or local. The instruction associated with a global segment is 195 recognized and executed by any SR-capable node in the domain. The 196 instruction associated with a local segment is only supported by the 197 specific node that originates it. 199 Let us assume some ISIS/OSPF extensions to define a "Node Segment" as 200 a global instruction within the IGP domain to forward a packet along 201 the shortest path to the specified node. Let us further assume that 202 within the SR domain illustrated in Figure 1, segments SI, SD, SB, SE 203 and SF respectively identify IGP node segments to I, D, B, E and F. 205 Let us assume that node B identifies its local service S with local 206 segment SS. 208 With all of this in mind, let us describe the journey of the packet 209 P. 211 The packet P reaches the ingress SR edge router. I pushes the SR 212 header illustrated in Figure 2 and sets the pointer to the first 213 segment of the list (SD). 215 SD is an instruction recognized by all the nodes in the SR domain 216 which causes the packet to be forwarded along the shortest path to D. 218 Once at D, the pointer is incremented and the next segment is 219 executed (SB). 221 SB is an instruction recognized by all the nodes in the SR domain 222 which causes the packet to be forwarded along the shortest path to B. 224 Once at B, the pointer is incremented and the next segment is 225 executed (SS). 227 SS is an instruction only recognized by node B which causes the 228 packet to receive service S. 230 Once the service applied, the next segment is executed (SF) which 231 causes the packet to be forwarded along the shortest path to F. 233 Once at F, the pointer is incremented and the next segment is 234 executed (SE). 236 SE is an instruction recognized by all the nodes in the SR domain 237 which causes the packet to be forwarded along the shortest path to E. 239 E then removes the SR header and the packet continues its journey 240 outside the SR domain. 242 All of the requirements are met. 244 First, the packet P has not used links AB and CE: the shortest-path 245 from I to D is I-A-D, the shortest-path from D to B is D-B, the 246 shortest-path from B to F is B-C-F and the shortest-path from F to E 247 is F-E, hence the packet path through the SR domain is I-A-D-B-C-F-E 248 and the links AB and CE have been avoided. 250 Second, the service S supported by B has been applied on packet P. 252 Third, any node along the packet path is able to identify the service 253 and topological journey of the packet within the SR domain. For 254 example, node C receives the packet illustrated in Figure 3 and hence 255 is able to infer where the packet entered the SR domain (SI), how it 256 got up to itself {SD, SB, SS, SE}, where it will exit the SR domain 257 (SE) and how it will do so {SF, SE}. 258 +---------------------------------------------------------------+ 259 | | | 260 | SR Header | | 261 | | | 262 | {SD, SB, SS, SF, SE}, Ptr, SI, SE | Transported | 263 | ^ | | Packet | 264 | | | | P | 265 | +--------+ | | 266 | | | 267 +---------------------------------------------------------------+ 269 Figure 3: Packet P at node C 271 Fourth, only node I maintains per-flow state for packet P. The entire 272 program of topological and service instructions to be executed by the 273 SR domain on packet P is encoded by the ingress edge router I in the 274 SR header in the form of a list of segments where each segment 275 identifies a specific instruction. No further per-flow state is 276 required along the packet path. The per-flow state is in the SR 277 header and travels with the packet. Intermediate nodes only hold 278 states related to the IGP global node segments and the local IGP 279 adjacency segments. These segments are not per-flow specific and 280 hence scale very well. Typically, an intermediate node would 281 maintain in the order of 100's to 1000's global node segments and in 282 the order of 10's to 100 of local adjacency segments. Typically the 283 SR IGP forwarding table is expected to be much less than 10000 284 entries. 286 Fifth, the SR header is inserted at the entrance to the domain and 287 removed at the exit of the operator domain. For security reasons, 288 the operator can forbid anyone outside its domain to use its intra- 289 domain SR capability. 291 1.2. Terminology 293 The following terminology is defined: 295 +---------------+---------------------------------------------------+ 296 | Term | Definition | 297 +---------------+---------------------------------------------------+ 298 | Segment | A segment that identifies an instruction | 299 +---------------+---------------------------------------------------+ 300 | SID | A 32-bit identification for a segment | 301 +---------------+---------------------------------------------------+ 302 | Segment List | Ordered list of segments encoding the topological | 303 | | and service source route of the packet | 304 +---------------+---------------------------------------------------+ 305 | Active | The segment that MUST be used by the receiving | 306 | Segment | router to process the packet. It is identified | 307 | | by the pointer | 308 +---------------+---------------------------------------------------+ 309 | SR-Pointer or | In the SR header, it indicates the active segment | 310 | pointer | in the segment list | 311 +---------------+---------------------------------------------------+ 312 | Global | The related instruction is supported by all the | 313 | Segment | SR-capable nodes in the local domain | 314 +---------------+---------------------------------------------------+ 315 | SRGB | SR Global Block: the set of global segments in | 316 | | the local SR domain | 317 +---------------+---------------------------------------------------+ 318 | Local Segment | The related instruction is supported only by the | 319 | | node originating it | 320 | IGP Segment | The generic names for a segment attached to a | 321 | or IGP SID | piece of information advertised by a link-state | 322 | | IGP, e.g. an IGP prefix or an IGP adjacency | 323 +---------------+---------------------------------------------------+ 324 | IGP-Prefix | An IGP-Prefix Segment is an IGP segment attached | 325 | Segment or | to an IGP prefix. An IGP-Prefix Segment is | 326 | Prefix-SID | always global within the SR/IGP domain and | 327 | | identifies the ECMP-aware shortest-path computed | 328 | | by the IGP to the related prefix. The Prefix-SID | 329 | | is the SID of the IGP-Prefix Segment | 330 +---------------+---------------------------------------------------+ 331 | IGP-Node | An IGP-Node Segment is a an IGP-Prefix Segment | 332 | Segment or | which identifies a specific router (e.g. a | 333 | Node Segment | loopback). The terms "Node Segment" or Node-SID" | 334 | or Node-SID | are often used as an abbreviation | 335 +---------------+---------------------------------------------------+ 336 | IGP-Anycast | An IGP-Anycast Segment is an IGP-prefix segment | 337 | Segment or | which does not identify a specific router, but a | 338 | Anycast | set of routers. The terms "Anycast Segment" or | 339 | Segment or | "Anycast-SID" are often used as an abbreviation | 340 | Anycast-SID | | 341 +---------------+---------------------------------------------------+ 342 | IGP-Adjacency | An IGP-Adjacency Segment is an IGP segment | 343 | Segment or | attached to an unidirectional adjacency or a set | 344 | Adjacency | of unidirectional adjacencies. An IGP-Adjacency | 345 | Segment or | Segment is local to the node which advertises it | 346 | Adj-SID | | 347 +---------------+---------------------------------------------------+ 348 | SRDB | The SR Database. Each entry is indexed by a | 349 | | segment value. Each entry must list the SR | 350 | | header operation to apply and the next-hop to | 351 | | forward the packet to | 352 +---------------+---------------------------------------------------+ 353 | SR Header | Push, Continue and Next are operations applied on | 354 | Operation | the SR segment list | 355 +---------------+---------------------------------------------------+ 357 Table 1: Segment Routing Terminology 359 1.3. Properties 361 Assuming a packet flow F entering an SR domain at ingress SR edge 362 router I, the properties offered by the SR architecture are: 364 Per-Flow state for F is only maintained by node I. 366 Any topological path through the SR domain can be enforced. 368 Any chain of services through the SR domain can be enforced. 370 Any mix of topological paths and chain of services can be 371 enforced. 373 Any node along the flow path can determine where flow entered the 374 SR domain, how it got up to that node, where it will exit the SR 375 domain and how it will get there. 377 1.4. Companion Documents 379 This document defines the SR architecture, its routing model, the 380 IGP-based segments and the service segments. 382 Use cases are described in 383 [draft-filsfils-rtgwg-segment-routing-use-cases-00]. 385 IS-IS protocol extensions for Segment Routing are described in 386 [draft-previdi-isis-segment-routing-extensions-00]. 388 OSPF protocol extensions for Segment Routing are defined in 389 [draft-psenak-ospf-segment-routing-extensions-00]. 391 The PCEP protocol extensions for Segment Routing are defined in 392 [draft-msiva-pce-pcep-segment-routing-extensions-00]. 394 In the future, it is expected that Section 5 and Section 6 of this 395 document be removed and submitted as independent documents, 396 respectively as instantiations of SR in MPLS and IPv6. 398 In the future, we will submit a SR-FRR specific document. 400 1.5. Relationship with MPLS and IPv6 402 The source routing model is inherited from the one proposed by 403 [RFC2460]. 405 The notion of abstract segment identifier which can represent any 406 instruction is inherited from MPLS ([RFC3031]). 408 Deployment experiences has shown the need to limit the number of per- 409 flow states maintained in the network while preserving information on 410 the topological and service journey of a packet (e.g. the ingress to 411 the domain for accounting/billing purpose). 413 The main differences from the IPv6 source route model are: 415 The source route is encoded as an ordered list of segments instead 416 of IP addresses. 418 A segment can represent any instruction either a service or a 419 topological path. Topologically, the path to an IP address is 420 often limited to the shortest-path to that address. A segment can 421 represent any path (e.g. an adjacency segment forces a packet to a 422 nexthop through a specific adjacency even if the shortest-path to 423 the next-hop does not use that adjacency). 425 The ingress and egress egde routers are identified and always 426 available, allowing for interesting accounting and policy 427 applications. 429 The source route functionality cannot be controlled from outside 430 the SR domain. 432 The main differences from the MPLS model are: 434 Global segments are introduced (e.g. IGP node segments). 436 LDP and RSVP MPLS signaling protocols are not required. If 437 present, SR can coexist and interwork with LDP and 438 RSVP.[draft-filsfils-rtgwg-segment-routing-use-cases-00]. 440 Per-flow states are only maintained at the ingress edge router. 442 SR can be instantiated on the IPv6 dataplane. Section 6 details the 443 new routing extension header which carry all the elements of the 444 abstract SR header. All the SR properties are preserved. 446 SR can be instantiated on the MPLS dataplane. In Section 5, we 447 explain that the information present in the SR abstract header is 448 encoded as a stack of labels. The notion of pointer and full segment 449 list containing the full history of the path from ingress to egress 450 edge routers is thus lost in the MPLS instantiation of SR. However 451 all the other SR properties are preserved and especially the MPLS 452 dataplane can be reused without any change. 454 2. Abstract Routing Model 456 Segment Routing (SR) leverages the source routing and tunneling 457 paradigms. 459 At the entrance of the SR domain, the ingress SR edge router pushes 460 the SR header on top of the packet. At the exit of the SR domain, 461 the egress SR edge router removes the SR header. 463 The SR header contains an ordered list of segments, a pointer 464 identifying the next segment to process and the identifications of 465 the ingress and egress SR edge routers on the path of this packet. 466 The pointer identifies the segment that MUST be used by the receiving 467 router to process the packet. This segment is called the active 468 segment. 470 A property of the architecture is that the entire source route of the 471 packet, including the identity of the ingress and egress edge routers 472 is always available with the packet. This allows for interesting 473 accounting and service applications. 475 We define three SR-header operations: 477 "PUSH": an SR header is pushed on an IP packet, or additional 478 segments are added at the head of the segment list. The pointer 479 is moved to the first entry of the added segments. 481 "NEXT": the active segment is completed, the pointer is moved to 482 the next segment in the list. 484 "CONTINUE": the active segment is not completed, the pointer is 485 left unchanged. 487 In the future, other SR-header management operations may be defined. 489 As the packet travels through the SR domain, the pointer is 490 incremented through the ordered list of segments and the source route 491 encoded by the SR ingress edge node is executed. 493 A node processes an incoming packet according to the instruction 494 associated with the active segment. 496 Any instruction might be associated with a segment: for example, an 497 intra or inter-domain topological strict or loose forwarding 498 instruction, a service instruction, etc. 500 At minimum, a segment instruction must define two elements: the 501 identity of the next-hop to forward the packet to (this could be the 502 same node or a context within the node) and which SR-header 503 management operation to execute. 505 Each segment is known in the network through a Segment Identifier 506 (SID), a value allocated from the 32-bit Segment IDentifier space. 507 The first 16 values are reserved. The terms "segment" and "SID" are 508 interchangeable. 510 Within an SR domain, all the SR-capable nodes are configured with the 511 Segment Routing Global Block (SRGB). The SRGB is a subset of the 32- 512 bit SID space. SRGB can be a non-contiguous set of segments. 514 All global segments must be allocated from the SRGB. Any SR capable 515 node MUST be able to process any global segment advertised by any 516 other node within the SR domain. 518 Any segment outside the SRGB has a local significance and is called a 519 "local segment". An SR-capable node MUST be able to process the 520 local segments it originates. An SR-capable node MUST NOT support 521 the instruction associated with a local segment originated by a 522 remote node. 524 2.1. Traffic Engineering with SR 526 An SR Traffic Engineering policy is composed of two elements: a flow 527 classification and a segment-list to prepend on the packets of the 528 flow. 530 In the SR architecture, this per-flow state only exists at the 531 ingress egde router whether the policy is defined and the SR header 532 is pushed. 534 It is outside the scope of the document to define the process that 535 leads to the instantiation at a node N of an SR Traffic Engineering 536 policy. 538 [draft-filsfils-rtgwg-segment-routing-use-cases-00] illustrates 539 various alternatives: 541 N is deriving this policy automatically (e.g. FRR). 543 N is provisioned explicitly by the operator. 545 N is provisioned by a stateful PCE server. 547 N is provisioned by the operator with a high-level policy which is 548 mapped into a path thanks to a local CSPF-based computation (e.g. 549 affinity/SRLG exclusion). 551 Any architecture that involves the insertion of information onto a 552 packet involves performance consideration. 553 [draft-filsfils-rtgwg-segment-routing-use-cases-00]explains why the 554 majority of use-cases require very short segment-lists. 556 A stateful PCE server, which desires to instantiate at node N an SR 557 Traffic Engineering policy, collects the SR capability of node N such 558 as to ensure that the policy meets its capability 560 [draft-msiva-pce-pcep-segment-routing-extensions-00]. 562 2.2. Segment Routing Database 564 The Segment routing Database (SRDB) is a set of entries where each 565 entry is identified by a segment value. The instruction associated 566 with each entry at least defines the identity of the next-hop to 567 which the packet should be forwarded and what operation should be 568 performed on the SR header (PUSH, CONTINUE, NEXT). 569 +---------+-----------+---------------------------------+ 570 | Segment | Next-Hop | SR Header operation | 571 +---------+-----------+---------------------------------+ 572 | Sk | M | CONTINUE | 573 | Sj | N | NEXT | 574 | Sl | NAT Srvc | NEXT | 575 | Sm | FW srvc | NEXT | 576 | Sn | Q | NEXT | 577 | etc. | etc. | etc. | 578 +---------+-----------+---------------------------------+ 580 Figure 4: SR Database 582 Each SR-capable node maintains its local SRDB. SRDB entries can 583 either derive from local policy or or from protocol segment 584 advertisement. The next section will detail segment advertisement by 585 IGP protocols." 587 3. Link-State IGP Segments 589 Within a link-state IGP domain, an SR-capable IGP node advertises 590 segments for its attached prefixes and adjacencies. These segments 591 are called IGP segments or IGP SIDs. They play a key role in the 592 Segment Routing architecture and use-cases 593 [draft-filsfils-rtgwg-segment-routing-use-cases-00] as they enable 594 the expression of any topological path throughout the IGP domain. 595 Such a topological path is either expressed as a single IGP segment 596 or a list of multiple IGP segments. 598 In the first sub-section, we introduce a terminology for a set of IGP 599 segments which are very frequently seen in the SR use-cases. The 600 second sub-section details the IGP segment allocation and SRDB 601 construction rules. 603 3.1. Illustration 605 Assuming the network diagram of Figure 5 and the IP address and IGP 606 Segment allocation of Figure 6, the following examples can be 607 constructed. 608 +--------+ 609 / \ 610 R1-----R2----------R3-----R8 611 | \ / | 612 | +--R4--+ | 613 | | 614 +-----R5-----+ 616 Figure 5: IGP Segments - Illustration 618 +-----------------------------------------------------------+ 619 | IP address allocated by the operator: | 620 | 192.0.2.1/32 as a loopback of R1 | 621 | 192.0.2.2/32 as a loopback of R2 | 622 | 192.0.2.3/32 as a loopback of R3 | 623 | 192.0.2.4/32 as a loopback of R4 | 624 | 192.0.2.5/32 as a loopback of R5 | 625 | 192.0.2.8/32 as a loopback of R8 | 626 | 198.51.100.9/32 as an anycast loopback of R4 | 627 | 198.51.100.9/32 as an anycast loopback of R5 | 628 | | 629 | SRGB defined by the operator as 1000-5000 | 630 | | 631 | Global IGP SID allocated by the operator: | 632 | 1001 allocated to 192.0.2.1/32 | 633 | 1002 allocated to 192.0.2.2/32 | 634 | 1003 allocated to 192.0.2.3/32 | 635 | 1004 allocated to 192.0.2.4/32 | 636 | 1008 allocated to 192.0.2.8/32 | 637 | 2009 allocated to 198.51.100.9/32 | 638 | | 639 | Local IGP SID allocated dynamically by R2 | 640 | for its "north" adjacency to R3: 9001 | 641 | for its "north" adjacency to R3: 9003 | 642 | for its "south" adjacency to R3: 9002 | 643 | for its "south" adjacency to R3: 9003 | 644 +-----------------------------------------------------------+ 646 Figure 6: IGP Address and Segment Allocation - Illustration 648 3.1.1. Example 1 650 R1 may send a packet P1 to R8 simply by pushing an SR header with 651 segment list {1008}. 653 1008 is a global IGP segment attached to the IP prefix 192.0.2.8/32. 654 Its semantic is global within the IGP domain: any router forwards a 655 packet received with active segment 1008 to the next-hop along the 656 ECMP-aware shortest-path to the related prefix. 658 In conclusion, the path followed by P1 is R1-R2--R3-R8. The ECMP- 659 awareness ensures that the traffic be load-shared between any ECMP 660 path, in this case the two north and south links between R2 and R3. 662 3.1.2. Example 2 664 R1 may send a packet P2 to R8 by pushing an SR header with segment 665 list {1002, 9001, 1008}. 667 1002 is a global IGP segment attached to the IP prefix 192.0.2.2/32. 668 Its semantic is global within the IGP domain: any router forwards a 669 packet received with active segment 1002 to the next-hop along the 670 shortest-path to the related prefix. 672 9001 is a local IGP segment attached by node R2 to its north link to 673 R3. Its semantic is local to node R2: R2 switches a packet received 674 with active segment 9001 towards the north link to R3. 676 In conclusion, the path followed by P2 is R1-R2-north-link-R3-R8. 678 3.1.3. Example 3 680 R1 may send a packet P3 along the same exact path as P1 using a 681 different segment list {1002, 9003, 1008}. 683 9003 is a local IGP segment attached by node R2 to both its north and 684 south links to R3. Its semantic is local to node R2: R2 switches a 685 packet received with active segment 9003 towards either the north or 686 south links to R3 (e.g. per-flow loadbalancing decision). 688 In conclusion, the path followed by P3 is R1-R2-any-link-R3-R8. 690 3.1.4. Example 4 692 R1 may send a packet P4 to R8 while avoiding the links between R2 and 693 R3 by pushing an SR header with segment list {1004, 1008}. 695 1004 is a global IGP segment attached to the IP prefix 192.0.2.4/32. 696 Its semantic is global within the IGP domain: any router forwards a 697 packet received with active segment 1004 to the next-hop along the 698 shortest-path to the related prefix. 700 In conclusion, the path followed by P4 is R1-R2-R4-R3-R8. 702 3.1.5. Example 5 704 R1 may send a packet P5 to R8 while avoiding the links between R2 and 705 R3 while still benefitting from all the remaining shortest paths (via 706 R4 and R5) by pushing an SR header with segment list {2009, 1008}. 708 2009 is a global IGP segment attached to the anycast IP prefix 709 198.51.100.9/32. Its semantic is global within the IGP domain: any 710 router forwards a packet received with active segment 2009 to the 711 next-hop along the shortest-path to the related prefix. 713 In conclusion, the path followed by P5 is either R1-R2-R4-R3-R8 or 714 R1-R2-R5-R3-R8 . 716 3.2. IGP Segment Terminology 718 3.2.1. IGP Segment, IGP SID 720 The terms "IGP Segment" and "IGP SID" are the generic names for a 721 segment attached to a piece of information advertised by a link-state 722 IGP, e.g. an IGP prefix or an IGP adjacency. 724 The IGP signaling extension to advertise an IGP segment includes the 725 G-Flag indicating whether the IGP segment is global or local. 726 IGP-SID 727 +--+--+ 728 / | \ 729 Prefix-SID x Adj-SID 730 +----+---+ 731 / | \ 732 Node-SID y Anycast-SID 734 Figure 7: IGP SID Terminology 736 The IGP Segment terminology is introduced to ease the documentation 737 of SR use-cases and hence does not propose a name for any possible 738 variation of IGP segment supported by the architecture. For example, 739 y in Figure 7 could represent a local IGP segment attached to an IGP 740 Prefix. This variation, while supported by the SR architecture is 741 not seen in the SR use-cases and hence does not receive a specific 742 name. 744 In Figure 5 and Figure 6, SIDs 1001, 1002, 1003, 1004, 1008, 2009, 745 9001, 9002 and 9003 are called IGP SIDs. 747 3.2.2. IGP-Prefix Segment, Prefix-SID 749 An IGP-Prefix Segment is an IGP segment attached to an IGP prefix. 750 An IGP-Prefix Segment is always global within the SR/IGP domain and 751 identifies the ECMP-aware shortest-path computed by the IGP to the 752 related prefix. The G-Flag MUST be set. The Prefix-SID is the SID 753 of the IGP-Prefix Segment. 755 A packet injected anywhere within the SR/IGP domain with an active 756 Prefix-SID will be forwarded along the shortest-path to that prefix. 758 The IGP signaling extension for IGP-Prefix segment includes the 759 P-Flag. A Node N advertising a Prefix-SID SID-R for its attached 760 prefix R resets the P-Flag to allow its connected neighbors to 761 perform the NEXT operation while processing SID-R. This behavior is 762 equivalent to Pen-ultimate Hop Popping in MPLS. When set, the 763 neighbors of N must perform the CONTINUE operation while processing 764 SID-R. 766 While the architecture allows to attach a local segment to an IGP 767 prefix, we specifically assume that when the terms "IGP-Prefix 768 Segment" and "Prefix-SID" are used then the segment is global (the 769 SID is allocated from the SRGB). This is consistent with 770 [draft-filsfils-rtgwg-segment-routing-use-cases-00] as all the 771 described use-cases require global segments attached to IGP prefix. 773 In Figure 5 and Figure 6, SIDs 1001, 1002, 1003, 1004, 1008, 2009 are 774 called Prefix-SIDs. 776 3.2.3. IGP-Node Segment, Node-SID 778 An IGP-Node Segment is a an IGP-Prefix Segment which identifies a 779 specific router (e.g. a loopback). The terms "Node Segment" or 780 "Node-SID" are often used as an abbreviation. 782 A "Node Segment" or "Node-SID" is fundamental to the SR architecture. 783 From anywhere in the network, it enforces the ECMP-aware shortest- 784 path forwarding of the packet towards the related node as explained 785 in [draft-filsfils-rtgwg-segment-routing-use-cases-00]. 787 In Figure 5 and Figure 6, SIDs 1001, 1002, 1003, 1004 and 1008 are 788 called Node-SIDs. 790 3.2.4. IGP-Anycast Segment, Anycast SID 792 An IGP-Anycast Segment is an IGP-prefix segment which does not 793 identify a specific router, but a set of routers. The terms "Anycast 794 Segment" or "Anycast-SID" are often used as an abbreviation. 796 An "Anycast Segment" or "Anycast SID" enforces the ECMP-aware 797 shortest-path forwarding towards the closest node of the anycast set. 798 This is useful to express macro-engineering policies as described in 799 [draft-filsfils-rtgwg-segment-routing-use-cases-00]. 801 In Figure 5 and Figure 6, SID 2009 is called Anycast SID. 803 3.2.5. IGP-Adjacency Segment, Adj-SID 805 An IGP-Adjacency Segment is an IGP segment attached to an 806 unidirectional adjacency or a set of unidirectional adjacencies. An 807 IGP-Adjacency Segment is local to the node which advertises it. The 808 SID of the IGP-Adjacency Segment is called the Adj-SID. The G-Flag 809 must be reset. 811 The adjacency is formed by the local node (i.e.: the node advertising 812 the adjacency in the IGP) and the remote node (i.e.: the other end of 813 the adjacency). The local node MUST be an IGP node. The remote node 814 MAY be: 816 An adjacent IGP node (i.e.: an IGP neighbor). 818 A non-adjacent neighbor (e.g.: a Forwarding Adjacency, [RFC4206]). 820 A virtual neighbor outside the IGP domain (e.g.: an interface 821 connecting another AS) as defined in [RFC5316]. 823 A packet injected anywhere within the SR/IGP domain with a segment 824 list {SN, SNL}, where SN is the Node-SID of node N and SNL is an Adj- 825 Sid attached by node N to its adjacency over link L, will be 826 forwarded along the shortest-path to N and then be switched by N, 827 without any IP shortest-path consideration, towards link L. If the 828 Adj-Sid identifies a set of adjacencies, then the node N load- 829 balances the traffic along the various members of the set. 831 An "IGP Adjacency Segment" or "Adj-SID" enforces the switching of the 832 packet from a note towards a defined interface or set of interfaces. 833 This is key to theoretically prove that any path can be expressed as 834 a list of segments as explained in 835 [draft-filsfils-rtgwg-segment-routing-use-cases-00]. 837 In Figure 5 and Figure 6, SIDs 9001, 9002 and 9003 are called Adj- 838 SIDs. 840 3.2.6. Finally 842 Figure 8 summarizes the different terms that can be used to refer to 843 the SID's used in the example illustrated by Figure 5 and Figure 6. 845 "Y" means that the term can be used to refer to the SID, "N" means 846 that the term cannot be used to refer to the SID. 847 +---------------------------------------------------------------+ 848 | SID | IGP SID | Prefix-SID | Node-SID| Anycast SID| Adj-SID | 849 | Value | | | | | | 850 +---------------------------------------------------------------+ 851 | 1001 | Y | Y | Y | N | N | 852 | 1002 | Y | Y | Y | N | N | 853 | 1003 | Y | Y | Y | N | N | 854 | 1004 | Y | Y | Y | N | N | 855 | 1005 | Y | Y | Y | N | N | 856 | 1008 | Y | Y | Y | N | N | 857 | 2009 | Y | Y | N | Y | N | 858 | 9001 | Y | N | N | N | Y | 859 | 9002 | Y | N | N | N | Y | 860 | 9003 | Y | N | N | N | Y | 861 +---------------------------------------------------------------+ 863 Figure 8: Terminology Example 865 3.3. IGP Segment Allocation, Advertisement and SRDB Maintenance 867 3.3.1. Prefix-SID 869 Multiple Prefix-SID's may be allocated to the same IGP Prefix (e.g. 870 for class of service purpose). Typically a single Prefix-SID is 871 allocated to an IGP Prefix. 873 A Prefix-SID is allocated from the SRGB according to a similar 874 process to IP address allocation. Typically the Prefix-SID is 875 allocated by policy by the operator (or NMS) and the SID very rarely 876 changes. 878 The allocation process MUST NOT allocate the same Prefix-SID to 879 different IP prefixes. 881 If a node learns a Prefix-SID having a value that falls outside the 882 locally configured SRGB range, then the node MUST NOT use the Prefix- 883 SID and SHOULD issue an error log warning for misconfiguration. 885 The required IGP protocol extensions are defined in 886 [draft-previdi-isis-segment-routing-extensions-00] and 887 [draft-psenak-ospf-segment-routing-extensions-00]. 889 A node N attaching a Prefix-SID SID-R to its attached prefix R MUST 890 maintain the following SRDB entry: 892 Incoming Active Segment: SID-R 893 Ingress Operation: NEXT 894 Egress interface: NULL 896 A remote node M MUST maintain the following SRDB entry for any 897 learned Prefix-SID SID-R attached to IP prefix R: 898 Incoming Active Segment: SID-R 899 Ingress Operation: 900 If the next-hop of R is the originator of R 901 and instructed to remove the active segment: NEXT 902 Else: CONTINUE 903 Egress interface: the interface towards the next-hop along 904 the shortest-path to prefix R. 906 3.3.2. Adj-SID 908 The Adjacency Segment SID (Adj-SID) identifies a unidirectional 909 adjacency or a set of unidirectional adjacencies. 910 A node SHOULD allocate one Adj-SIDs for each of its adjacencies. 911 A node MAY allocate multiple Adj-SIDs to the same adjacency. 912 A node MAY allocate the same Adj-SID to multiple adjacencies. 914 Adjacency suppression MUST NOT be performed by the IGP. 916 A node MUST install an SRDB entry for any Adj-SID of value V attached 917 to data-link L: 918 Incoming Active Segment: V 919 Operation: NEXT 920 Egress Interface: L 922 When associated to a Forwarding Adjacency ([RFC4206]), the Adj-SID 923 MAY also include the necessary information in order to describe the 924 path to the remote end of the Forwarding Adjacency in the form of an 925 Explicit Route Object. 927 The Adj-SID implies, from the router advertising it, the forwarding 928 of the packet through the adjacency identified by the Adj-SID, 929 regardless its IGP/SPF cost. In other words, the use of Adjacency 930 Segments overrides the routing decision made by SPF algorithm. 932 3.3.2.1. Parallel Adjacencies 934 Adj-SIDs can be used in order to represent a set of parallel 935 interfaces between two adjacent routers. For example, SID 9003 in 936 figures 5 and 6 identify the set of interfaces between R2 and R3. 938 A node MUST install an SRDB entry for any locally originated 939 Adjacency Segment (Adj-SID) of value W attached to a set of link B 940 with: 941 Incoming Active Segment: W 942 Ingress Operation: NEXT 943 Egress interface: loadbalance between any data-link within set B 945 3.3.2.2. LAN Adjacency Segments 947 In LAN subnetworks, link-state protocols define the concept of 948 Designated Router (DR, in OSPF) or Designated Intermediate System 949 (DIS, in IS-IS) that conduct flooding in broadcast subnetworks and 950 that describe the LAN topology in a special routing update (OSPF 951 Type2 LSA or IS-IS Pseudonode LSP). 953 The difficulty with LANs is that each router only advertises its 954 connectivity to the DR/DIS and not to each other individual nodes in 955 the LAN. Therefore, additional protocol mechanisms (IS-IS and OSPF) 956 are necessary in order for each router in the LAN to advertise an 957 Adj-SID associated to each neighbor in the LAN. These extensions are 958 defined in [draft-previdi-isis-segment-routing-extensions-00] and 959 [draft-psenak-ospf-segment-routing-extensions-00]. 961 3.3.2.3. External Adjacencies Considerations 963 IGPs have been extended in order to advertise virtual adjacencies 964 that represent external links ([RFC5316]). 966 Segment Routing allows to allocate an Adj-SID to these external 967 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 [draft-filsfils-rtgwg-segment-routing-use-cases-00] provides an 987 external-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 [draft-filsfils-rtgwg-segment-routing-use-cases-00] illustrates such 1038 a 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 [draft-previdi-isis-segment-routing-extensions-00] and 1044 [draft-psenak-ospf-segment-routing-extensions-00]. 1046 4. Service Segments 1048 A service segment refers to a service offered by a node (e.g. 1049 firewall, vpn, etc.). 1051 Further informations will be included in future revisions. 1053 5. MPLS 1055 The 20 right-most bits of the segment are encoded as a label. This 1056 implies that, in the MPLS instantiation, the SID values are allocated 1057 within a reduced 20-bit space out of the 32-bit SID space. 1059 A list of segments is represented as a stack of labels. 1061 The active segment is the top label. 1063 The CONTINUE operation is implemented as an MPLS swap operation where 1064 the outgoing label value is equal to the incoming label value. 1066 The NEXT operation is implemented as an MPLS pop operation. 1068 The PUSH operation is implemented as an MPLS push of a label stack. 1070 The SRGB label space is allocated to Segment Routing. The SR 1071 operator manages the SRGB space as a registry and ensures the unique 1072 allocation of the global resource. 1074 A local segment is a locally allocated label. 1076 In conclusion: 1078 There are no changes in the operations of the data-plane currently 1079 used in MPLS networks. 1081 The SR solution can co-exist and interwork with other MPLS 1082 control-plane protocols, see 1083 [draft-filsfils-rtgwg-segment-routing-use-cases-00] for more 1084 details. 1086 In the MPLS instantiation, as the packet travels through the SR 1087 domain, the stack is depleted and the segment list history is 1088 gradually lost. 1090 6. IPv6 1092 The text will be added in future revision. 1094 7. OAM 1096 SR offers an interesting capability to monitor SR domains: 1098 Any path can be monitored by setting the segment list accordingly. 1100 A path can be expressed with ECMP-awareness or not. 1102 The probe travels along the desired path while staying at the 1103 forwarding level. 1105 A monitoring system is able to check any element of the entire SR 1106 domain, even if it located multiple hops away. 1108 Some elements of the SR/OAM functionality will require 1109 standardization and a related independent draft will eventually be 1110 submitted. 1112 SR/OAM use-cases are described in 1113 [draft-filsfils-rtgwg-segment-routing-use-cases-00]. 1115 8. Multicast 1117 The text will be added in future revision. 1119 9. IANA Considerations 1121 TBD 1123 10. Manageability Considerations 1125 TBD 1127 11. Security Considerations 1129 TBD 1131 12. Acknowledgements 1133 We would like to thank Dave Ward, Dan Frost, Stewart Bryant, Pierre 1134 Francois, Thomas Telkamp, Les Ginsberg, Ruediger Geib and Hannes 1135 Gredler for their contribution to the content of this document. 1137 13. References 1139 13.1. Normative References 1141 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1142 Requirement Levels", BCP 14, RFC 2119, March 1997. 1144 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1145 (IPv6) Specification", RFC 2460, December 1998. 1147 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 1148 Label Switching Architecture", RFC 3031, January 2001. 1150 [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) 1151 Hierarchy with Generalized Multi-Protocol Label Switching 1152 (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. 1154 [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in 1155 Support of Inter-Autonomous System (AS) MPLS and GMPLS 1156 Traffic Engineering", RFC 5316, December 2008. 1158 13.2. Informative References 1160 [I-D.minto-rsvp-lsp-egress-fast-protection] 1161 Jeganathan, J., Gredler, H., and Y. Shen, "RSVP-TE LSP 1162 egress fast-protection", 1163 draft-minto-rsvp-lsp-egress-fast-protection-02 (work in 1164 progress), April 2013. 1166 [draft-filsfils-rtgwg-segment-routing-use-cases-00] 1167 Filsfils, C., "Segment Routing Use Cases", May 2013. 1169 [draft-msiva-pce-pcep-segment-routing-extensions-00] 1170 Filsfils, C. and S. Sivabalan, "PCEP Extensions for 1171 Segment Routing", May 2013. 1173 [draft-previdi-isis-segment-routing-extensions-00] 1174 Previdi, S., Filsfils, C., and A. Bashandy, "IS-IS Segment 1175 Routing Extensions", May 2013. 1177 [draft-psenak-ospf-segment-routing-extensions-00] 1178 Psenak, P. and S. Previdi, "OSPF Segment Routing 1179 Extensions", May 2013. 1181 Authors' Addresses 1183 Clarence Filsfils (editor) 1184 Cisco Systems, Inc. 1185 Brussels, 1186 BE 1188 Email: cfilsfil@cisco.com 1190 Stefano Previdi (editor) 1191 Cisco Systems, Inc. 1192 Via Del Serafico, 200 1193 Rome 00142 1194 Italy 1196 Email: sprevidi@cisco.com 1198 Ahmed Bashandy 1199 Cisco Systems, Inc. 1200 170, West Tasman Drive 1201 San Jose, CA 95134 1202 US 1204 Email: bashandy@cisco.com 1206 Bruno Decraene 1207 Orange 1208 FR 1210 Email: bruno.decraene@orange.com 1211 Stephane Litkowski 1212 Orange 1213 FR 1215 Email: stephane.litkowski@orange.com 1217 Martin Horneffer 1218 Deutsche Telekom 1219 Hammer Str. 216-226 1220 Muenster 48153 1221 DE 1223 Email: Martin.Horneffer@telekom.de 1225 Igor Milojevic 1226 Telekom Srbija 1227 Takovska 2 1228 Belgrade 1229 RS 1231 Email: igormilojevic@telekom.rs 1233 Rob Shakir 1234 British Telecom 1235 London 1236 UK 1238 Email: rob.shakir@bt.com 1240 Saku Ytti 1241 TDC Oy 1242 Mechelininkatu 1a 1243 TDC 00094 1244 FI 1246 Email: saku@ytti.fi 1247 Wim Henderickx 1248 Alcatel-Lucent 1249 Copernicuslaan 50 1250 Antwerp 2018 1251 BE 1253 Email: wim.henderickx@alcatel-lucent.com 1255 Jeff Tantsura 1256 Ericsson 1257 300 Holger Way 1258 San Jose, CA 95134 1259 US 1261 Email: Jeff.Tantsura@ericsson.com 1263 Edward Crabbe 1264 Google, Inc. 1265 1600 Amphitheatre Parkway 1266 Mountain View, CA 94043 1267 US 1269 Email: edc@google.com