idnits 2.17.1 draft-ietf-spring-segment-routing-08.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 (May 11, 2016) is 2906 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) == Outdated reference: A later version (-13) exists of draft-filsfils-spring-large-scale-interconnect-02 == Outdated reference: A later version (-04) exists of draft-francois-rtgwg-segment-routing-ti-lfa-00 == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-01 == Outdated reference: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-06 == Outdated reference: A later version (-23) exists of draft-ietf-ospf-ospfv3-segment-routing-extensions-05 == Outdated reference: A later version (-27) exists of draft-ietf-ospf-segment-routing-extensions-08 == Outdated reference: A later version (-16) exists of draft-ietf-pce-segment-routing-07 == Outdated reference: A later version (-12) exists of draft-ietf-spring-ipv6-use-cases-06 == Outdated reference: A later version (-10) exists of draft-ietf-spring-oam-usecase-03 == Outdated reference: A later version (-12) exists of draft-ietf-spring-resiliency-use-cases-03 == Outdated reference: A later version (-10) exists of draft-ietf-spring-segment-routing-central-epe-01 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-ldp-interop-01 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-04 == Outdated reference: A later version (-11) exists of draft-ietf-spring-segment-routing-msdc-01 == Outdated reference: A later version (-03) exists of draft-ietf-spring-sr-oam-requirement-01 -- Obsolete informational reference (is this intentional?): RFC 6822 (Obsoleted by RFC 8202) Summary: 1 error (**), 0 flaws (~~), 16 warnings (==), 3 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 Cisco Systems, Inc. 5 Expires: November 12, 2016 B. Decraene 6 S. Litkowski 7 Orange 8 R. Shakir 9 Jive Communications 10 May 11, 2016 12 Segment Routing Architecture 13 draft-ietf-spring-segment-routing-08 15 Abstract 17 Segment Routing (SR) leverages the source routing paradigm. A node 18 steers a packet through an ordered list of instructions, called 19 segments. A segment can represent any instruction, topological or 20 service-based. A segment can have a local semantic to an SR node or 21 global within an SR domain. SR allows to enforce a flow through any 22 topological path and service chain while maintaining per-flow state 23 only at the ingress node to the SR domain. 25 Segment Routing can be directly applied to the MPLS architecture with 26 no change on the forwarding plane. A segment is encoded as an MPLS 27 label. An ordered list of segments is encoded as a stack of labels. 28 The segment to process is on the top of the stack. Upon completion 29 of a segment, the related label is popped from the stack. 31 Segment Routing can be applied to the IPv6 architecture, with a new 32 type of routing header. A segment is encoded as an IPv6 address. An 33 ordered list of segments is encoded as an ordered list of IPv6 34 addresses in the routing header. The active segment is indicated by 35 the Destination Address of the packet. The next active segment is 36 indicated by a pointer in the new routing header. 38 Requirements Language 40 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 41 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 42 document are to be interpreted as described in RFC 2119 [RFC2119]. 44 Status of This Memo 46 This Internet-Draft is submitted in full conformance with the 47 provisions of BCP 78 and BCP 79. 49 Internet-Drafts are working documents of the Internet Engineering 50 Task Force (IETF). Note that other groups may also distribute 51 working documents as Internet-Drafts. The list of current Internet- 52 Drafts is at http://datatracker.ietf.org/drafts/current/. 54 Internet-Drafts are draft documents valid for a maximum of six months 55 and may be updated, replaced, or obsoleted by other documents at any 56 time. It is inappropriate to use Internet-Drafts as reference 57 material or to cite them other than as "work in progress." 59 This Internet-Draft will expire on November 12, 2016. 61 Copyright Notice 63 Copyright (c) 2016 IETF Trust and the persons identified as the 64 document authors. All rights reserved. 66 This document is subject to BCP 78 and the IETF Trust's Legal 67 Provisions Relating to IETF Documents 68 (http://trustee.ietf.org/license-info) in effect on the date of 69 publication of this document. Please review these documents 70 carefully, as they describe your rights and restrictions with respect 71 to this document. Code Components extracted from this document must 72 include Simplified BSD License text as described in Section 4.e of 73 the Trust Legal Provisions and are provided without warranty as 74 described in the Simplified BSD License. 76 Table of Contents 78 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 79 1.1. Companion Documents . . . . . . . . . . . . . . . . . . . 4 80 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 81 3. Link-State IGP Segments . . . . . . . . . . . . . . . . . . . 7 82 3.1. IGP Segment, IGP SID . . . . . . . . . . . . . . . . . . 7 83 3.2. IGP-Prefix Segment, Prefix-SID . . . . . . . . . . . . . 7 84 3.2.1. Prefix-SID Algorithm . . . . . . . . . . . . . . . . 7 85 3.2.2. MPLS Dataplane . . . . . . . . . . . . . . . . . . . 8 86 3.2.3. IPv6 Dataplane . . . . . . . . . . . . . . . . . . . 10 87 3.3. IGP-Node Segment, Node-SID . . . . . . . . . . . . . . . 10 88 3.4. IGP-Anycast Segment, Anycast SID . . . . . . . . . . . . 11 89 3.5. IGP-Adjacency Segment, Adj-SID . . . . . . . . . . . . . 13 90 3.5.1. Parallel Adjacencies . . . . . . . . . . . . . . . . 15 91 3.5.2. LAN Adjacency Segments . . . . . . . . . . . . . . . 16 92 3.6. Binding Segment . . . . . . . . . . . . . . . . . . . . . 16 93 3.6.1. Mapping Server . . . . . . . . . . . . . . . . . . . 16 94 3.6.2. Tunnel Headend . . . . . . . . . . . . . . . . . . . 16 95 3.7. Inter-Area Considerations . . . . . . . . . . . . . . . . 16 96 4. BGP Peering Segments . . . . . . . . . . . . . . . . . . . . 17 97 5. IGP Mirroring Context Segment . . . . . . . . . . . . . . . 18 98 6. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 19 99 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 100 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 101 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19 102 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 103 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 104 11.1. Normative References . . . . . . . . . . . . . . . . . . 20 105 11.2. Informative References . . . . . . . . . . . . . . . . . 21 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 108 1. Introduction 110 With Segment Routing (SR), a node steers a packet through an ordered 111 list of instructions, called segments. A segment can represent any 112 instruction, topological or service-based. A segment can have a 113 local semantic to an SR node or global within an SR domain. SR 114 allows to enforce a flow through any path and service chain while 115 maintaining per-flow state only at the ingress node of the SR domain. 117 Segment Routing can be directly applied to the MPLS architecture 118 ([RFC3031]) with no change on the forwarding plane. A segment is 119 encoded as an MPLS label. An ordered list of segments is encoded as 120 a stack of labels. The active segment is on the top of the stack. A 121 completed segment is popped off the stack. The addition of a segment 122 is performed with a push. 124 In the Segment Routing MPLS instantiation, a segment could be of 125 several types: 127 o an IGP segment, 129 o a BGP Peering segments, 131 o an LDP LSP segment, 133 o an RSVP-TE LSP segment, 135 o a BGP LSP segment. 137 The first two (IGP and BGP Peering segments) types of segments are 138 defined in this document. The use of the last three types of 139 segments is illustrated in [I-D.ietf-spring-segment-routing-mpls]. 141 Segment Routing can be applied to the IPv6 architecture ([RFC2460]), 142 with a new type of routing header. A segment is encoded as an IPv6 143 address. An ordered list of segments is encoded as an ordered list 144 of IPv6 addresses in the routing header. The active segment is 145 indicated by the Destination Address of the packet. Upon completion 146 of a segment, a pointer in the new routing header is incremented and 147 indicates the next segment. 149 Numerous use-cases illustrate the benefits of source routing either 150 for FRR, OAM or Traffic Engineering reasons. 152 This document defines a set of instructions (called segments) that 153 are required to fulfill the described use-cases. These segments can 154 either be used in isolation (one single segment defines the source 155 route of the packet) or in combination (these segments are part of an 156 ordered list of segments that define the source route of the packet). 158 1.1. Companion Documents 160 This document defines the SR architecture, its routing model, the 161 IGP-based segments, the BGP-based segments and the service segments. 163 Use cases are described in [I-D.ietf-spring-problem-statement], 164 [I-D.ietf-spring-segment-routing-central-epe], 165 [I-D.ietf-spring-segment-routing-msdc], 166 [I-D.filsfils-spring-large-scale-interconnect], 167 [I-D.ietf-spring-ipv6-use-cases], 168 [I-D.ietf-spring-resiliency-use-cases], [I-D.ietf-spring-oam-usecase] 169 and [I-D.ietf-spring-sr-oam-requirement]. 171 Segment Routing for MPLS dataplane is documented in 172 [I-D.ietf-spring-segment-routing-mpls]. 174 Segment Routing for IPv6 dataplane is documented in 175 [I-D.ietf-6man-segment-routing-header]. 177 IGP protocol extensions for Segment Routing are described in 178 [I-D.ietf-isis-segment-routing-extensions], 179 [I-D.ietf-ospf-segment-routing-extensions] and 180 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] referred in this 181 document as "IGP SR extensions documents". 183 The FRR solution for SR is documented in 184 [I-D.francois-rtgwg-segment-routing-ti-lfa]. 186 The PCEP protocol extensions for Segment Routing are defined in 187 [I-D.ietf-pce-segment-routing]. 189 The interaction between SR/MPLS with other MPLS Signaling planes is 190 documented in [I-D.ietf-spring-segment-routing-ldp-interop]. 192 2. Terminology 194 Segment: an instruction a node executes on the incoming packet (e.g.: 195 forward packet according to shortest path to destination, or, forward 196 packet through a specific interface, or, deliver the packet to a 197 given application/service instance). 199 SID: a Segment Identifier. Examples of SIDs are: a MPLS label, an 200 index value in a MPLS label space, an IPv6 address. Other types of 201 SIDs can be defined in the future. 203 Segment List: ordered list of SID's encoding the topological and 204 service source route of the packet. It is a stack of labels in the 205 MPLS architecture. It is an ordered list of IPv6 addresses in the 206 IPv6 architecture. 208 Segment Routing Domain (SR Domain): the set of nodes participating 209 into the source based routing model. These nodes may be connected to 210 the same physical infrastructure (e.g.: a Service Provider's network) 211 as well as nodes remotely connected to each other (e.g.: an 212 enterprise VPN or an overlay). Note that a SR domain may also be 213 confined within an IGP instance, in which case it is named SR-IGP 214 Domain. 216 Active segment: the segment that MUST be used by the receiving router 217 to process the packet. In the MPLS dataplane is the top label. In 218 the IPv6 dataplane is the destination address of a packet having the 219 Segment Routing Header as defined in 220 [I-D.ietf-6man-segment-routing-header]. 222 PUSH: the insertion of a segment at the head of the Segment list. 224 NEXT: the active segment is completed, the next segment becomes 225 active. 227 CONTINUE: the active segment is not completed and hence remains 228 active. The CONTINUE instruction is implemented as the SWAP 229 instruction in the MPLS dataplane. In IPv6, this is the plain IPv6 230 forwarding action of a regular IPv6 packet according to its 231 Destination Address. 233 SR Global Block (SRGB): local property of an SR node. In the MPLS 234 architecture, SRGB is the set of local labels reserved for global 235 segments. Using the same SRGB on all nodes within the SR domain ease 236 operations and troubleshooting and is expected to be a deployment 237 guideline. In the IPv6 architecture, the equivalent of the SRGB is 238 in fact the set of addresses used as global segments. Since there 239 are no restrictions on which IPv6 address can be used, the concept of 240 the SRGB includes all IPv6 global address space used within the SR 241 domain. 243 Global Segment: the related instruction is supported by all the SR- 244 capable nodes in the domain. In the MPLS architecture, a Global 245 Segment has a globally-unique index. The related local label at a 246 given node N is found by adding the globally-unique index to the SRGB 247 of node N. In the IPv6 architecture, a global segment is a globally- 248 unique IPv6 address. 250 Local Segment: the related instruction is supported only by the node 251 originating it. In the MPLS architecture, this is a local label 252 outside the SRGB. In the IPv6 architecture, this can be any IPv6 253 address whose reachability is not advertised in any routing protocol 254 (hence, the segment is known only by the local node). 256 IGP Segment: the generic name for a segment attached to a piece of 257 information advertised by a link-state IGP, e.g. an IGP prefix or an 258 IGP adjacency. 260 IGP-prefix Segment, Prefix-SID: an IGP-Prefix Segment is an IGP 261 segment attached to an IGP prefix. An IGP-Prefix Segment is global 262 (unless explicitly advertised otherwise) within the SR IGP instance/ 263 topology and identifies an instruction to forward the packet along 264 the path computed using the algorithm field, in the topology and the 265 IGP instance where it is advertised. The Prefix-SID is the SID of 266 the IGP-Prefix Segment. 268 IGP-Anycast: an IGP-Anycast Segment is an IGP-prefix segment which 269 does not identify a specific router, but a set of routers. The terms 270 "Anycast Segment" or "Anycast-SID" are often used as an abbreviation. 272 IGP-Adjacency: an IGP-Adjacency Segment is an IGP segment attached to 273 an unidirectional adjacency or a set of unidirectional adjacencies. 274 By default, an IGP-Adjacency Segment is local (unless explicitly 275 advertised otherwise) to the node that advertises it. 277 IGP-Node: an IGP-Node Segment is an IGP-Prefix Segment which 278 identifies a specific router (e.g. a loopback). The terms "Node 279 Segment" or Node-SID" are often used as an abbreviation. 281 SR Tunnel: a list of segments to be pushed on the packets directed on 282 the tunnel. The list of segments can be specified explicitly or 283 implicitly via a set of abstract constraints (latency, affinity, 284 SRLG, ...). In the latter case, a constraint-based path computation 285 is used to determine the list of segments associated with the tunnel. 286 The computation can be local or delegated to a PCE server. An SR 287 tunnel can be configured by the operator, provisioned via netconf or 288 provisioned via PCEP. An SR tunnel can be used for traffic- 289 engineering, OAM or FRR reasons. 291 Segment List Depth: the number of segments of an SR tunnel. The 292 entity instantiating an SR Tunnel at a node N should be able to 293 discover the depth insertion capability of the node N. The PCEP 294 discovery capability is described in [I-D.ietf-pce-segment-routing]. 296 3. Link-State IGP Segments 298 Within a link-state IGP domain, an SR-capable IGP node advertises 299 segments for its attached prefixes and adjacencies. These segments 300 are called IGP segments or IGP SIDs. They play a key role in Segment 301 Routing and use-cases as they enable the expression of any 302 topological path throughout the IGP domain. Such a topological path 303 is either expressed as a single IGP segment or a list of multiple IGP 304 segments. 306 3.1. IGP Segment, IGP SID 308 The terms "IGP Segment" and "IGP SID" are the generic names for a 309 segment attached to a piece of information advertised by a link-state 310 IGP, e.g. an IGP prefix or an IGP adjacency. 312 3.2. IGP-Prefix Segment, Prefix-SID 314 An IGP-Prefix Segment is an IGP segment attached to an IGP prefix. 315 An IGP-Prefix Segment is global (unless explicitly advertised 316 otherwise) within the SR/IGP domain. 318 The required IGP protocol extensions are defined in IGP SR extensions 319 documents. 321 3.2.1. Prefix-SID Algorithm 323 The IGP protocol extensions for Segment Routing define the Prefix-SID 324 advertisement which includes a set of flags and the algorithm field. 325 The algorithm field has the purpose of associating a given Prefix-SID 326 to a routing algorithm. 328 In the context of an instance and a topology, multiple Prefix-SID's 329 MAY be allocated to the same IGP Prefix as long as the algorithm 330 value is different in each one. 332 Multiple instances and topologies are defined in IS-IS and OSPF in: 333 [RFC5120], [RFC6822], [RFC6549] and [RFC4915]. 335 Initially, two "algorithms" have been defined: 337 o "Shortest Path": this algorithm is the default behavior. The 338 packet is forwarded along the well known ECMP-aware SPF algorithm 339 however it is explicitly allowed for a midpoint to implement 340 another forwarding based on local policy.. The "Shortest Path" 341 algorithm is in fact the default and current behavior of most of 342 the networks where local policies may override the SPF decision. 344 o "Strict Shortest Path": This algorithm mandates that the packet is 345 forwarded according to ECMP-aware SPF algorithm and instruct any 346 router in the path to ignore any possible local policy overriding 347 SPF decision. The SID advertised with "Strict Shortest Path" 348 algorithm ensures that the path the packet is going to take is the 349 expected, and not altered, SPF path. 351 An IGP-Prefix Segment identifies the path, to the related prefix, 352 along the path computed as per the algorithm field. 354 A packet injected anywhere within the SR/IGP domain with an active 355 Prefix-SID will be forwarded along path computed by the algorithm 356 expressed in the algorithm field. 358 The ingress node of an SR domain validates that the path to a prefix, 359 advertised with a given algorithm, includes nodes all supporting the 360 advertised algorithm. In other words, when computing paths for a 361 given algorithm, the transit nodes MUST compute the algorithm X on 362 the IGP topology, regardless of the support of the algorithm X by the 363 nodes in that topology. As a consequence, if a node on the path does 364 not support algorithm X, the IGP-Prefix segment will be interrupted 365 and will drop packet on that node. It's the responsibility of the 366 ingress node using a segment to check that all downstream nodes 367 support the algorithm of the segment. 369 Details of the two defined algorithms are defined in 370 [I-D.ietf-isis-segment-routing-extensions], 371 [I-D.ietf-ospf-segment-routing-extensions] and 372 [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. 374 3.2.2. MPLS Dataplane 376 When SR is used over the MPLS dataplane: 378 o the IGP signaling extension for IGP-Prefix segment includes the 379 P-Flag ([I-D.ietf-isis-segment-routing-extensions]) or the NP-Flag 380 ([I-D.ietf-ospf-segment-routing-extensions]). A Node N 381 advertising a Prefix-SID SID-R for its attached prefix R unset the 382 P-Flag (or NP-Flag) in order to instruct its connected neighbors 383 to perform the NEXT operation while processing SID-R. This 384 behavior is equivalent to Penultimate Hop Popping in MPLS. When 385 the flag is unset, the neighbors of N MUST perform the NEXT 386 operation while processing SID-R. When the flag is set, the 387 neighbors of N MUST perform the CONTINUE operation while 388 processing SID-R. 390 o A Prefix-SID is allocated in the form of an index in the SRGB (or 391 as a local MPLS label) according to a process similar to IP 392 address allocation. Typically the Prefix-SID is allocated by 393 policy by the operator (or NMS) and the SID very rarely changes. 395 o While SR allows to attach a local segment to an IGP prefix (using 396 the L-Flag), we specifically assume that when the terms "IGP- 397 Prefix Segment" and "Prefix-SID" are used, the segment is global 398 (the SID is allocated from the SRGB or as an index). This is 399 consistent with all the described use-cases that require global 400 segments attached to IGP prefixes. 402 o The allocation process MUST NOT allocate the same Prefix-SID to 403 different IP prefixes. 405 o If a node learns a Prefix-SID having a value that falls outside 406 the locally configured SRGB range, then the node MUST NOT use the 407 Prefix-SID and SHOULD issue an error log warning for 408 misconfiguration. 410 o If a node N advertises Prefix-SID SID-R for a prefix R that is 411 attached to N, N MUST either clear the P-Flag in the advertisement 412 of SID-R, or else maintain the following FIB entry: 414 Incoming Active Segment: SID-R 415 Ingress Operation: NEXT 416 Egress interface: NULL 418 o A remote node M MUST maintain the following FIB entry for any 419 learned Prefix-SID SID-R attached to IP prefix R: 421 Incoming Active Segment: SID-R 422 Ingress Operation: 423 If the next-hop of R is the originator of R 424 and instructed to remove the active segment: NEXT 425 Else: CONTINUE 426 Egress interface: the interface towards the next-hop along the 427 path computed using the algorithm advertised with 428 the SID toward prefix R. 430 3.2.3. IPv6 Dataplane 432 When SR is used over the IPv6 dataplane: 434 o The Prefix-SID is the prefix itself. No additional identifier is 435 needed for Segment Routing over IPv6. 437 o Any address belonging to any of the node's prefixes can be used as 438 Prefix-SIDs. 440 o An operator may want to explicitly indicate which of the node's 441 prefixes can be used as Prefix-SIDs through the setting of a flag 442 (e.g.: using the IGP prefix attribute defined in [RFC7794]) in the 443 routing protocol used for advertising the prefix. 445 o A global SID is instantiated through any globally advertised IPv6 446 address. 448 o A local SID is instantiated through a local IPv6 prefix not being 449 advertised and therefore known only by the local node. 451 A node N advertising an IPv6 address R usable as a segment identifier 452 MUST maintain the following FIB entry: 454 Incoming Active Segment: R 455 Ingress Operation: NEXT 456 Egress interface: NULL 458 Regardless Segment Routing, any remote IPv6 node will maintain a 459 plain IPv6 FIB entry for any prefix, no matter if they represent a 460 segment or not. 462 3.3. IGP-Node Segment, Node-SID 464 An IGP Node Segment is a an IGP Prefix Segment which identifies a 465 specific router (e.g. a loopback). The terms "Node Segment" or 466 "Node-SID" are often used as an abbreviation. The IGP SR extensions 467 define a flag that identifies Node-SIDs. 469 A "Node Segment" or "Node-SID" is fundamental to SR. From anywhere 470 in the network, it enforces the ECMP-aware shortest-path forwarding 471 of the packet towards the related node. 473 An IGP Node-SID MUST NOT be associated with a prefix that is owned by 474 more than one router within the same routing domain. 476 3.4. IGP-Anycast Segment, Anycast SID 478 An IGP-Anycast Segment is an IGP-prefix segment which does not 479 identify a specific router, but a set of routers. The terms "Anycast 480 Segment" or "Anycast-SID" are often used as an abbreviation. 482 An "Anycast Segment" or "Anycast SID" enforces the ECMP-aware 483 shortest-path forwarding towards the closest node of the anycast set. 484 This is useful to express macro-engineering policies or protection 485 mechanisms. 487 An IGP-Anycast Segment MUST NOT reference a particular node. 489 Within an anycast group, all routers MUST advertise the same prefix 490 with the same SID value. 492 +--------------+ 493 | Group A | 494 |192.0.2.10/32 | 495 | SID:100 | 496 | | 497 +-----------A1---A3----------+ 498 | | | \ / | | | 499 SID:10 | | | / | | | SID:30 500 203.0.113.1/32 | | | / \ | | | 203.0.113.3/32 501 PE1------R1----------A2---A4---------R3------PE3 502 \ /| | | |\ / 503 \ / | +--------------+ | \ / 504 \ / | | \ / 505 / | | / 506 / \ | | / \ 507 / \ | +--------------+ | / \ 508 / \| | | |/ \ 509 PE2------R2----------B1---B3----+----R4------PE4 510 203.0.113.2/32 | | | \ / | | | 203.0.113.4/32 511 SID:20 | | | / | | | SID:40 512 | | | / \ | | | 513 +-----+-----B2---B4----+-----+ 514 | | 515 | Group B | 516 | 192.0.2.1/32 | 517 | SID:200 | 518 +--------------+ 520 Transit device groups 522 The figure above describes a network example with two groups of 523 transit devices. Group A consists of devices {A1, A2, A3 and A4}. 525 They are all provisioned with the anycast address 192.0.2.10/32 and 526 the anycast SID 100. 528 Similarly, group B consists of devices {B1, B2, B3 and B4} and are 529 all provisioned with the anycast address 192.0.2.1/32, anycast SID 530 200. In the above network topology, each PE device is connected to 531 two routers in each of the groups A and B. 533 PE1 can choose a particular transit device group when sending traffic 534 to PE3 or PE4. This will be done by pushing the anycast SID of the 535 group in the stack. 537 Processing the anycast, and subsequent segments, requires special 538 care. 540 Obviously, the value of the SID following the anycast SID MUST be 541 understood by all nodes advertising the same anycast segment. 543 +-------------------------+ 544 | Group A | 545 | 192.0.2.10/32 | 546 | SID:100 | 547 |-------------------------| 548 | | 549 | SRGB: SRGB: | 550 SID:10 |(1000-2000) (3000-4000)| SID:30 551 PE1---+ +-------A1-------------A3-------+ +---PE3 552 \ / | | \ / | | \ / 553 \ / | | +-----+ / | | \ / 554 SRGB: \ / | | \ / | | \ / SRGB: 555 (7000-8000) R1 | | \ | | R3 (6000-7000) 556 / \ | | / \ | | / \ 557 / \ | | +-----+ \ | | / \ 558 / \ | | / \ | | / \ 559 PE2---+ +-------A2-------------A4-------+ +---PE4 560 SID:20 | SRGB: SRGB: | SID:40 561 |(2000-3000) (4000-5000)| 562 | | 563 +-------------------------+ 565 Transit paths via anycast group A 567 Considering a MPLS deployment, in the above topology, if device PE1 568 (or PE2) requires to send a packet to the device PE3 (or PE4) it 569 needs to encapsulate the packet in a MPLS payload with the following 570 stack of labels. 572 o Label allocated by R1 for anycast SID 100 (outer label). 574 o Label allocated by the nearest router in group A for SID 30 (for 575 destination PE3). 577 While the first label is easy to compute, in this case since there 578 are more than one topologically nearest devices (A1 and A2), unless 579 A1 and A2 allocated the same label value to the same prefix, 580 determining the second label is impossible. Devices A1 and A2 may be 581 devices from different hardware vendors. If both don't allocate the 582 same label value for SID 30, it is impossible to use the anycast 583 group "A" as a transit anycast group towards PE3. Hence, PE1 (or 584 PE2) cannot compute an appropriate label stack to steer the packet 585 exclusively through the group A devices. Same holds true for devices 586 PE3 and PE4 when trying to send a packet to PE1 or PE2. 588 To ease the use of anycast segment in a short term, it is recommended 589 to configure the same SRGB on all nodes of a particular anycast 590 group. Using this method, as mentioned above, computation of the 591 label following the anycast segment is straightforward. 593 Using anycast segment without configuring the same SRGB on nodes 594 belonging to the same device group may lead to misrouting (in a MPLS 595 VPN deployment, some traffic may leak between VPNs). 597 3.5. IGP-Adjacency Segment, Adj-SID 599 An IGP-Adjacency Segment is an IGP segment attached to a 600 unidirectional adjacency or a set of unidirectional adjacencies. By 601 default, an IGP-Adjacency Segment is local to the node which 602 advertises it. However, an Adjacency Segment can be global if 603 advertised by the IGP as such. The SID of the IGP-Adjacency Segment 604 is called the Adj-SID. 606 The adjacency is formed by the local node (i.e., the node advertising 607 the adjacency in the IGP) and the remote node (i.e., the other end of 608 the adjacency). The local node MUST be an IGP node. The remote node 609 MAY be an adjacent IGP neighbor or a non-adjacent neighbor (e.g.: a 610 Forwarding Adjacency, [RFC4206]). 612 A packet injected anywhere within the SR domain with a segment list 613 {SN, SNL}, where SN is the Node-SID of node N and SNL is an Adj-SID 614 attached by node N to its adjacency over link L, will be forwarded 615 along the shortest-path to N and then be switched by N, without any 616 IP shortest-path consideration, towards link L. If the Adj-SID 617 identifies a set of adjacencies, then the node N load- balances the 618 traffic among the various members of the set. 620 Similarly, when using a global Adj-SID, a packet injected anywhere 621 within the SR domain with a segment list {SNL}, where SNL is a global 622 Adj-SID attached by node N to its adjacency over link L, will be 623 forwarded along the shortest-path to N and then be switched by N, 624 without any IP shortest-path consideration, towards link L. If the 625 Adj-SID identifies a set of adjacencies, then the node N load- 626 balances the traffic among the various members of the set. The use 627 of global Adj-SID allows to reduce the size of the segment list when 628 expressing a path at the cost of additional state (i.e.: the global 629 Adj-SID will be inserted by all routers within the area in their 630 forwarding table). 632 An "IGP Adjacency Segment" or "Adj-SID" enforces the switching of the 633 packet from a node towards a defined interface or set of interfaces. 634 This is key to theoretically prove that any path can be expressed as 635 a list of segments. 637 The encodings of the Adj-SID include the B-flag. When set, the Adj- 638 SID refers to an adjacency that is eligible for protection (e.g.: 639 using IPFRR or MPLS-FRR). 641 The encodings of the Adj-SID include the L-flag. When set, the Adj- 642 SID has local significance. By default the L-flag is set. 644 A node SHOULD allocate one Adj-SIDs for each of its adjacencies. 646 A node MAY allocate multiple Adj-SIDs to the same adjacency. An 647 example is where the adjacency is established over a bundle 648 interface. Each bundle member MAY have its own Adj-SID. 650 A node MAY allocate the same Adj-SID to multiple adjacencies. 652 Adjacency suppression MUST NOT be performed by the IGP. 654 A node MUST install a FIB entry for any Adj-SID of value V attached 655 to data-link L: 657 Incoming Active Segment: V 658 Operation: NEXT 659 Egress Interface: L 661 The Adj-SID implies, from the router advertising it, the forwarding 662 of the packet through the adjacency identified by the Adj-SID, 663 regardless its IGP/SPF cost. In other words, the use of Adjacency 664 Segments overrides the routing decision made by SPF algorithm. 666 3.5.1. Parallel Adjacencies 668 Adj-SIDs can be used in order to represent a set of parallel 669 interfaces between two adjacent routers. 671 A node MUST install a FIB entry for any locally originated Adjacency 672 Segment (Adj-SID) of value W attached to a set of link B with: 674 Incoming Active Segment: W 675 Ingress Operation: NEXT 676 Egress interface: loadbalance between any data-link within set B 678 When parallel adjacencies are used and associated to the same Adj- 679 SID, and in order to optimize the load balancing function, a "weight" 680 factor can be associated to the Adj-SID advertised with each 681 adjacency. The weight tells the ingress (or a SDN/orchestration 682 system) about the loadbalancing factor over the parallel adjacencies. 683 As shown in Figure 1, A and B are connected through two parallel 684 adjacencies 686 link-1 687 +--------+ 688 | | 689 S---A B---C 690 | | 691 +--------+ 692 link-2 694 Figure 1: Parallel Links and Adj-SIDs 696 Node A advertises following Adj-SIDs and weights: 698 o Link-1: Adj-SID 1000, weight: 1 700 o Link-2: Adj-SID 1000, weight: 2 702 Node S receives the advertisements of the parallel adjacencies and 703 understands that by using Adj-SID 1000 node A will loadbalance the 704 traffic across the parallel links (link-1 and link-2) according to a 705 1:2 ratio. 707 The weight value is advertised with the Adj-SID as defined in IGP SR 708 extensions documents. 710 3.5.2. LAN Adjacency Segments 712 In LAN subnetworks, link-state protocols define the concept of 713 Designated Router (DR, in OSPF) or Designated Intermediate System 714 (DIS, in IS-IS) that conduct flooding in broadcast subnetworks and 715 that describe the LAN topology in a special routing update (OSPF 716 Type2 LSA or IS-IS Pseudonode LSP). 718 The difficulty with LANs is that each router only advertises its 719 connectivity to the DR/DIS and not to each other individual nodes in 720 the LAN. Therefore, additional protocol mechanisms (IS-IS and OSPF) 721 are necessary in order for each router in the LAN to advertise an 722 Adj-SID associated to each neighbor in the LAN. These extensions are 723 defined in IGP SR extensions documents. 725 3.6. Binding Segment 727 3.6.1. Mapping Server 729 A Remote-Binding SID S advertised by the mapping server M for remote 730 prefix R attached to non-SR-capable node N signals the same 731 information as if N had advertised S as a Prefix-SID. Further 732 details are described in the SR/LDP interworking procedures 733 ([I-D.ietf-spring-segment-routing-ldp-interop]. 735 The segment allocation and SRGB Maintenance rules are the same as 736 those defined for Prefix-SID. 738 3.6.2. Tunnel Headend 740 The segment allocation and SRGB Maintenance rules are the same as 741 those defined for Adj-SID. A tunnel attached to a head-end H acts as 742 an adjacency attached to H. 744 Note: an alternative consists of representing tunnels as forwarding- 745 adjacencies ( [RFC4206]). In such case, the tunnel is presented to 746 the routing area as a routing adjacency and is considered as such by 747 all area routers. The Remote-Binding SID is preferred as it allows 748 to advertise the presence of a tunnel without influencing the LSDB 749 and the SPF computation. 751 3.7. Inter-Area Considerations 753 In the following example diagram we assume an IGP deployed using 754 areas and where SR has been deployed. 756 ! ! 757 ! ! 758 B------C-----F----G-----K 759 / | | | 760 S---A/ | | | 761 \ | | | 762 \D------I----------J-----L----Z (192.0.2.1/32, Node-SID: 150) 763 ! ! 764 Area-1 ! Backbone ! Area 2 765 ! area ! 767 Figure 2: Inter-Area Topology Example 769 In area 2, node Z allocates Node-SID 150 to his local prefix 770 192.0.2.1/32. ABRs G and J will propagate the prefix into the 771 backbone area by creating a new instance of the prefix according to 772 normal inter-area/level IGP propagation rules. 774 Nodes C and I will apply the same behavior when leaking prefixes from 775 the backbone area down to area 1. Therefore, node S will see prefix 776 192.0.2.1/32 with Prefix-SID 150 and advertised by nodes C and I. 778 It therefore results that a Prefix-SID remains attached to its 779 related IGP Prefix through the inter-area process. 781 When node S sends traffic to 192.0.2.1/32, it pushes Node-SID(150) as 782 active segment and forward it to A. 784 When packet arrives at ABR I (or C), the ABR forwards the packet 785 according to the active segment (Node-SID(150)). Forwarding 786 continues across area borders, using the same Node-SID(150), until 787 the packet reaches its destination. 789 When an ABR propagates a prefix from one area to another it MUST set 790 the R-Flag. 792 4. BGP Peering Segments 794 In the context of BGP Egress Peer Engineering (EPE), as described in 795 [I-D.ietf-spring-segment-routing-central-epe], an EPE enabled Egress 796 PE node MAY advertise segments corresponding to its attached peers. 797 These segments are called BGP peering segments or BGP Peering SIDs. 798 They enable the expression of source-routed inter-domain paths. 800 An ingress border router of an AS may compose a list of segments to 801 steer a flow along a selected path within the AS, towards a selected 802 egress border router C of the AS and through a specific peer. At 803 minimum, a BGP Peering Engineering policy applied at an ingress PE 804 involves two segments: the Node SID of the chosen egress PE and then 805 the BGP Peering Segment for the chosen egress PE peer or peering 806 interface. 808 Hereafter, we will define three types of BGP peering segments/SID's: 809 PeerNodeSID, PeerAdjSID and PeerSetSID. 811 o PeerNode SID. A BGP PeerNode segment/SID is a local segment. At 812 the BGP node advertising it, its semantics is: 814 * SR header operation: NEXT. 816 * Next-Hop: the connected peering node to which the segment is 817 related. 819 o PeerAdj SID: A BGP PeerAdj segment/SID is a local segment. At the 820 BGP node advertising it, its semantics is: 822 * SR header operation: NEXT. 824 * Next-Hop: the peer connected through the interface to which the 825 segment is related. 827 o PeerSet SID. A BGP PeerSet segment/SID is a local segment. At 828 the BGP node advertising it, its semantics is: 830 * SR header operation: NEXT. 832 * Next-Hop: loadbalance across any connected interface to any 833 peer in the related group. 835 A peer set could be all the connected peers from the same AS or a 836 subset of these. A group could also span across AS. The group 837 definition is a policy set by the operator. 839 The BGP extensions necessary in order to signal these BGP peering 840 segments will be defined in a separate document. 842 5. IGP Mirroring Context Segment 844 It is beneficial for an IGP node to be able to advertise its ability 845 to process traffic originally destined to another IGP node, called 846 the Mirrored node and identified by an IP address or a Node-SID, 847 provided that a "Mirroring Context" segment be inserted in the 848 segment list prior to any service segment local to the mirrored node. 850 When a given node B wants to provide egress node A protection, it 851 advertises a segment identifying node's A context. Such segment is 852 called "Mirror Context Segment" and identified by the Mirror SID. 854 The Mirror SID is advertised using the Binding Segment defined in SR 855 IGP protocol extensions ( [I-D.ietf-isis-segment-routing-extensions], 856 [I-D.ietf-ospf-segment-routing-extensions] and 857 [I-D.ietf-ospf-ospfv3-segment-routing-extensions]). 859 In the event of a failure, a point of local repair (PLR) diverting 860 traffic from A to B does a PUSH of the Mirror SID on the protected 861 traffic. B, when receiving the traffic with the Mirror SID as the 862 active segment, uses that segment and process underlying segments in 863 the context of A. 865 6. Multicast 867 Segment Routing is defined for unicast. The application of the 868 source-route concept to Multicast is not in the scope of this 869 document. 871 7. IANA Considerations 873 This document does not require any action from IANA. 875 8. Security Considerations 877 This document doesn't introduce new security considerations when 878 applied to the MPLS dataplane. 880 There are a number of security concerns with source routing at the 881 IPv6 dataplane [RFC5095]. The new IPv6-based segment routing header 882 defined in [I-D.ietf-6man-segment-routing-header] and its associated 883 security measures address these concerns. The IPv6 Segment Routing 884 Header is defined in a way that blind attacks are never possible, 885 i.e., attackers will be unable to send source routed packets that get 886 successfully processed, without being part of the negations for 887 setting up the source routes or being able to eavesdrop legitimate 888 source routed packets. In some networks this base level security may 889 be complemented with other mechanisms, such as packet filtering, 890 cryptographic security, etc. 892 9. Contributors 894 The following people have substantially contributed to the definition 895 of the Segment Routing architecture and to the editing of this 896 document: 898 Ahmed Bashandy 899 Cisco Systems, Inc. 900 Email: bashandy@cisco.com 902 Martin Horneffer 903 Deutsche Telekom 904 Email: Martin.Horneffer@telekom.de 906 Wim Henderickx 907 Alcatel-Lucent 908 Email: wim.henderickx@alcatel-lucent.com 910 Jeff Tantsura 911 Ericsson 912 Email: Jeff.Tantsura@ericsson.com 914 Edward Crabbe 915 Individual 916 Email: edward.crabbe@gmail.com 918 Igor Milojevic 919 Email: milojevicigor@gmail.com 921 Saku Ytti 922 TDC 923 Email: saku@ytti.fi 925 10. Acknowledgements 927 We would like to thank Dave Ward, Dan Frost, Stewart Bryant, Pierre 928 Francois, Thomas Telkamp, Les Ginsberg, Ruediger Geib, Hannes 929 Gredler, Pushpasis Sarkar, Eric Rosen and Chris Bowers for their 930 comments and review of this document. 932 11. References 934 11.1. Normative References 936 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 937 Requirement Levels", BCP 14, RFC 2119, 938 DOI 10.17487/RFC2119, March 1997, 939 . 941 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 942 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 943 December 1998, . 945 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 946 Label Switching Architecture", RFC 3031, 947 DOI 10.17487/RFC3031, January 2001, 948 . 950 [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) 951 Hierarchy with Generalized Multi-Protocol Label Switching 952 (GMPLS) Traffic Engineering (TE)", RFC 4206, 953 DOI 10.17487/RFC4206, October 2005, 954 . 956 11.2. Informative References 958 [I-D.filsfils-spring-large-scale-interconnect] 959 Filsfils, C., Cai, D., Previdi, S., Henderickx, W., 960 Shakir, R., Cooper, D., Ferguson, F., Lin, S., Laberge, 961 T., Decraene, B., Jalil, L., and J. Tantsura, 962 "Interconnecting Millions Of Endpoints With Segment 963 Routing", draft-filsfils-spring-large-scale- 964 interconnect-02 (work in progress), April 2016. 966 [I-D.francois-rtgwg-segment-routing-ti-lfa] 967 Francois, P., Filsfils, C., Bashandy, A., and B. Decraene, 968 "Topology Independent Fast Reroute using Segment Routing", 969 draft-francois-rtgwg-segment-routing-ti-lfa-00 (work in 970 progress), August 2015. 972 [I-D.ietf-6man-segment-routing-header] 973 Previdi, S., Filsfils, C., Field, B., Leung, I., Linkova, 974 J., Kosugi, T., Vyncke, E., and D. Lebrun, "IPv6 Segment 975 Routing Header (SRH)", draft-ietf-6man-segment-routing- 976 header-01 (work in progress), March 2016. 978 [I-D.ietf-isis-segment-routing-extensions] 979 Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., 980 Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS 981 Extensions for Segment Routing", draft-ietf-isis-segment- 982 routing-extensions-06 (work in progress), December 2015. 984 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] 985 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 986 Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3 987 Extensions for Segment Routing", draft-ietf-ospf-ospfv3- 988 segment-routing-extensions-05 (work in progress), March 989 2016. 991 [I-D.ietf-ospf-segment-routing-extensions] 992 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 993 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 994 Extensions for Segment Routing", draft-ietf-ospf-segment- 995 routing-extensions-08 (work in progress), April 2016. 997 [I-D.ietf-pce-segment-routing] 998 Sivabalan, S., Medved, J., Filsfils, C., Crabbe, E., 999 Lopez, V., Tantsura, J., Henderickx, W., and J. Hardwick, 1000 "PCEP Extensions for Segment Routing", draft-ietf-pce- 1001 segment-routing-07 (work in progress), March 2016. 1003 [I-D.ietf-spring-ipv6-use-cases] 1004 Brzozowski, J., Leddy, J., Leung, I., Previdi, S., 1005 Townsley, W., Martin, C., Filsfils, C., and R. Maglione, 1006 "IPv6 SPRING Use Cases", draft-ietf-spring-ipv6-use- 1007 cases-06 (work in progress), March 2016. 1009 [I-D.ietf-spring-oam-usecase] 1010 Geib, R., Filsfils, C., Pignataro, C., and N. Kumar, "A 1011 Scalable and Topology-Aware MPLS Dataplane Monitoring 1012 System", draft-ietf-spring-oam-usecase-03 (work in 1013 progress), April 2016. 1015 [I-D.ietf-spring-problem-statement] 1016 Previdi, S., Filsfils, C., Decraene, B., Litkowski, S., 1017 Horneffer, M., and R. Shakir, "SPRING Problem Statement 1018 and Requirements", draft-ietf-spring-problem-statement-08 1019 (work in progress), April 2016. 1021 [I-D.ietf-spring-resiliency-use-cases] 1022 Francois, P., Filsfils, C., Decraene, B., and R. Shakir, 1023 "Use-cases for Resiliency in SPRING", draft-ietf-spring- 1024 resiliency-use-cases-03 (work in progress), April 2016. 1026 [I-D.ietf-spring-segment-routing-central-epe] 1027 Filsfils, C., Previdi, S., Ginsburg, D., and D. Afanasiev, 1028 "Segment Routing Centralized BGP Peer Engineering", draft- 1029 ietf-spring-segment-routing-central-epe-01 (work in 1030 progress), March 2016. 1032 [I-D.ietf-spring-segment-routing-ldp-interop] 1033 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., and 1034 S. Litkowski, "Segment Routing interworking with LDP", 1035 draft-ietf-spring-segment-routing-ldp-interop-01 (work in 1036 progress), April 2016. 1038 [I-D.ietf-spring-segment-routing-mpls] 1039 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 1040 Litkowski, S., Horneffer, M., Shakir, R., Tantsura, J., 1041 and E. Crabbe, "Segment Routing with MPLS data plane", 1042 draft-ietf-spring-segment-routing-mpls-04 (work in 1043 progress), March 2016. 1045 [I-D.ietf-spring-segment-routing-msdc] 1046 Filsfils, C., Previdi, S., Mitchell, J., and P. Lapukhov, 1047 "BGP-Prefix Segment in large-scale data centers", draft- 1048 ietf-spring-segment-routing-msdc-01 (work in progress), 1049 April 2016. 1051 [I-D.ietf-spring-sr-oam-requirement] 1052 Kumar, N., Pignataro, C., Akiya, N., Geib, R., Mirsky, G., 1053 and S. Litkowski, "OAM Requirements for Segment Routing 1054 Network", draft-ietf-spring-sr-oam-requirement-01 (work in 1055 progress), December 2015. 1057 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 1058 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 1059 RFC 4915, DOI 10.17487/RFC4915, June 2007, 1060 . 1062 [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation 1063 of Type 0 Routing Headers in IPv6", RFC 5095, 1064 DOI 10.17487/RFC5095, December 2007, 1065 . 1067 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 1068 Topology (MT) Routing in Intermediate System to 1069 Intermediate Systems (IS-ISs)", RFC 5120, 1070 DOI 10.17487/RFC5120, February 2008, 1071 . 1073 [RFC6549] Lindem, A., Roy, A., and S. Mirtorabi, "OSPFv2 Multi- 1074 Instance Extensions", RFC 6549, DOI 10.17487/RFC6549, 1075 March 2012, . 1077 [RFC6822] Previdi, S., Ed., Ginsberg, L., Shand, M., Roy, A., and D. 1078 Ward, "IS-IS Multi-Instance", RFC 6822, 1079 DOI 10.17487/RFC6822, December 2012, 1080 . 1082 [RFC7794] Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and 1083 U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4 1084 and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794, 1085 March 2016, . 1087 Authors' Addresses 1089 Clarence Filsfils (editor) 1090 Cisco Systems, Inc. 1091 Brussels 1092 BE 1094 Email: cfilsfil@cisco.com 1096 Stefano Previdi (editor) 1097 Cisco Systems, Inc. 1098 Via Del Serafico, 200 1099 Rome 00142 1100 Italy 1102 Email: sprevidi@cisco.com 1104 Bruno Decraene 1105 Orange 1106 FR 1108 Email: bruno.decraene@orange.com 1110 Stephane Litkowski 1111 Orange 1112 FR 1114 Email: stephane.litkowski@orange.com 1116 Rob Shakir 1117 Jive Communications, Inc. 1118 1275 West 1600 North, Suite 100 1119 Orem, UT 84057 1121 Email: rjs@rob.sh