vnet/vnet/sr/rfc_draft_05.txt

   1 Network Working Group                                    S. Previdi, Ed.
   2 Internet-Draft                                               C. Filsfils
   3 Intended status: Standards Track                     Cisco Systems, Inc.
   4 Expires: June 12, 2015                                          B. Field
   5                                                                  Comcast
   6                                                                 I. Leung
   7                                                    Rogers Communications
   8                                                         December 9, 2014
   9
  10
  11                    IPv6 Segment Routing Header (SRH)
  12               draft-previdi-6man-segment-routing-header-05
  13
  14 Abstract
  15
  16    Segment Routing (SR) allows a node to steer a packet through a
  17    controlled set of instructions, called segments, by prepending a SR
  18    header to the packet.  A segment can represent any instruction,
  19    topological or service-based.  SR allows to enforce a flow through
  20    any path (topological, or application/service based) while
  21    maintaining per-flow state only at the ingress node to the SR domain.
  22
  23    Segment Routing can be applied to the IPv6 data plane with the
  24    addition of a new type of Routing Extension Header.  This draft
  25    describes the Segment Routing Extension Header Type and how it is
  26    used by SR capable nodes.
  27
  28 Requirements Language
  29
  30    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  31    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  32    document are to be interpreted as described in RFC 2119 [RFC2119].
  33
  34 Status of This Memo
  35
  36    This Internet-Draft is submitted in full conformance with the
  37    provisions of BCP 78 and BCP 79.
  38
  39    Internet-Drafts are working documents of the Internet Engineering
  40    Task Force (IETF).  Note that other groups may also distribute
  41    working documents as Internet-Drafts.  The list of current Internet-
  42    Drafts is at http://datatracker.ietf.org/drafts/current/.
  43
  44    Internet-Drafts are draft documents valid for a maximum of six months
  45    and may be updated, replaced, or obsoleted by other documents at any
  46    time.  It is inappropriate to use Internet-Drafts as reference
  47    material or to cite them other than as "work in progress."
  48
  49
  50
  51
  52 Previdi, et al.           Expires June 12, 2015                 [Page 1]
  53
  54 Internet-Draft      IPv6 Segment Routing Header (SRH)      December 2014
  55
  56
  57    This Internet-Draft will expire on June 12, 2015.
  58
  59 Copyright Notice
  60
  61    Copyright (c) 2014 IETF Trust and the persons identified as the
  62    document authors.  All rights reserved.
  63
  64    This document is subject to BCP 78 and the IETF Trust's Legal
  65    Provisions Relating to IETF Documents
  66    (http://trustee.ietf.org/license-info) in effect on the date of
  67    publication of this document.  Please review these documents
  68    carefully, as they describe your rights and restrictions with respect
  69    to this document.  Code Components extracted from this document must
  70    include Simplified BSD License text as described in Section 4.e of
  71    the Trust Legal Provisions and are provided without warranty as
  72    described in the Simplified BSD License.
  73
  74 Table of Contents
  75
  76    1.  Structure of this document  . . . . . . . . . . . . . . . . .   3
  77    2.  Segment Routing Documents . . . . . . . . . . . . . . . . . .   3
  78    3.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
  79      3.1.  Data Planes supporting Segment Routing  . . . . . . . . .   4
  80      3.2.  Illustration  . . . . . . . . . . . . . . . . . . . . . .   4
  81    4.  Abstract Routing Model  . . . . . . . . . . . . . . . . . . .   7
  82      4.1.  Segment Routing Global Block (SRGB) . . . . . . . . . . .   8
  83      4.2.  Traffic Engineering with SR . . . . . . . . . . . . . . .   9
  84      4.3.  Segment Routing Database  . . . . . . . . . . . . . . . .  10
  85    5.  IPv6 Instantiation of Segment Routing . . . . . . . . . . . .  10
  86      5.1.  Segment Identifiers (SIDs) and SRGB . . . . . . . . . . .  10
  87        5.1.1.  Node-SID  . . . . . . . . . . . . . . . . . . . . . .  11
  88        5.1.2.  Adjacency-SID . . . . . . . . . . . . . . . . . . . .  11
  89      5.2.  Segment Routing Extension Header (SRH)  . . . . . . . . .  11
  90        5.2.1.  SRH and RFC2460 behavior  . . . . . . . . . . . . . .  15
  91    6.  SRH Procedures  . . . . . . . . . . . . . . . . . . . . . . .  15
  92      6.1.  Segment Routing Operations  . . . . . . . . . . . . . . .  15
  93      6.2.  Segment Routing Node Functions  . . . . . . . . . . . . .  16
  94        6.2.1.  Ingress SR Node . . . . . . . . . . . . . . . . . . .  16
  95        6.2.2.  Transit Non-SR Capable Node . . . . . . . . . . . . .  18
  96        6.2.3.  SR Intra Segment Transit Node . . . . . . . . . . . .  18
  97        6.2.4.  SR Segment Endpoint Node  . . . . . . . . . . . . . .  18
  98      6.3.  FRR Flag Settings . . . . . . . . . . . . . . . . . . . .  18
  99    7.  SR and Tunneling  . . . . . . . . . . . . . . . . . . . . . .  18
 100    8.  Example Use Case  . . . . . . . . . . . . . . . . . . . . . .  19
 101    9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  21
 102    10. Manageability Considerations  . . . . . . . . . . . . . . . .  21
 103    11. Security Considerations . . . . . . . . . . . . . . . . . . .  21
 104    12. Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  21
 105
 106
 107
 108 Previdi, et al.           Expires June 12, 2015                 [Page 2]
 109
 110 Internet-Draft      IPv6 Segment Routing Header (SRH)      December 2014
 111
 112
 113    13. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  21
 114    14. References  . . . . . . . . . . . . . . . . . . . . . . . . .  21
 115      14.1.  Normative References . . . . . . . . . . . . . . . . . .  21
 116      14.2.  Informative References . . . . . . . . . . . . . . . . .  21
 117    Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  22
 118
 119 1.  Structure of this document
 120
 121    Section 3 gives an introduction on SR for IPv6 networks.
 122
 123    Section 4 describes the Segment Routing abstract model.
 124
 125    Section 5 defines the Segment Routing Header (SRH) allowing
 126    instantiation of SR over IPv6 dataplane.
 127
 128    Section 6 details the procedures of the Segment Routing Header.
 129
 130 2.  Segment Routing Documents
 131
 132    Segment Routing terminology is defined in
 133    [I-D.filsfils-spring-segment-routing].
 134
 135    Segment Routing use cases are described in
 136    [I-D.filsfils-spring-segment-routing-use-cases].
 137
 138    Segment Routing IPv6 use cases are described in
 139    [I-D.ietf-spring-ipv6-use-cases].
 140
 141    Segment Routing protocol extensions are defined in
 142    [I-D.ietf-isis-segment-routing-extensions], and
 143    [I-D.psenak-ospf-segment-routing-ospfv3-extension].
 144
 145    The security mechanisms of the Segment Routing Header (SRH) are
 146    described in [I-D.vyncke-6man-segment-routing-security].
 147
 148 3.  Introduction
 149
 150    Segment Routing (SR), defined in
 151    [I-D.filsfils-spring-segment-routing], allows a node to steer a
 152    packet through a controlled set of instructions, called segments, by
 153    prepending a SR header to the packet.  A segment can represent any
 154    instruction, topological or service-based.  SR allows to enforce a
 155    flow through any path (topological or service/application based)
 156    while maintaining per-flow state only at the ingress node to the SR
 157    domain.  Segments can be derived from different components: IGP, BGP,
 158    Services, Contexts, Locators, etc.  The list of segment forming the
 159    path is called the Segment List and is encoded in the packet header.
 160
 161
 162
 163
 164 Previdi, et al.           Expires June 12, 2015                 [Page 3]
 165
 166 Internet-Draft      IPv6 Segment Routing Header (SRH)      December 2014
 167
 168
 169    SR allows the use of strict and loose source based routing paradigms
 170    without requiring any additional signaling protocols in the
 171    infrastructure hence delivering an excellent scalability property.
 172
 173    The source based routing model described in
 174    [I-D.filsfils-spring-segment-routing] is inherited from the ones
 175    proposed by [RFC1940] and [RFC2460].  The source based routing model
 176    offers the support for explicit routing capability.
 177
 178 3.1.  Data Planes supporting Segment Routing
 179
 180    Segment Routing (SR), can be instantiated over MPLS
 181    ([I-D.filsfils-spring-segment-routing-mpls]) and IPv6.  This document
 182    defines its instantiation over the IPv6 data-plane based on the use-
 183    cases defined in [I-D.ietf-spring-ipv6-use-cases].
 184
 185    Segment Routing for IPv6 (SR-IPv6) is required in networks where MPLS
 186    data-plane is not used or, when combined with SR-MPLS, in networks
 187    where MPLS is used in the core and IPv6 is used at the edge (home
 188    networks, datacenters).
 189
 190    This document defines a new type of Routing Header (originally
 191    defined in [RFC2460]) called the Segment Routing Header (SRH) in
 192    order to convey the Segment List in the packet header as defined in
 193    [I-D.filsfils-spring-segment-routing].  Mechanisms through which
 194    segment are known and advertised are outside the scope of this
 195    document.
 196
 197 3.2.  Illustration
 198
 199    In the context of Figure 1 where all the links have the same IGP
 200    cost, let us assume that a packet P enters the SR domain at an
 201    ingress edge router I and that the operator requests the following
 202    requirements for packet P:
 203
 204       The local service S offered by node B must be applied to packet P.
 205
 206       The links AB and CE cannot be used to transport the packet P.
 207
 208       Any node N along the journey of the packet should be able to
 209       determine where the packet P entered the SR domain and where it
 210       will exit.  The intermediate node should be able to determine the
 211       paths from the ingress edge router to itself, and from itself to
 212       the egress edge router.
 213
 214       Per-flow State for packet P should only be created at the ingress
 215       edge router.
 216
 217
 218
 219
 220 Previdi, et al.           Expires June 12, 2015                 [Page 4]
 221
 222 Internet-Draft      IPv6 Segment Routing Header (SRH)      December 2014
 223
 224
 225       The operator can forbid, for security reasons, anyone outside the
 226       operator domain to exploit its intra-domain SR capabilities.
 227
 228    I---A---B---C---E
 229         \  |  / \ /
 230          \ | /   F
 231           \|/
 232            D
 233
 234                 Figure 1: An illustration of SR properties
 235
 236    All these properties may be realized by instructing the ingress SR
 237    edge router I to push the following abstract SR header on the packet
 238    P.
 239
 240    +---------------------------------------------------------------+
 241    |                                   |                           |
 242    |      Abstract SR Header           |                           |
 243    |                                   |                           |
 244    | {SD, SB, SS, SF, SE}, Ptr, SI, SE |        Transported        |
 245    |  ^                     |          |           Packet          |
 246    |  |                     |          |             P             |
 247    |  +---------------------+          |                           |
 248    |                                   |                           |
 249    +---------------------------------------------------------------+
 250
 251                        Figure 2: Packet P at node I
 252
 253    The abstract SR header contains a source route encoded as a list of
 254    segments {SD, SB, SS, SF, SE}, a pointer (Ptr) and the identification
 255    of the ingress and egress SR edge routers (segments SI and SE).
 256
 257    A segment identifies a topological instruction or a service
 258    instruction.  A segment can either be global or local.  The
 259    instruction associated with a global segment is recognized and
 260    executed by any SR-capable node in the domain.  The instruction
 261    associated with a local segment is only supported by the specific
 262    node that originates it.
 263
 264    Let us assume some IGP (i.e.: ISIS and OSPF) extensions to define a
 265    "Node Segment" as a global instruction within the IGP domain to
 266    forward a packet along the shortest path to the specified node.  Let
 267    us further assume that within the SR domain illustrated in Figure 1,
 268    segments SI, SD, SB, SE and SF respectively identify IGP node
 269    segments to I, D, B, E and F.
 270
 271    Let us assume that node B identifies its local service S with local
 272    segment SS.
 273
 274
 275
 276 Previdi, et al.           Expires June 12, 2015                 [Page 5]
 277
 278 Internet-Draft      IPv6 Segment Routing Header (SRH)      December 2014
 279
 280
 281    With all of this in mind, let us describe the journey of the packet
 282    P.
 283
 284    The packet P reaches the ingress SR edge router.  I pushes the SR
 285    header illustrated in Figure 2 and sets the pointer to the first
 286    segment of the list (SD).
 287
 288    SD is an instruction recognized by all the nodes in the SR domain
 289    which causes the packet to be forwarded along the shortest path to D.
 290
 291    Once at D, the pointer is incremented and the next segment is
 292    executed (SB).
 293
 294    SB is an instruction recognized by all the nodes in the SR domain
 295    which causes the packet to be forwarded along the shortest path to B.
 296
 297    Once at B, the pointer is incremented and the next segment is
 298    executed (SS).
 299
 300    SS is an instruction only recognized by node B which causes the
 301    packet to receive service S.
 302
 303    Once the service applied, the next segment is executed (SF) which
 304    causes the packet to be forwarded along the shortest path to F.
 305
 306    Once at F, the pointer is incremented and the next segment is
 307    executed (SE).
 308
 309    SE is an instruction recognized by all the nodes in the SR domain
 310    which causes the packet to be forwarded along the shortest path to E.
 311
 312    E then removes the SR header and the packet continues its journey
 313    outside the SR domain.
 314
 315    All of the requirements are met.
 316
 317    First, the packet P has not used links AB and CE: the shortest-path
 318    from I to D is I-A-D, the shortest-path from D to B is D-B, the
 319    shortest-path from B to F is B-C-F and the shortest-path from F to E
 320    is F-E, hence the packet path through the SR domain is I-A-D-B-C-F-E
 321    and the links AB and CE have been avoided.
 322
 323    Second, the service S supported by B has been applied on packet P.
 324
 325    Third, any node along the packet path is able to identify the service
 326    and topological journey of the packet within the SR domain.  For
 327    example, node C receives the packet illustrated in Figure 3 and hence
 328    is able to infer where the packet entered the SR domain (SI), how it
 329
 330
 331
 332 Previdi, et al.           Expires June 12, 2015                 [Page 6]
 333
 334 Internet-Draft      IPv6 Segment Routing Header (SRH)      December 2014
 335
 336
 337    got up to itself {SD, SB, SS, SE}, where it will exit the SR domain
 338    (SE) and how it will do so {SF, SE}.
 339
 340    +---------------------------------------------------------------+
 341    |                                   |                           |
 342    |           SR Header               |                           |
 343    |                                   |                           |
 344    | {SD, SB, SS, SF, SE}, Ptr, SI, SE |        Transported        |
 345    |               ^        |          |           Packet          |
 346    |               |        |          |             P             |
 347    |               +--------+          |                           |
 348    |                                   |                           |
 349    +---------------------------------------------------------------+
 350
 351                        Figure 3: Packet P at node C
 352
 353    Fourth, only node I maintains per-flow state for packet P.  The
 354    entire program of topological and service instructions to be executed
 355    by the SR domain on packet P is encoded by the ingress edge router I
 356    in the SR header in the form of a list of segments where each segment
 357    identifies a specific instruction.  No further per-flow state is
 358    required along the packet path.  The per-flow state is in the SR
 359    header and travels with the packet.  Intermediate nodes only hold
 360    states related to the IGP global node segments and the local IGP
 361    adjacency segments.  These segments are not per-flow specific and
 362    hence scale very well.  Typically, an intermediate node would
 363    maintain in the order of 100's to 1000's global node segments and in
 364    the order of 10's to 100 of local adjacency segments.  Typically the
 365    SR IGP forwarding table is expected to be much less than 10000
 366    entries.
 367
 368    Fifth, the SR header is inserted at the entrance to the domain and
 369    removed at the exit of the operator domain.  For security reasons,
 370    the operator can forbid anyone outside its domain to use its intra-
 371    domain SR capability.
 372
 373 4.  Abstract Routing Model
 374
 375    At the entrance of the SR domain, the ingress SR edge router pushes
 376    the SR header on top of the packet.  At the exit of the SR domain,
 377    the egress SR edge router removes the SR header.
 378
 379    The abstract SR header contains an ordered list of segments, a
 380    pointer identifying the next segment to process and the
 381    identifications of the ingress and egress SR edge routers on the path
 382    of this packet.  The pointer identifies the segment that MUST be used
 383    by the receiving router to process the packet.  This segment is
 384    called the active segment.
 385
 386
 387
 388 Previdi, et al.           Expires June 12, 2015                 [Page 7]
 389
 390 Internet-Draft      IPv6 Segment Routing Header (SRH)      December 2014
 391
 392
 393    A property of SR is that the entire source route of the packet,
 394    including the identity of the ingress and egress edge routers is
 395    always available with the packet.  This allows for interesting
 396    accounting and service applications.
 397
 398    We define three SR-header operations:
 399
 400       "PUSH": an SR header is pushed on an IP packet, or additional
 401       segments are added at the head of the segment list.  The pointer
 402       is moved to the first entry of the added segments.
 403
 404       "NEXT": the active segment is completed, the pointer is moved to
 405       the next segment in the list.
 406
 407       "CONTINUE": the active segment is not completed, the pointer is
 408       left unchanged.
 409
 410    In the future, other SR-header management operations may be defined.
 411
 412    As the packet travels through the SR domain, the pointer is
 413    incremented through the ordered list of segments and the source route
 414    encoded by the SR ingress edge node is executed.
 415
 416    A node processes an incoming packet according to the instruction
 417    associated with the active segment.
 418
 419    Any instruction might be associated with a segment: for example, an
 420    intra-domain topological strict or loose forwarding instruction, a
 421    service instruction, etc.
 422
 423    At minimum, a segment instruction must define two elements: the
 424    identity of the next-hop to forward the packet to (this could be the
 425    same node or a context within the node) and which SR-header
 426    management operation to execute.
 427
 428    Each segment is known in the network through a Segment Identifier
 429    (SID).  The terms "segment" and "SID" are interchangeable.
 430
 431 4.1.  Segment Routing Global Block (SRGB)
 432
 433    In the SR abstract model, a segment is identified by a Segment
 434    Routing Identifier (SID).  The SR abstract model doesn't mandate a
 435    specific format for the SID (IPv6 address or other formats).
 436
 437    In Segment Routing IPv6 the SID is an IPv6 address.  Therefore, the
 438    SRGB is materialized by the global IPv6 address space which
 439    represents the set of IPv6 routable addresses in the SR domain.  The
 440    following rules apply:
 441
 442
 443
 444 Previdi, et al.           Expires June 12, 2015                 [Page 8]
 445
 446 Internet-Draft      IPv6 Segment Routing Header (SRH)      December 2014
 447
 448
 449    o  Each node of the SR domain MUST be configured with the Segment
 450       Routing Global Block (SRGB).
 451
 452    o  All global segments must be allocated from the SRGB.  Any SR
 453       capable node MUST be able to process any global segment advertised
 454       by any other node within the SR domain.
 455
 456    o  Any segment outside the SRGB has a local significance and is
 457       called a "local segment".  An SR-capable node MUST be able to
 458       process the local segments it originates.  An SR-capable node MUST
 459       NOT support the instruction associated with a local segment
 460       originated by a remote node.
 461
 462 4.2.  Traffic Engineering with SR
 463
 464    An SR Traffic Engineering policy is composed of two elements: a flow
 465    classification and a segment-list to prepend on the packets of the
 466    flow.
 467
 468    In SR, this per-flow state only exists at the ingress edge node where
 469    the policy is defined and the SR header is pushed.
 470
 471    It is outside the scope of the document to define the process that
 472    leads to the instantiation at a node N of an SR Traffic Engineering
 473    policy.
 474
 475    [I-D.filsfils-spring-segment-routing-use-cases] illustrates various
 476    alternatives:
 477
 478       N is deriving this policy automatically (e.g.  FRR).
 479
 480       N is provisioned explicitly by the operator.
 481
 482       N is provisioned by a controller or server (e.g.: SDN Controller).
 483
 484       N is provisioned by the operator with a high-level policy which is
 485       mapped into a path thanks to a local CSPF-based computation (e.g.
 486       affinity/SRLG exclusion).
 487
 488       N could also be provisioned by other means.
 489
 490    [I-D.filsfils-spring-segment-routing-use-cases] explains why the
 491    majority of use-cases require very short segment-lists, hence
 492    minimizing the performance impact, if any, of inserting and
 493    transporting the segment list.
 494
 495
 496
 497
 498
 499
 500 Previdi, et al.           Expires June 12, 2015                 [Page 9]
 501
 502 Internet-Draft      IPv6 Segment Routing Header (SRH)      December 2014
 503
 504
 505    A SDN controller, which desires to instantiate at node N an SR
 506    Traffic Engineering policy, collects the SR capability of node N such
 507    as to ensure that the policy meets its capability.
 508
 509 4.3.  Segment Routing Database
 510
 511    The Segment routing Database (SRDB) is a set of entries where each
 512    entry is identified by a SID.  The instruction associated with each
 513    entry at least defines the identity of the next-hop to which the
 514    packet should be forwarded and what operation should be performed on
 515    the SR header (PUSH, CONTINUE, NEXT).
 516
 517    +---------+-----------+---------------------------------+
 518    | Segment |  Next-Hop |  SR Header operation            |
 519    +---------+-----------+---------------------------------+
 520    |   Sk    |     M     | CONTINUE                        |
 521    |   Sj    |     N     | NEXT                            |
 522    |   Sl    | NAT Srvc  | NEXT                            |
 523    |   Sm    |  FW srvc  | NEXT                            |
 524    |   Sn    |     Q     | NEXT                            |
 525    |  etc.   |   etc.    | etc.                            |
 526    +---------+-----------+---------------------------------+
 527
 528                            Figure 4: SR Database
 529
 530    Each SR-capable node maintains its local SRDB.  SRDB entries can
 531    either derive from local policy or from protocol segment
 532    advertisement.
 533
 534 5.  IPv6 Instantiation of Segment Routing
 535
 536 5.1.  Segment Identifiers (SIDs) and SRGB
 537
 538    Segment Routing, as described in
 539    [I-D.filsfils-spring-segment-routing], defines Node-SID and
 540    Adjacency-SID.  When SR is used over IPv6 data-plane the following
 541    applies.
 542
 543    The SRGB is the global IPv6 address space which represents the set of
 544    IPv6 routable addresses in the SR domain.
 545
 546    Node SIDs are IPv6 addresses part of the SRGB (i.e.: routable
 547    addresses).  Adjacency-SIDs are IPv6 addresses which may not be part
 548    of the global IPv6 address space.
 549
 550
 551
 552
 553
 554
 555
 556 Previdi, et al.           Expires June 12, 2015                [Page 10]
 557
 558 Internet-Draft      IPv6 Segment Routing Header (SRH)      December 2014
 559
 560
 561 5.1.1.  Node-SID
 562
 563    The Node-SID identifies a node.  With SR-IPv6 the Node-SID is an IPv6
 564    prefix that the operator configured on the node and that is used as
 565    the node identifier.  Typically, in case of a router, this is the
 566    IPv6 address of the node loopback interface.  Therefore, SR-IPv6 does
 567    not require any additional SID advertisement for the Node Segment.
 568    The Node-SID is in fact the IPv6 address of the node.
 569
 570 5.1.2.  Adjacency-SID
 571
 572    In the SR architecture defined in
 573    [I-D.filsfils-spring-segment-routing] the Adjacency-SID (or Adj-SID)
 574    identifies a given interface and may be local or global (depending on
 575    how it is advertised).  A node may advertise one (or more) Adj-SIDs
 576    allocated to a given interface so to force the forwarding of the
 577    packet (when received with that particular Adj-SID) into the
 578    interface regardless the routing entry for the packet destination.
 579    The semantic of the Adj-SID is:
 580
 581       Send out the packet to the interface this prefix is allocated to.
 582
 583    When SR is applied to IPv6, any SID is in a global IPv6 address and
 584    therefore, an Adj-SID has a global significance (i.e.: the IPv6
 585    address representing the SID is a global address).  In other words, a
 586    node that advertises the Adj-SID in the form of a global IPv6 address
 587    representing the link/adjacency the packet has to be forwarded to,
 588    will apply to the Adj-SID a global significance.
 589
 590    Advertisement of Adj-SID may be done using multiple mechanisms among
 591    which the ones described in ISIS and OSPF protocol extensions:
 592    [I-D.ietf-isis-segment-routing-extensions] and
 593    [I-D.psenak-ospf-segment-routing-ospfv3-extension].  The distinction
 594    between local and global significance of the Adj-SID is given in the
 595    encoding of the Adj-SID advertisement.
 596
 597 5.2.  Segment Routing Extension Header (SRH)
 598
 599    A new type of the Routing Header (originally defined in [RFC2460]) is
 600    defined: the Segment Routing Header (SRH) which has a new Routing
 601    Type, (suggested value 4) to be assigned by IANA.
 602
 603    As an example, if an explicit path is to be constructed across a core
 604    network running ISIS or OSPF, the segment list will contain SIDs
 605    representing the nodes across the path (loose or strict) which,
 606    usually, are the IPv6 loopback interface address of each node.  If
 607    the path is across service or application entities, the segment list
 608
 609
 610
 611
 612 Previdi, et al.           Expires June 12, 2015                [Page 11]
 613
 614 Internet-Draft      IPv6 Segment Routing Header (SRH)      December 2014
 615
 616
 617    contains the IPv6 addresses of these services or application
 618    instances.
 619
 620    The Segment Routing Header (SRH) is defined as follows:
 621
 622
 623      0                   1                   2                   3
 624      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 625     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 626     | Next Header   |  Hdr Ext Len  | Routing Type  | Segments Left |
 627     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 628     | First Segment |             Flags             |  HMAC Key ID  |
 629     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 630     |                                                               |
 631     |            Segment List[0] (128 bits ipv6 address)            |
 632     |                                                               |
 633     |                                                               |
 634     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 635     |                                                               |
 636     |                                                               |
 637                                   ...
 638     |                                                               |
 639     |                                                               |
 640     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 641     |                                                               |
 642     |            Segment List[n] (128 bits ipv6 address)            |
 643     |                                                               |
 644     |                                                               |
 645     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 646     |                                                               |
 647     |            Policy List[0] (optional)                          |
 648     |                                                               |
 649     |                                                               |
 650     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 651     |                                                               |
 652     |            Policy List[1] (optional)                          |
 653     |                                                               |
 654     |                                                               |
 655     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 656     |                                                               |
 657     |            Policy List[2] (optional)                          |
 658     |                                                               |
 659     |                                                               |
 660     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 661     |                                                               |
 662     |                                                               |
 663     |                                                               |
 664     |                       HMAC (256 bits)                         |
 665
 666
 667
 668 Previdi, et al.           Expires June 12, 2015                [Page 12]
 669
 670 Internet-Draft      IPv6 Segment Routing Header (SRH)      December 2014
 671
 672
 673     |                        (optional)                             |
 674     |                                                               |
 675     |                                                               |
 676     |                                                               |
 677     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 678
 679    where:
 680
 681    o  Next Header: 8-bit selector.  Identifies the type of header
 682       immediately following the SRH.
 683
 684    o  Hdr Ext Len: 8-bit unsigned integer, is the length of the SRH
 685       header in 8-octet units, not including the first 8 octets.
 686
 687    o  Routing Type: TBD, to be assigned by IANA (suggested value: 4).
 688
 689    o  Segments Left.  Defined in [RFC2460], it contains the index, in
 690       the Segment List, of the next segment to inspect.  Segments Left
 691       is decremented at each segment and it is used as an index in the
 692       segment list.
 693
 694    o  First Segment: offset in the SRH, not including the first 8 octets
 695       and expressed in 16-octet units, pointing to the last element of
 696       the segment list, which is in fact the first segment of the
 697       segment routing path.
 698
 699    o  Flags: 16 bits of flags.  Following flags are defined:
 700
 701                               1
 702           0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
 703          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 704          |C|P|R|R|    Policy Flags       |
 705          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 706
 707          C-flag: Clean-up flag.  Set when the SRH has to be removed from
 708          the packet when packet reaches the last segment.
 709
 710          P-flag: Protected flag.  Set when the packet has been rerouted
 711          through FRR mechanism by a SR endpoint node.  See Section 6.3
 712          for more details.
 713
 714          R-flags.  Reserved and for future use.
 715
 716          Policy Flags.  Define the type of the IPv6 addresses encoded
 717          into the Policy List (see below).  The following have been
 718          defined:
 719
 720
 721
 722
 723
 724 Previdi, et al.           Expires June 12, 2015                [Page 13]
 725
 726 Internet-Draft      IPv6 Segment Routing Header (SRH)      December 2014
 727
 728
 729             Bits 4-6: determine the type of the first element after the
 730             segment list.
 731
 732             Bits 7-9: determine the type of the second element.
 733
 734             Bits 10-12: determine the type of the third element.
 735
 736             Bits 13-15: determine the type of the fourth element.
 737
 738          The following values are used for the type:
 739
 740             0x0: Not present.  If value is set to 0x0, it means the
 741             element represented by these bits is not present.
 742
 743             0x1: SR Ingress.
 744
 745             0x2: SR Egress.
 746
 747             0x3: Original Source Address.
 748
 749    o  HMAC Key ID and HMAC field, and their use are defined in
 750       [I-D.vyncke-6man-segment-routing-security].
 751
 752    o  Segment List[n]: 128 bit IPv6 addresses representing the nth
 753       segment in the Segment List.  The Segment List is encoded starting
 754       from the last segment of the path.  I.e., the first element of the
 755       segment list (Segment List [0]) contains the last segment of the
 756       path while the last segment of the Segment List (Segment List[n])
 757       contains the first segment of the path.  The index contained in
 758       "Segments Left" identifies the current active segment.
 759
 760    o  Policy List.  Optional addresses representing specific nodes in
 761       the SR path such as:
 762
 763          SR Ingress: a 128 bit generic identifier representing the
 764          ingress in the SR domain (i.e.: it needs not to be a valid IPv6
 765          address).
 766
 767          SR Egress: a 128 bit generic identifier representing the egress
 768          in the SR domain (i.e.: it needs not to be a valid IPv6
 769          address).
 770
 771          Original Source Address: IPv6 address originally present in the
 772          SA field of the packet.
 773
 774       The segments in the Policy List are encoded after the segment list
 775       and they are optional.  If none are in the SRH, all bits of the
 776       Policy List Flags MUST be set to 0x0.
 777
 778
 779
 780 Previdi, et al.           Expires June 12, 2015                [Page 14]
 781
 782 Internet-Draft      IPv6 Segment Routing Header (SRH)      December 2014
 783
 784
 785 5.2.1.  SRH and RFC2460 behavior
 786
 787    The SRH being a new type of the Routing Header, it also has the same
 788    properties:
 789
 790       SHOULD only appear once in the packet.
 791
 792       Only the router whose address is in the DA field of the packet
 793       header MUST inspect the SRH.
 794
 795    Therefore, Segment Routing in IPv6 networks implies that the segment
 796    identifier (i.e.: the IPv6 address of the segment) is moved into the
 797    DA of the packet.
 798
 799    The DA of the packet changes at each segment termination/completion
 800    and therefore the original DA of the packet MUST be encoded as the
 801    last segment of the path.
 802
 803    As illustrated in Section 3.2, nodes that are within the path of a
 804    segment will forward packets based on the DA of the packet without
 805    inspecting the SRH.  This ensures full interoperability between SR-
 806    capable and non-SR-capable nodes.
 807
 808 6.  SRH Procedures
 809
 810    In this section we describe the different procedures on the SRH.
 811
 812 6.1.  Segment Routing Operations
 813
 814    When Segment Routing is instantiated over the IPv6 data plane the
 815    following applies:
 816
 817    o  The segment list is encoded in the SRH.
 818
 819    o  The active segment is in the destination address of the packet.
 820
 821    o  The Segment Routing CONTINUE operation (as described in
 822       [I-D.filsfils-spring-segment-routing]) is implemented as a
 823       regular/plain IPv6 operation consisting of DA based forwarding.
 824
 825    o  The NEXT operation is implemented through the update of the DA
 826       with the value represented by the Next Segment field in the SRH.
 827
 828    o  The PUSH operation is implemented through the insertion of the SRH
 829       or the insertion of additional segments in the SRH segment list.
 830
 831
 832
 833
 834
 835
 836 Previdi, et al.           Expires June 12, 2015                [Page 15]
 837
 838 Internet-Draft      IPv6 Segment Routing Header (SRH)      December 2014
 839
 840
 841 6.2.  Segment Routing Node Functions
 842
 843    SR packets are forwarded to segments endpoints (i.e.: nodes whose
 844    address is in the DA field of the packet).  The segment endpoint,
 845    when receiving a SR packet destined to itself, does:
 846
 847    o  Inspect the SRH.
 848
 849    o  Determine the next active segment.
 850
 851    o  Update the Segments Left field (or, if requested, remove the SRH
 852       from the packet).
 853
 854    o  Update the DA.
 855
 856    o  Send the packet to the next segment.
 857
 858    The procedures applied to the SRH are related to the node function.
 859    Following nodes functions are defined:
 860
 861       Ingress SR Node.
 862
 863       Transit Non-SR Node.
 864
 865       Transit SR Intra Segment Node.
 866
 867       SR Endpoint Node.
 868
 869 6.2.1.  Ingress SR Node
 870
 871    Ingress Node can be a router at the edge of the SR domain or a SR-
 872    capable host.  The ingress SR node may obtain the segment list by
 873    either:
 874
 875       Local path computation.
 876
 877       Local configuration.
 878
 879       Interaction with an SDN controller delivering the path as a
 880       complete SRH.
 881
 882       Any other mechanism (mechanisms through which the path is acquired
 883       are outside the scope of this document).
 884
 885    When creating the SRH (either at ingress node or in the SDN
 886    controller) the following is done:
 887
 888       Next Header and Hdr Ext Len fields are set according to [RFC2460].
 889
 890
 891
 892 Previdi, et al.           Expires June 12, 2015                [Page 16]
 893
 894 Internet-Draft      IPv6 Segment Routing Header (SRH)      December 2014
 895
 896
 897       Routing Type field is set as TBD (SRH).
 898
 899       The Segment List is built with the FIRST segment of the path
 900       encoded in the LAST element of the Segment List.  Subsequent
 901       segments are encoded on top of the first segment.  Finally, the
 902       LAST segment of the path is encoded in the FIRST element of the
 903       Segment List.  In other words, the Segment List is encoded in the
 904       reverse order of the path.
 905
 906       The original DA of the packet is encoded as the last segment of
 907       the path (encoded in the first element of the Segment List).
 908
 909       the DA of the packet is set with the value of the first segment
 910       (found in the last element of the segment list).
 911
 912       the Segments Left field is set to n-1 where n is the number of
 913       elements in the Segment List.
 914
 915       The packet is sent out towards the first segment (i.e.:
 916       represented in the packet DA).
 917
 918 6.2.1.1.  Security at Ingress
 919
 920    The procedures related to the Segment Routing security are detailed
 921    in [I-D.vyncke-6man-segment-routing-security].
 922
 923    In the case where the SR domain boundaries are not under control of
 924    the network operator (e.g.: when the SR domain edge is in a home
 925    network), it is important to authenticate and validate the content of
 926    any SRH being received by the network operator.  In such case, the
 927    security procedure described in
 928    [I-D.vyncke-6man-segment-routing-security] is to be used.
 929
 930    The ingress node (e.g.: the host in the home network) requests the
 931    SRH from a control system (e.g.: an SDN controller) which delivers
 932    the SRH with its HMAC signature on it.
 933
 934    Then, the home network host can send out SR packets (with an SRH on
 935    it) that will be validated at the ingress of the network operator
 936    infrastructure.
 937
 938    The ingress node of the network operator infrastructure, is
 939    configured in order to validate the incoming SRH HMACs in order to
 940    allow only packets having correct SRH according to their SA/DA
 941    addresses.
 942
 943
 944
 945
 946
 947
 948 Previdi, et al.           Expires June 12, 2015                [Page 17]
 949
 950 Internet-Draft      IPv6 Segment Routing Header (SRH)      December 2014
 951
 952
 953 6.2.2.  Transit Non-SR Capable Node
 954
 955    SR is interoperable with plain IPv6 forwarding.  Any non SR-capable
 956    node will forward SR packets solely based on the DA.  There's no SRH
 957    inspection.  This ensures full interoperability between SR and non-SR
 958    nodes.
 959
 960 6.2.3.  SR Intra Segment Transit Node
 961
 962    Only the node whose address is in DA inspects and processes the SRH
 963    (according to [RFC2460]).  An intra segment transit node is not in
 964    the DA and its forwarding is based on DA and its SR-IPv6 FIB.
 965
 966 6.2.4.  SR Segment Endpoint Node
 967
 968    The SR segment endpoint node is the node whose address is in the DA.
 969    The segment endpoint node inspects the SRH and does:
 970
 971    1.   IF DA = myself (segment endpoint)
 972    2.      IF Segments Left > 0 THEN
 973               decrement Segments Left
 974               update DA with Segment List[Segments Left]
 975    3.      ELSE IF Segments List[Segments Left] <> DA THEN
 976               update DA with Segments List[Segments Left]
 977               IF Clean-up bit is set THEN remove the SRH
 978    4.      ELSE give the packet to next PID (application)
 979                 End of processing.
 980    5.   Forward the packet out
 981
 982 6.3.  FRR Flag Settings
 983
 984    A node supporting SR and doing Fast Reroute (as described in
 985    [I-D.filsfils-spring-segment-routing-use-cases], when rerouting
 986    packets through FRR mechanisms, SHOULD inspect the rerouted packet
 987    header and look for the SRH.  If the SRH is present, the rerouting
 988    node SHOULD set the Protected bit on all rerouted packets.
 989
 990 7.  SR and Tunneling
 991
 992    Encapsulation can be realized in two different ways with SR-IPv6:
 993
 994       Outer encapsulation.
 995
 996       SRH with SA/DA original addresses.
 997
 998    Outer encapsulation tunneling is the traditional method where an
 999    additional IPv6 header is prepended to the packet.  The original IPv6
1000    header being encapsulated, everything is preserved and the packet is
1001
1002
1003
1004 Previdi, et al.           Expires June 12, 2015                [Page 18]
1005
1006 Internet-Draft      IPv6 Segment Routing Header (SRH)      December 2014
1007
1008
1009    switched/routed according to the outer header (that could contain a
1010    SRH).
1011
1012    SRH allows encoding both original SA and DA, hence an operator may
1013    decide to change the SA/DA at ingress and restore them at egress.
1014    This can be achieved without outer encapsulation, by changing SA/DA
1015    and encoding the original SA in the Policy List and in the original
1016    DA in the Segment List.
1017
1018 8.  Example Use Case
1019
1020    A more detailed description of use cases are available in
1021    [I-D.ietf-spring-ipv6-use-cases].  In this section, a simple SR-IPv6
1022    example is illustrated.
1023
1024    In the topology described in Figure 6 it is assumed an end-to-end SR
1025    deployment.  Therefore SR is supported by all nodes from A to J.
1026
1027     Home Network |          Backbone         |    Datacenter
1028                  |                           |
1029                  |   +---+   +---+   +---+   |   +---+   |
1030              +---|---| C |---| D |---| E |---|---| I |---|
1031              |   |   +---+   +---+   +---+   |   +---+   |
1032              |   |     |       |       |     |     |     |  +---+
1033    +---+   +---+ |     |       |       |     |     |     |--| X |
1034    | A |---| B | |   +---+   +---+   +---+   |   +---+   |  +---+
1035    +---+   +---+ |   | F |---| G |---| H |---|---| J |---|
1036                  |   +---+   +---+   +---+   |   +---+   |
1037                  |                           |
1038                  |        +-----------+
1039                           |    SDN    |
1040                           | Orch/Ctlr |
1041                           +-----------+
1042
1043                        Figure 6: Sample SR topology
1044
1045    The following workflow applies to packets sent by host A and destined
1046    to server X.
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060 Previdi, et al.           Expires June 12, 2015                [Page 19]
1061
1062 Internet-Draft      IPv6 Segment Routing Header (SRH)      December 2014
1063
1064
1065    . Host A sends a request for a path to server X to the SDN
1066      controller or orchestration system.
1067
1068    . The SDN controller/orchestrator builds a SRH with:
1069       . Segment List: C, F, J, X
1070       . HMAC
1071      that satisfies the requirements expressed in the request
1072      by host A and based on policies applicable to host A.
1073
1074    . Host A receives the SRH and insert it into the packet.
1075      The packet has now:
1076       . SA: A
1077       . DA: C
1078       . SRH with
1079          . SL: X, J, F, C
1080          . Segments Left: 3 (i.e.: Segment List size - 1)
1081          . PL: C (ingress), J (egress)
1082         Note that X is the last segment and C is the
1083         first segment (i.e.: the SL is encoded in the reverse
1084         path order).
1085       . HMAC
1086
1087    . When packet arrives in C (first segment), C does:
1088       . Validate the HMAC of the SRH.
1089       . Decrement Segments Left by one: 2
1090       . Update the DA with the next segment found in
1091         Segment List[2]. DA is set to F.
1092       . Forward the packet to F.
1093
1094    . When packet arrives in F (second segment), F does:
1095       . Decrement Segments Left by one: 1
1096       . Update the DA with the next segment found in
1097         Segment List[1]. DA is set to J.
1098       . Forward the packet to J.
1099
1100    . Packet travels across G and H nodes which do plain
1101      IPv6 forwarding based on DA. No inspection of SRH needs
1102      to be done in these nodes. However, any SR capable node
1103      is allowed to set the Protected bit in case of FRR
1104      protection.
1105
1106    . When packet arrives in J (third segment), J does:
1107       . Decrement Segments Left by one: 0
1108       . Update the DA with the next segment found in
1109         Segment List[0]. DA is set to X.
1110       . If the cleanup bit is set, then node J will strip out
1111         the SRH from the packet.
1112       . Forward the packet to X.
1113
1114
1115
1116 Previdi, et al.           Expires June 12, 2015                [Page 20]
1117
1118 Internet-Draft      IPv6 Segment Routing Header (SRH)      December 2014
1119
1120
1121    The packet arrives in the server that may or may not support SR.  The
1122    return traffic, from server to host, may be sent using the same
1123    procedures.
1124
1125 9.  IANA Considerations
1126
1127    TBD
1128
1129 10.  Manageability Considerations
1130
1131    TBD
1132
1133 11.  Security Considerations
1134
1135    Security mechanisms applied to Segment Routing over IPv6 networks are
1136    detailed in [I-D.vyncke-6man-segment-routing-security].
1137
1138 12.  Contributors
1139
1140    The authors would like to thank Dave Barach, John Leddy, John
1141    Brzozowski, Pierre Francois, Nagendra Kumar, Mark Townsley, Christian
1142    Martin, Roberta Maglione, Eric Vyncke, James Connolly, David Lebrun
1143    and Fred Baker for their contribution to this document.
1144
1145 13.  Acknowledgements
1146
1147    TBD
1148
1149 14.  References
1150
1151 14.1.  Normative References
1152
1153    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
1154               Requirement Levels", BCP 14, RFC 2119, March 1997.
1155
1156    [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
1157               (IPv6) Specification", RFC 2460, December 1998.
1158
1159 14.2.  Informative References
1160
1161    [I-D.filsfils-spring-segment-routing]
1162               Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,
1163               Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R.,
1164               Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe,
1165               "Segment Routing Architecture", draft-filsfils-spring-
1166               segment-routing-04 (work in progress), July 2014.
1167
1168
1169
1170
1171
1172 Previdi, et al.           Expires June 12, 2015                [Page 21]
1173
1174 Internet-Draft      IPv6 Segment Routing Header (SRH)      December 2014
1175
1176
1177    [I-D.filsfils-spring-segment-routing-mpls]
1178               Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,
1179               Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R.,
1180               Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe,
1181               "Segment Routing with MPLS data plane", draft-filsfils-
1182               spring-segment-routing-mpls-03 (work in progress), August
1183               2014.
1184
1185    [I-D.filsfils-spring-segment-routing-use-cases]
1186               Filsfils, C., Francois, P., Previdi, S., Decraene, B.,
1187               Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R.,
1188               Ytti, S., Henderickx, W., Tantsura, J., Kini, S., and E.
1189               Crabbe, "Segment Routing Use Cases", draft-filsfils-
1190               spring-segment-routing-use-cases-01 (work in progress),
1191               October 2014.
1192
1193    [I-D.ietf-isis-segment-routing-extensions]
1194               Previdi, S., Filsfils, C., Bashandy, A., Gredler, H.,
1195               Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS
1196               Extensions for Segment Routing", draft-ietf-isis-segment-
1197               routing-extensions-03 (work in progress), October 2014.
1198
1199    [I-D.ietf-spring-ipv6-use-cases]
1200               Brzozowski, J., Leddy, J., Leung, I., Previdi, S.,
1201               Townsley, W., Martin, C., Filsfils, C., and R. Maglione,
1202               "IPv6 SPRING Use Cases", draft-ietf-spring-ipv6-use-
1203               cases-03 (work in progress), November 2014.
1204
1205    [I-D.psenak-ospf-segment-routing-ospfv3-extension]
1206               Psenak, P., Previdi, S., Filsfils, C., Gredler, H.,
1207               Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3
1208               Extensions for Segment Routing", draft-psenak-ospf-
1209               segment-routing-ospfv3-extension-02 (work in progress),
1210               July 2014.
1211
1212    [I-D.vyncke-6man-segment-routing-security]
1213               Vyncke, E. and S. Previdi, "IPv6 Segment Routing Header
1214               (SRH) Security Considerations", July 2014.
1215
1216    [RFC1940]  Estrin, D., Li, T., Rekhter, Y., Varadhan, K., and D.
1217               Zappala, "Source Demand Routing: Packet Format and
1218               Forwarding Specification (Version 1)", RFC 1940, May 1996.
1219
1220 Authors' Addresses
1221
1222
1223
1224
1225
1226
1227
1228 Previdi, et al.           Expires June 12, 2015                [Page 22]
1229
1230 Internet-Draft      IPv6 Segment Routing Header (SRH)      December 2014
1231
1232
1233    Stefano Previdi (editor)
1234    Cisco Systems, Inc.
1235    Via Del Serafico, 200
1236    Rome  00142
1237    Italy
1238
1239    Email: sprevidi@cisco.com
1240
1241
1242    Clarence Filsfils
1243    Cisco Systems, Inc.
1244    Brussels
1245    BE
1246
1247    Email: cfilsfil@cisco.com
1248
1249
1250    Brian Field
1251    Comcast
1252    4100 East Dry Creek Road
1253    Centennial, CO  80122
1254    US
1255
1256    Email: Brian_Field@cable.comcast.com
1257
1258
1259    Ida Leung
1260    Rogers Communications
1261    8200 Dixie Road
1262    Brampton, ON  L6T 0C1
1263    CA
1264
1265    Email: Ida.Leung@rci.rogers.com