Network Working Group

Internet Engineering Task Force (IETF)                  A. Bashandy, Ed.
Internet Draft
Request for Comments: 8660                                        Arrcus
Intended status:
Category: Standards Track                               C. Filsfils, Ed.
Expires: November 2019
ISSN: 2070-1721                                               S. Previdi, Previdi
                                                     Cisco Systems, Inc.
                                                             B. Decraene
                                                            S. Litkowski
                                                                  Orange
                                                               R. Shakir
                                                                  Google
                                                            May 1,
                                                            October 2019

                Segment Routing with the MPLS data plane
                 draft-ietf-spring-segment-routing-mpls-22 Data Plane

Abstract

   Segment Routing (SR) leverages the source routing paradigm.  A node
   steers a packet through a controlled set of instructions, called
   segments, by prepending the packet with an SR header.  In the MPLS
   dataplane,
   data plane, the SR header is instantiated through a label stack.
   This document specifies the forwarding behavior to allow
   instantiating SR over the MPLS dataplane. data plane (SR-MPLS).

Status of this This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list  It represents the consensus of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid the IETF community.  It has
   received public review and has been approved for a maximum publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 7841.

   Information about the current status of six months this document, any errata,
   and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on November 1, 2019.
   https://www.rfc-editor.org/info/rfc8660.

Copyright Notice

   Copyright (c) 2019 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info)
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1. Introduction...................................................3  Introduction
     1.1.  Requirements Language.....................................4 Language
   2.  MPLS Instantiation of Segment Routing..........................4 Routing
     2.1.  Multiple Forwarding Behaviors for the Same Prefix.........4 Prefix
     2.2.  SID Representation in the MPLS Forwarding Plane...........5 Plane
     2.3.  Segment Routing Global Block and Local Block..............5 Block
     2.4.  Mapping a SID Index to an MPLS label......................6 Label
     2.5.  Incoming Label Collision..................................7 Collision
       2.5.1. Tie-breaking Rules..................................10  Tiebreaking Rules
       2.5.2.  Redistribution between Routing Protocol Instances...13
            2.5.2.1. Illustration...................................13
            2.5.2.2. Illustration 2.................................14 Instances
     2.6.  Effect of Incoming Label Collision on Outgoing Label
      Programming...................................................14
            Programming
     2.7.  PUSH, CONTINUE, and NEXT.................................15 NEXT
       2.7.1. PUSH................................................15  PUSH
       2.7.2. CONTINUE............................................15  CONTINUE
       2.7.3. NEXT................................................15
            2.7.3.1. Mirror SID.....................................16  NEXT
     2.8.  MPLS Label Downloaded to the FIB for Global and Local SIDs...16
            SIDs
     2.9.  Active Segment...........................................16 Segment
     2.10. Forwarding behavior Behavior for Global SIDs.....................16 SIDs
       2.10.1.  Forwarding for PUSH and CONTINUE of Global SIDs....17 SIDs
       2.10.2.  Forwarding for the NEXT Operation for Global SIDs......18
               SIDs
     2.11. Forwarding Behavior for Local SIDs......................18 SIDs
       2.11.1.  Forwarding for the PUSH Operation on Local SIDs........19 SIDs
       2.11.2.  Forwarding for the CONTINUE Operation for Local SIDs...19
               SIDs
       2.11.3.  Outgoing label Label for the NEXT Operation for Local SIDs...19
               SIDs
   3.  IANA Considerations...........................................19 Considerations
   4.  Manageability Considerations..................................20 Considerations
   5.  Security Considerations.......................................20 Considerations
   6. Contributors..................................................20
   7. Acknowledgements..............................................20
   8. References....................................................21
      8.1.  References
     6.1.  Normative References.....................................21
      8.2. References
     6.2.  Informative References...................................22
   9. Authors' Addresses............................................24 References
   Appendix A. Examples.............................................26  Examples
     A.1.  IGP Segments Example.....................................26 Segment Examples
     A.2.  Incoming Label Collision Examples........................28 Examples
       A.2.1.  Example 1...........................................28 1
       A.2.2.  Example 2...........................................29 2
       A.2.3.  Example 3...........................................30 3
       A.2.4.  Example 4...........................................30 4
       A.2.5.  Example 5...........................................31 5
       A.2.6.  Example 6...........................................31 6
       A.2.7.  Example 7...........................................32 7
       A.2.8.  Example 8...........................................32 8
       A.2.9.  Example 9...........................................33 9
       A.2.10. Example 10.........................................33 10
       A.2.11. Example 11.........................................34 11
       A.2.12. Example 12.........................................35 12
       A.2.13. Example 13.........................................35 13
       A.2.14. Example 14.........................................36 14
     A.3.  Examples for the Effect of Incoming Label Collision on
           an Outgoing Label................................................36 Label
       A.3.1.  Example 1...........................................36 1
       A.3.2.  Example 2...........................................37 2
   Acknowledgements
   Contributors
   Authors' Addresses

1.  Introduction

   The Segment Routing architecture RFC8402 [RFC8402] can be directly applied to
   the MPLS architecture with no change in the MPLS forwarding plane.
   This document specifies the forwarding plane forwarding-plane behavior to allow Segment
   Routing to operate on top of the MPLS data plane. plane (SR-MPLS).  This
   document does not address the control plane control-plane behavior. Control plane  Control-plane
   behavior is specified in other documents such as [I-D.ietf-isis-
   segment-routing-extensions], [I-D.ietf-ospf-segment-routing-
   extensions], [RFC8665],
   [RFC8666], and [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. [RFC8667].

   The Segment Routing problem statement is described in [RFC7855].

   Co-existence

   Coexistence of SR over the MPLS forwarding plane with LDP [RFC5036]
   is specified in [I-D.ietf-spring-segment-routing-ldp-interop]. [RFC8661].

   Policy routing and traffic engineering using segment routing Segment Routing can be
   found in [I-D.ietf-spring-segment-routing-policy] [ROUTING-POLICY].

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2.  MPLS Instantiation of Segment Routing

   MPLS instantiation of Segment Routing fits in the MPLS architecture
   as defined in [RFC3031] both from both a control plane control-plane and forwarding forwarding-
   plane perspective:

   o

   *  From a control plane control-plane perspective, [RFC3031] does not mandate a
      single signaling protocol.  Segment Routing makes use of various
      control plane
      control-plane protocols such as link state link-state IGPs [I-D.ietf-isis-
      segment-routing-extensions], [I-D.ietf-ospf-segment-routing-
      extensions] and [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. [RFC8665]
      [RFC8666] [RFC8667].  The flooding mechanisms of link state link-state IGPs
      fit very well with label stacking on the ingress. Future control layer  A future
      control-layer protocol and/or policy/configuration can be used to
      specify the label stack.

   o

   *  From a forwarding plane forwarding-plane perspective, Segment Routing does not
      require any change to the forwarding plane because Segment IDs
      (SIDs) are instantiated as MPLS labels labels, and the Segment routing Routing
      header is instantiated as a stack of MPLS labels.

   We call the "MPLS Control Plane Client (MCC)" any control plane control-plane
   entity installing forwarding entries in the MPLS data plane.  Local
   configuration and policies applied on a router are examples of MCCs.

   In order to have a node segment reach the node, a network operator
   SHOULD configure at least one node segment per routing instance,
   topology, or algorithm.  Otherwise, the node is not reachable within
   the routing instance, topology within the topology, or along the routing
   algorithm, which
   restrict restricts its ability to be used by a an SR policy, including for TI-LFA. Policy and
   as a Topology Independent Loop-Free Alternate (TI-LFA).

2.1.  Multiple Forwarding Behaviors for the Same Prefix

   The SR architecture does not prohibit having more than one SID for
   the same prefix.  In fact, by allowing multiple SIDs for the same
   prefix, it is possible to have different forwarding behaviors (such
   as different paths, different ECMP/UCMP behaviors,...,etc) ECMP and Unequal-Cost Multipath (UCMP)
   behaviors, etc.) for the same destination.

   Instantiating Segment routing Routing over the MPLS forwarding plane fits
   seamlessly with this principle.  An operator may assign multiple MPLS
   labels or indices to the same prefix and assign different forwarding
   behaviors to each label/SID.  The MCC in the network downloads
   different MPLS labels/SIDs to the FIB for different forwarding
   behaviors.  The MCC at the entry of an SR domain or at any point in
   the domain can choose to apply a particular forwarding behavior to a
   particular packet by applying the PUSH action to that packet using
   the corresponding SID.

2.2.  SID Representation in the MPLS Forwarding Plane

   When instantiating SR over the MPLS forwarding plane, a SID is
   represented by an MPLS label or an index [RFC8402].

   A global segment SID is a label, or an index which that may be mapped to an MPLS
   label within the Segment Routing Global Block (SRGB) (SRGB), of the node
   installing the
   that installs a global segment SID in its FIB/receiving FIB and receives the labeled
   packet.  Section 2.4 specifies the procedure to map a global segment
   represented by an index to an MPLS label within the SRGB.

   The MCC MUST ensure that any label value corresponding to any SID it
   installs in the forwarding plane follows the following rules:

   o rules below:

   *  The label value MUST be unique within the router on which the MCC
      is running. i.e. running, i.e., the label MUST only be used to represent the SID
      and MUST NOT be used to represent more than one SID or for any
      other forwarding purpose on the router.

   o

   *  The label value MUST NOT come from the range of special purpose special-purpose
      labels [RFC7274].

   Labels allocated in this document are considered per platform down-
   stream per-platform
   downstream allocated labels [RFC3031].

2.3.  Segment Routing Global Block and Local Block

   The concepts of Segment Routing Global Block (SRGB) SRGB and global SID are explained in [RFC8402].  In
   general, the SRGB need not be a contiguous range of labels.

   For the rest of this document, the SRGB is specified by the list of
   MPLS Label label ranges [Ll(1),Lh(1)], [Ll(2),Lh(2)],..., [Ll(k),Lh(k)]
   where Ll(i) =< Lh(i).

   The following rules apply to the list of MPLS ranges representing the
   SRGB

   o
   SRGB:

   *  The list of ranges comprising the SRGB MUST NOT overlap.

   o

   *  Every range in the list of ranges specifying the SRGB MUST NOT
      cover or overlap with a reserved label value or range [RFC7274],
      respectively.

   o

   *  If the SRGB of a node does not conform to the structure specified
      in this section or to the previous two rules, then this the SRGB MUST be
      completely ignored by all routers in the routing domain domain, and the
      node MUST be treated as if it does not have an SRGB.

   o

   *  The list of label ranges MUST only be used to instantiate global
      SIDs into the MPLS forwarding plane plane.

   A Local local segment MAY be allocated from the Segment Routing Local Block
   (SRLB) [RFC8402] or from any unused label as long as it does not use
   a special purpose special-purpose label.  The SRLB consists of the range of local
   labels reserved by the node for certain local segments.  In a
   controller-driven network, some controllers or applications MAY use
   the control plane to discover the available set of local SIDs on a
   particular router [I-D.ietf-spring-segment-routing-policy]. [ROUTING-POLICY].  The rules applicable to the SRGB
   are also applicable to the SRLB, except the
   rule that says that the SRGB MUST only be used to
   instantiate global SIDs into the MPLS forwarding plane.  The
   recommended, minimum, or maximum size of the SRGB and/or SRLB is a
   matter of future study study.

2.4.  Mapping a SID Index to an MPLS label Label

   This sub-section subsection specifies how the MPLS label value is calculated
   given the index of a SID.  The value of the index is determined by an
   MCC such as IS-IS [I-D.ietf-isis-segment-routing-extensions] [RFC8667] or OSPF
   [I-D.ietf-ospf-segment-routing-extensions]. [RFC8665].  This section only
   specifies how to map the index to an MPLS label.  The calculated MPLS
   label is downloaded to the FIB, sent out with a forwarded packet, or
   both.

   Consider a SID represented by the index "I".  Consider an SRGB as
   specified in Section 2.3.  The total size of the SRGB, represented by
   the variable "Size", is calculated according to the formula:

   size = Lh(1)- Ll(1) + 1 + Lh(2)- Ll(2) + 1 + ... + Lh(k)- Ll(k) + 1

   The following rules MUST be applied by the MCC when calculating the
   MPLS label value corresponding to the SID index value "I".

   o

      0 =< I < size.  If the index "I" does not satisfy the previous
      inequality, then the label cannot be calculated.

   o

      The label value corresponding to the SID index "I" is calculated
      as follows

       o follows:

         j = 1 , temp = 0

       o

         While temp + Lh(j)- Ll(j) < I

            .

            temp = temp + Lh(j)- Ll(j) + 1

            .

            j = j+1

       o

         label = I - temp + Ll(j)

   An example for how a router calculates labels and forwards traffic
   based on the procedure described in this section can be found in
   Appendix A.1.

2.5.  Incoming Label Collision

   The MPLS Architecture [RFC3031] defines the term Forwarding
   Equivalence Class (FEC) as the set of packets with similar and / or and/or
   identical characteristics which that are forwarded the same way and are
   bound to the same MPLS incoming (local) label.  In Segment-Routing Segment Routing
   MPLS, a local label serves as the SID for a given FEC.

   We define Segment Routing (SR) SR FEC [RFC8402] as one of the following [RFC8402]:

   o following:

   *  (Prefix, Routing Instance, Topology, Algorithm [RFC8402]), Algorithm) [RFC8402], where a
      topology identifies a set of links with metrics.  For the purpose
      of incoming label collision resolution, the same Topology
      numerical value SHOULD be used on all routers to identify the same
      set of links with metrics.  For MCCs where the "Topology" and/or
      "Algorithm" fields are not defined, the numerical value of zero
      MUST be used for these two fields.  For the purpose of incoming
      label collision resolution, a routing instance is identified by a
      single incoming label downloader to the FIB.  Two MCCs running on
      the same router are considered different routing instances if the
      only way the two instances can know about the each other's incoming labels
      is through redistribution.  The numerical value used to identify a
      routing instance MAY be derived from other configuration or MAY be
      explicitly configured.  If it is derived from other configuration,
      then the same numerical value SHOULD be derived from the same
      configuration as long as the configuration survives router reload.
      If the derived numerical value varies for the same configuration,
      then an implementation SHOULD make the numerical value used to
      identify a routing instance configurable.

   o

   *  (next-hop, outgoing interface), where the outgoing interface is
      physical or virtual.

   o

   *  (number of adjacencies, list of next-hops, list of outgoing
      interfaces IDs in ascending numerical order).  This FEC represents
      parallel adjacencies [RFC8402]

   o [RFC8402].

   *  (Endpoint, Color) representing Color).  This FEC represents an SR policy [RFC8402]

   o  (Mirrored SID) Policy [RFC8402].

   *  (Mirror SID).  The Mirrored Mirror SID [RFC8402, (see [RFC8402], Section 5.1] 5.1) is the
      IP address advertised by the advertising node to identify the mirror-
      Mirror SID.  The IP address is encoded as specified in
      Section 2.5.1.

   This section covers the RECOMMENDED procedure to handle for handling the
   scenario where, because of an error/misconfiguration, more than one
   SR FEC as defined in this section, map section maps to the same incoming MPLS
   label.  Examples illustrating the behavior specified in this section
   can be found in Appendix A.2.

   An incoming label collision occurs if the SIDs of the set of FECs
   {FEC1, FEC2,..., FEC2, ..., FECk} map to the same incoming SR MPLS label "L1".

   Suppose an anycast prefix is advertised with a prefix-SID by some,
   but not all, of the nodes that advertise that prefix.  If the prefix-
   SID sub-TLVs result in mapping that anycast prefix to the same
   incoming label, then the advertisement of the prefix-SID by some, but
   not all, of the advertising nodes MUST NOT be treated as a label
   collision.

   An implementation MUST NOT allow the MCCs belonging to the same
   router to assign the same incoming label to more than one SR FEC.

   The objective of the following steps is to deterministically install
   in the MPLS Incoming Label Map, also known as label FIB, a single FEC
   with the incoming label "L1".  By "deterministically install" install", we
   mean if the set of FECs {FEC1, FEC2,..., FECk} map to the same
   incoming SR MPLS label "L1", then the steps below assign the same FEC
   to the label "L1" irrespective of the order by which the mappings of
   this set of FECs to the label "L1" are received.  For example, a first-
   come-first-serve tie-breaking
   come, first-served tiebreaking is not allowed.  The remaining FECs
   may be installed in the IP FIB without an incoming label.

   The procedure in this section relies completely on the local FEC and
   label database within a given router.

   The collision resolution procedure is as follows follows:

   1.  Given the SIDs of the set of FECs, {FEC1, FEC2,..., FECk} map to
       the same MPLS label "L1".

   2.  Within an MCC, apply tie-breaking tiebreaking rules to select one FEC only only,
       and assign the label to it.  The losing FECs are handled as if no
       labels are attached to them.  The losing FECs with algorithms
       other than the shortest path first [RFC8402] are not installed in
       the FIB.

       a.  If the same set of FECs are attached to the same label "L1",
           then the tie-breaking tiebreaking rules MUST always select the same FEC
           irrespective of the order in which the FECs and the label
           "L1" are received.  In other words, the tie-breaking tiebreaking rule MUST
           be deterministic.

   3.  If there is still collision between the FECs belonging to
       different MCCs, then re-apply reapply the tie-breaking tiebreaking rules to the
       remaining FECs to select one FEC only only, and assign the label to
       that
      FEC FEC.

   4.  Install the selected FEC into the IP FIB the selected FEC and its incoming label in
       into the label FIB.

   5.  The remaining FECs with the default algorithm (see the
      specification of prefix-SID
       algorithm specification [RFC8402]) may be installed in the FIB
       natively, such as pure IP entries in case of Prefix FEC, without
       any incoming labels corresponding to their SIDs.  The remaining
       FECs with algorithms other than the shortest path first [RFC8402]
       are not installed in the FIB.

2.5.1. Tie-breaking  Tiebreaking Rules

   The default tie-breaking tiebreaking rules are specified as follows:

   1. if FECi has  Determine the lowest FEC administrative distance among the competing
       FECs as defined in this the section below, below.  Then filter away all the
       competing FECs with a higher administrative distance.

   2. if  If more than one competing FEC remains after step 1, select the
       smallest numerical FEC value.  The numerical value of the FEC is
       determined according to the FEC encoding described later in this
       section.

   These rules deterministically select the which FEC to install in the MPLS
   forwarding plane for the given incoming label.

   This document defines the default tie breaking tiebreaking rules that SHOULD be
   implemented.  An implementation MAY choose to support different tie-
   breaking
   tiebreaking rules and MAY use one of the these instead of the default
   tie-breaking
   tiebreaking rules.  To maximize MPLS forwarding consistency in case
   of a SID configuration error, the network operator MUST deploy,
   within an IGP flooding area, routers implementing the same tie-breaking
   tiebreaking rules.

   Each FEC is assigned an administrative distance.  The FEC
   administrative distance is encoded as an 8-bit value.  The lower the
   value, the better the administrative distance.

   The default FEC administrative distance order starting from the
   lowest value SHOULD be:

   o

   *  Explicit SID assignment to a FEC that maps to a label outside the
      SRGB irrespective of the owner MCC.  An explicit SID assignment is
      a static assignment of a label to a FEC such that the assignment
      survives a router reboot.

       o

      -  An example of explicit SID allocation is static assignment of a
         specific label to an adj-SID.

       o Adj-SID.

      -  An implementation of explicit SID assignment MUST guarantee
         collision freeness on the same router

   o router.

   *  Dynamic SID assignment:

       o For all

      -  All FEC types types, except for SR policy, the FEC types SR Policy, are ordered using the
         default administrative distance ordering defined by the implementation.

       o

      -  The Binding SID [RFC8402] assigned to the SR Policy always has
         a higher default administrative distance than the default
         administrative distance of any other FEC type type.

   To maximize MPLS forwarding consistency, If a if the same FEC is
   advertised in more than one protocol, a user MUST ensure that the
   administrative distance preference between protocols is the same on
   all routers of the IGP flooding domain.  Note that this is not really
   new as this already applies to IP forwarding.

   The numerical sort across FECs SHOULD be performed as follows:

   o

   *  Each FEC is assigned a FEC type encoded in 8 bits.  The following
      are the type code point
      points for each SR FEC defined at the beginning of this Section:

       o section
      are as follows:

         120:  (Prefix, Routing Instance, Topology, Algorithm)

       o

         130:  (next-hop, outgoing interface)

       o

         140:  Parallel Adjacency [RFC8402]

       o

         150: an  SR policy [RFC8402].

       o Policy [RFC8402]

         160:  Mirror SID [RFC8402]

       o

      The numerical values above are mentioned to guide implementation.
      If other numerical values are used, then the numerical values must
      maintain the same greater-than ordering of the numbers mentioned
      here.

   o

   *  The fields of each FEC are encoded as follows

       o follows:

      -  All fields in all FECs are encoded in big endian
       o order.

      -  The Routing Instance ID is represented by 16 bits.  For routing
         instances that are identified by less than 16 bits, encode the
         Instance ID in the least significant bits while the most
         significant bits are set to zero

       o Address Family zero.

      -  The address family is represented by 8 bits, where IPv4 is
         encoded as
         100 100, and IPv6 is encoded as 110.  These numerical
         values are mentioned to guide implementations.  If other
         numerical values are used, then the numerical value of IPv4
         MUST be less than the numerical value for IPv6

       o IPv6.

      -  All addresses are represented in 128 bits as follows

            . follows:

         o  The IPv6 address is encoded natively

            . natively.

         o  The IPv4 address is encoded in the most significant bits bits,
            and the remaining bits are set to zero

       o zero.

      -  All prefixes are represented by (8 + 128) bits.

            .

         o  A prefix is encoded in the most significant bits bits, and the
            remaining bits are set to zero.

            .

         o  The prefix length is encoded before the prefix in a field
               of size 8 bits.

       o an 8-bit
            field.

      -  The Topology ID is represented by 16 bits.  For routing
         instances that identify topologies using less than 16 bits,
         encode the topology ID in the least significant bits while the
         most significant bits are set to zero

       o zero.

      -  The Algorithm is encoded in a 16 bits 16-bit field.

       o

      -  The Color ID is encoded using 32 bits

   o bits.

   *  Choose the set of FECs of the smallest FEC type code point

   o point.

   *  Out of these FECs, choose the FECs with the smallest address
      family code point

   o point.

   *  Encode the remaining set of FECs as follows

       o follows:

      -  (Prefix, Routing Instance, Topology, Algorithm) is encoded as
         (Prefix Length, Prefix, routing_instance_id, Topology, SR
         Algorithm)
       o
         Algorithm).

      -  (next-hop, outgoing interface) is encoded as (next-hop,
         outgoing_interface_id)

      o
         outgoing_interface_id).

      -  (number of adjacencies, list of next-hops in ascending
         numerical order, list of outgoing interface IDs in ascending
         numerical order). This encoding order) is used to encode a parallel adjacency [RFC8402]

       o
         [RFC8402].

      -  (Endpoint, Color) is encoded as (Endpoint_address, Color_id)

       o Color_id).

      -  (IP address): This address) is the encoding for a mirror Mirror SID FEC.  The IP
         address is encoded as described above in this section

   o section.

   *  Select the FEC with the smallest numerical value value.

   The numerical values mentioned in this section are for guidance only.
   If other numerical values are used used, then the other numerical values
   MUST maintain the same numerical ordering among different SR FECs.

2.5.2.  Redistribution between Routing Protocol Instances

   The following rule SHOULD be applied when redistributing SIDs with
   prefixes between routing protocol instances:

   o

   *  If the receiving instance's SRGB of the receiving instance is the same as the SRGB of
      the origin instance, then

       o then:

      -  the index is redistributed with the route

   o  Else

       o route.

   *  Else,

      -  the index is not redistributed and if the receiving instance
         decides to advertise an index with the redistributed route, it
         is the duty of the receiving instance to allocate a fresh index
         relative to its own SRGB.  Note that in this case case, the
         receiving instance MUST compute the local label it assignes assigns to
         the route according to section Section 2.4 and install it in FIB.

   It is outside the scope of this document to define local node
   behaviors that would allow to map the mapping of the original index into a
   new index in the receiving instance via the addition of an offset or
   other policy means.

2.5.2.1.  Illustration

           A----IS-IS----B---OSPF----C-192.0.2.1/32 (20001)

   Consider the simple topology above.

   o above, where:

   *  A and B are in the IS-IS domain with SRGB = [16000-17000]

   o

   *  B and C are in the OSPF domain with SRGB = [20000-21000]

   o

   *  B redistributes 192.0.2.1/32 into the IS-IS domain

   o

   In that case this case, A learns 192.0.2.1/32 as an IP leaf connected to B as B,
   which is usual for IP prefix redistribution

   o

   However, according to the redistribution rule above rule, above, B decides not to
   advertise any index with 192.0.2.1/32 into IS-IS because the SRGB is
   not the same.

2.5.2.2.  Illustration 2

   Consider the example in the illustration described in
   Section 2.5.2.1.

   When router B redistributes the prefix 192.0.2.1/32, router B decides
   to allocate and advertise the same index 1 with the prefix
   192.0.2.1/32
   192.0.2.1/32.

   Within the SRGB of the IS-IS domain, index 1 corresponds to the local
   label 16001

   o  Hence 16001.  Hence, according to the redistribution rule above,
   router B programs the incoming label 16001 in its FIB to match
   traffic arriving from the IS-IS domain destined to the prefix
   192.0.2.1/32.

2.6.  Effect of Incoming Label Collision on Outgoing Label Programming

   For the determination of the

   When determining what outgoing label to use, the ingress node
   pushing that
   pushes new segments, and hence a stack of MPLS labels, MUST use, for
   a given FEC, the same label that has been selected by the node receiving
   the packet with that label exposed as the top label.  So in case of
   incoming label collision on this receiving node, the ingress node
   MUST resolve this collision by using this same "Incoming Label
   Collision resolution procedure", procedure" and by using the data of the
   receiving node.

   In the general case, the ingress node may not have exactly the exact same
   data of as the receiving node, so the result may be different.  This is
   under the responsibility of the network operator.  But in a typical
   case, e.g. e.g., where a centralized node or a distributed link state link-state IGP
   is used, all nodes would have the same database. However  However, to
   minimize the chance of misforwarding, a FEC that loses its incoming
   label to the tie-breaking tiebreaking rules specified in Section 2.5 MUST NOT be
   installed in FIB with an outgoing segment routing Segment Routing label based on the
   SID corresponding to the lost incoming label.

   Examples for the behavior specified in this section can be found in
   Appendix A.3.

2.7.  PUSH, CONTINUE, and NEXT

   PUSH, NEXT, and CONTINUE are operations applied by the forwarding
   plane.  The specifications of these operations can be found in
   [RFC8402].  This sub-section subsection specifies how to implement each of these
   operations in the MPLS forwarding plane.

2.7.1.  PUSH

   As described in [RFC8402], PUSH corresponds to pushing one or more
   labels on top of an incoming packet then sending it out of a
   particular physical interface or virtual interface, such as a UDP
   tunnel [RFC7510] or L2TPv3 tunnel the Layer 2 Tunneling Protocol version 3 (L2TPv3)
   [RFC4817], towards a particular next-hop.  When pushing labels onto a
   packet's label stack, the Time-
   to-Live Time-to-Live (TTL) field ([RFC3032], [RFC3443]) [RFC3032]
   [RFC3443] and the Traffic Class (TC) field ([RFC3032], [RFC5462]) [RFC3032] [RFC5462] of
   each label stack entry must, of course, be set.  This document does
   not specify any set of rules for setting these fields; that is a
   matter of local policy.  Sections 2.10 and 2.11 specify additional
   details about forwarding behavior.

2.7.2.  CONTINUE

   As described in [RFC8402], the CONTINUE operation corresponds to
   swapping the incoming label with an outgoing label.  The value of the
   outgoing label is calculated as specified in Sections 2.10 and 2.11.

2.7.3.  NEXT

   As described in [RFC8402], NEXT corresponds to popping the topmost
   label.  The action before and/or after the popping depends on the
   instruction associated with the active SID on the received packet
   prior to the popping.  For example example, suppose the active SID in the
   received packet was an Adj-SID [RFC8402], then [RFC8402]; on receiving the packet,
   the node applies the NEXT operation, which corresponds to popping the top most
   topmost label, and then sends the packet out of the physical or
   virtual interface (e.g. (e.g., the UDP tunnel [RFC7510] or L2TPv3 tunnel
   [RFC4817]) towards the next-hop corresponding to the adj-SID. Adj-SID.

2.7.3.1.  Mirror SID

   If the active SID in the received packet was a Mirror SID [RFC8402, (see
   [RFC8402], Section 5.1] 5.1) allocated by the receiving router, then the
   receiving router applies the NEXT operation, which corresponds to
   popping the top
   most topmost label, and then performs a lookup using the
   contents of the packet after popping the outer most outermost label in the
   mirrored forwarding table.  The method by which the lookup is made,
   and/or the actions applied to the packet after the lookup in the
   mirror table table, depends on the contents of the packet and the mirror
   table.  Note that the packet exposed after popping the top most topmost label
   may or may not be an MPLS packet.  A mirror Mirror SID can be viewed as a
   generalization of the context label in [RFC5331] because a mirror Mirror SID
   does not make any assumptions about the packet underneath the top
   label.

2.8.  MPLS Label Downloaded to the FIB for Global and Local SIDs

   The label corresponding to the global SID "Si" "Si", which is represented
   by the global index "I" and downloaded to FIB the FIB, is used to match
   packets whose active segment (and hence topmost label) is "Si".  The
   value of this label is calculated as specified in Section 2.4.

   For Local SIDs, the MCC is responsible for downloading the correct
   label value to the FIB.  For example, an IGP with SR extensions [I-D.ietf-
   isis-segment-routing-extensions, I-D.ietf-ospf-segment-routing-
   extensions]
   [RFC8667] [RFC8665] downloads the MPLS label corresponding to an Adj-SID Adj-
   SID [RFC8402].

2.9.  Active Segment

   When instantiated in the MPLS domain, the active segment on a packet
   corresponds to the topmost label on the packet that and is calculated according to the
   procedure specified in Sections 2.10 and 2.11.  When arriving at a
   node, the topmost label corresponding to the active SID matches the
   MPLS label downloaded to the FIB as specified in Section 2.4.

2.10.  Forwarding behavior Behavior for Global SIDs

   This section specifies the forwarding behavior, including the
   calculation of outgoing labels, that corresponds to a global SID when
   applying the PUSH, CONTINUE, and NEXT operations in the MPLS
   forwarding plane.

   This document covers the calculation of the outgoing label for the
   top label only.  The case where the outgoing label is not the top
   label and is part of a stack of labels that instantiates a routing
   policy or a traffic engineering traffic-engineering tunnel is outside the scope of this
   document and may be covered in other documents such as [I-D.ietf-
   spring-segment-routing-policy].
   [ROUTING-POLICY].

2.10.1.  Forwarding for PUSH and CONTINUE of Global SIDs

   Suppose an MCC on a router "R0" determines that that, before sending the
   packet towards a neighbor "N", the PUSH or CONTINUE operation is to
   be applied to an incoming packet related to the global SID "Si".  SID
   "Si" is represented by the global index "I" and owned by the router Ri before sending the packet towards a neighbor
   Ri.  Neighbor "N" may be directly connected to "R0" through either a
   physical or a virtual interface such as (e.g., UDP tunnel [RFC7510] or L2TPv3
   tunnel [RFC4817]. [RFC4817]).

   The method by which the MCC on router "R0" determines that the PUSH
   or CONTINUE operation must be applied using the SID "Si" is beyond
   the scope of this document.  An example of a method to determine the
   SID "Si" for the PUSH operation is the case where IS-IS [I-D.ietf-isis-
   segment-routing-extensions] [RFC8667]
   receives the prefix-SID "Si" sub-TLV advertised with the prefix "P/m"
   in TLV 135 135, and the destination address
   of the incoming IPv4 packet prefix "P/m" is covered by the longest matching network
   prefix "P/m". for the incoming IPv4 packet.

   For the CONTINUE operation, an example of a method used to determine
   the SID "Si" is the case where IS-IS [I-D.ietf-isis-segment-routing-
   extensions] [RFC8667] receives the prefix-SID prefix-
   SID "Si" sub-TLV advertised with prefix "P" in TLV 135 135, and the top
   label of the incoming packet matches the MPLS label in the FIB
   corresponding to the SID "Si" on the router "R0".

   The forwarding behavior for PUSH and CONTINUE corresponding to the
   SID "Si"

   o is as follows:

   *  If the neighbor "N" does not support SR or advertises an invalid SRGB
      or a SRGB that is too small for the SID "Si"

       o "Si", then:

      -  If it is possible to send the packet towards the neighbor "N" using
         standard MPLS forwarding behavior as specified in [RFC3031] and
         [RFC3032], then forward the packet.  The method by which a router
         decides whether it is possible to send the packet to "N" or not
         is beyond the scope of this document.  For example, the router
         "R0" can use the downstream label determined by another MCC,
         such as LDP [RFC5036], to send the packet.

       o Else

      -  Else, if there are other useable usable next-hops, then use other next-
         hops them to forward
         the incoming packet.  The method by which the router "R0"
         decides on the possibility of using other next-
         hops next-hops is beyond
         the scope of this document.  For example, the MCC on "R0" may
         chose the send an IPv4 packet without pushing any label to
         another next-hop.

       o Otherwise

      -  Otherwise, drop the packet.

   o  Else

      o

   *  Else,

      -  Calculate the outgoing label as specified in Section 2.4 using
         the SRGB of the neighbor "N" "N".

      -  Determine the outgoing label stack

         o  If the operation is PUSH

           . PUSH:

            +  Push the calculated label according to the MPLS label
               pushing rules specified in [RFC3032] [RFC3032].

         o Else

           .  Else,

            +  swap the incoming label with the calculated label
               according to the label swapping label-swapping rules in [RFC3032] [RFC3031].

         o  Send the packet towards the neighbor "N" "N".

2.10.2.  Forwarding for the NEXT Operation for Global SIDs

   As specified in Section 2.7.3 2.7.3, the NEXT operation corresponds to
   popping the top most topmost label.  The forwarding behavior is as follows

   o follows:

   *  Pop the topmost label

   o

   *  Apply the instruction associated with the incoming label that has
      been popped

   The action on the packet after popping the topmost label depends on
   the instruction associated with the incoming label as well as the
   contents of the packet right underneath the top label that got was
   popped.  Examples of the NEXT operation are described in Appendix A.1. A.1

2.11.  Forwarding Behavior for Local SIDs

   This section specifies the forwarding behavior for local SIDs when SR
   is instantiated over the MPLS forwarding plane.

2.11.1.  Forwarding for the PUSH Operation on Local SIDs

   Suppose an MCC on a router "R0" determines that the PUSH operation is
   to be applied to an incoming packet using the local SID "Si" before
   sending the packet towards a neighbor "N" "N", which is directly connected
   to R0 through a physical or virtual interface such as a UDP tunnel
   [RFC7510] or L2TPv3 tunnel [RFC4817].

   An example of such a local SID is an Adj-SID allocated and advertised
   by IS-IS [I-D.ietf-isis-segment-routing-extensions]. [RFC8667].  The method by which the MCC on "R0" determines
   that the PUSH operation is to be applied to the incoming packet is
   beyond the scope of this document.  An example of such a method is
   the backup path used to protect against a failure using TI-LFA [I-D.bashandy-rtgwg-segment-routing-ti-lfa].
   [FAST-REROUTE].

   As mentioned in [RFC8402], a local SID is specified by an MPLS label.
   Hence
   Hence, the PUSH operation for a local SID is identical to the label
   push operation [RFC3032] using any MPLS label. label [RFC3031].  The forwarding action
   after pushing the MPLS label corresponding to the local SID is also
   determined by the MCC.  For example, if the PUSH operation was done
   to forward a packet over a backup path calculated using TI-LFA, then
   the forwarding action may be sending the packet to a certain neighbor
   that will in turn continue to forward the packet along the backup
   path
   path.

2.11.2.  Forwarding for the CONTINUE Operation for Local SIDs

   A local SID on a router "R0" corresponds to a local label.  In such a
   scenario, the outgoing label towards a next-hop "N" is determined by
   the MCC running on the router "R0"and "R0", and the forwarding behavior for
   the CONTINUE operation is identical to the swap operation [RFC3032] on an MPLS label.
   label [RFC3031].

2.11.3.  Outgoing label Label for the NEXT Operation for Local SIDs

   The NEXT operation for Local SIDs is identical to the NEXT operation
   for global SIDs as specified in Section 2.10.2.

3.  IANA Considerations

   This document does not make any request to IANA. has no IANA actions.

4.  Manageability Considerations

   This document describes the applicability of Segment Routing over the
   MPLS data plane.  Segment Routing does not introduce any change in
   the MPLS data plane.  Manageability considerations described in
   [RFC8402] applies apply to the MPLS data plane when used with Segment
   Routing.  SR OAM Operations, Administration, and Maintenance (OAM) use
   cases for the MPLS data plane are defined in [RFC8403].  SR OAM
   procedures for the MPLS data plane are defined in [RFC8287].

5.  Security Considerations

   This document does not introduce additional security requirements and
   mechanisms other than the ones described in [RFC8402].

   This document was prepared using 2-Word-v2.0.template.dot.

8.

6.  References

8.1.

6.1.  Normative References

   [RFC8402] Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., and
             R. Shakir, "Segment Routing Architecture", RFC 8402, DOI
             10.17487/RFC8402 July 2018, <http://www.rfc-
             editor.org/info/rfc8402>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI
             0.17487/RFC2119, 10.17487/RFC2119, March 1997, <http://www.rfc-
             editor.org/info/rfc2119>.
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC3031]  Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
              Label Switching Architecture", RFC 3031,
              DOI 10.17487/RFC3031, January 2001, <http://www.rfc-
             editor.org/info/rfc3031>.
              <https://www.rfc-editor.org/info/rfc3031>.

   [RFC3032]  Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
              Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
              Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001,
             <http://www.rfc-editor.org/info/rfc3032>.
              <https://www.rfc-editor.org/info/rfc3032>.

   [RFC3443] P.  Agarwal, P. and Akyol, B. Akyol, "Time To Live (TTL) Processing
              in Multi-Protocol Label Switching (MPLS) Networks",
              RFC 3443, DOI 10.17487/RFC3443, January 2003, <http://www.rfc-
             editor.org/info/rfc3443>.
              <https://www.rfc-editor.org/info/rfc3443>.

   [RFC5462]  Andersson, L., L. and R. Asati, R., " Multiprotocol "Multiprotocol Label Switching
              (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic
              Class" Field", RFC 5462, DOI 10.17487/RFC5462, February
              2009, <http://www.rfc-editor.org/info/rfc5462>. <https://www.rfc-editor.org/info/rfc5462>.

   [RFC7274] K.  Kompella, L. K., Andersson, L., and A. Farrel, "Allocating
              and Retiring Special-Purpose MPLS Labels", RFC7274 RFC 7274,
              DOI 10.17487/RFC7274, May 2014 <http://www.rfc-
             editor.org/info/rfc7274> June 2014,
              <https://www.rfc-editor.org/info/rfc7274>.

   [RFC8174] B.  Leiba, " Ambiguity B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", RFC8174 BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017
             <http://www.rfc-editor.org/info/rfc8174>

8.2. Informative References

   [I-D.ietf-isis-segment-routing-extensions] Previdi, S., 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8402]  Filsfils, C.,
             Bashandy, A., Gredler, H., Litkowski, Ed., Previdi, S., Ed., Ginsberg, L.,
              Decraene, B., and
             j. jefftant@gmail.com, "IS-IS Extensions for Segment
             Routing", draft-ietf-isis-segment-routing-extensions-13
             (work in progress), June 2017.

   [I-D.ietf-ospf-ospfv3-segment-routing-extensions] Psenak, P.,
             Previdi, Litkowski, S., Filsfils, C., Gredler, H., Shakir, R.,
             Henderickx, W., and J. Tantsura, "OSPFv3 Extensions for
             Segment Routing", draft-ietf-ospf-ospfv3-segment-routing-
             extensions-09 (work in progress), March 2017.

   [I-D.ietf-ospf-segment-routing-extensions] Psenak, P., Previdi, S.,
             Filsfils, C., Gredler, H., R. Shakir, R., Henderickx, W., and
             J. Tantsura, "OSPF Extensions for Segment Routing", draft-
             ietf-ospf-segment-routing-extensions-16 (work in progress),
             May 2017.

   [I-D.ietf-spring-segment-routing-ldp-interop] Filsfils, C., Previdi,
             S., Bashandy, A., Decraene, B., and S. Litkowski, "Segment
              Routing interworking with LDP", draft-ietf-spring-segment-
             routing-ldp-interop-08 (work in progress), June 2017.

   [I-D.bashandy-rtgwg-segment-routing-ti-lfa], Architecture", RFC 8402, DOI 10.17487/RFC8402,
              July 2018, <https://www.rfc-editor.org/info/rfc8402>.

6.2.  Informative References

   [FAST-REROUTE]
              Litkowski, S., Bashandy, A., Filsfils, C., Decraene, B., Litkowski, S.,
              Francois, P., Voyer, P. daniel.voyer@bell.ca, d., Clad, F., and P.
              Camarillo, P., "Topology Independent Fast Reroute using
              Segment Routing", draft-bashandy-rtgwg-
             segment-routing-ti-lfa-05 (work Work in progress), October 2018,

   [RFC7855]  Previdi, S., Ed., Filsfils, Progress, Internet-Draft, draft-
              ietf-rtgwg-segment-routing-ti-lfa-01, 5 March 2019,
              <https://tools.ietf.org/html/draft-ietf-rtgwg-segment-
              routing-ti-lfa-01>.

   [RFC4817]  Townsley, M., Pignataro, C., Ed., Decraene, B.,
             Litkowski, Wainner, S., Horneffer, M., and R. Shakir, "Source Packet
             Routing in Networking (SPRING) Problem Statement Seely, T., and
             Requirements",
              J. Young, "Encapsulation of MPLS over Layer 2 Tunneling
              Protocol Version 3", RFC 7855, 4817, DOI 10.17487/RFC7855, May 2016,
             <http://www.rfc-editor.org/info/rfc7855>. 10.17487/RFC4817, March
              2007, <https://www.rfc-editor.org/info/rfc4817>.

   [RFC5036]  Andersson, L., Acreo, AB, Ed., Minei, I., Ed., and B. Thomas, B., " LDP Ed.,
              "LDP Specification", RFC5036, RFC 5036, DOI 10.17487/RFC5036,
              October 2007, <https://www.rfc-editor.org/info/rfc5036> <https://www.rfc-editor.org/info/rfc5036>.

   [RFC5331]  Aggarwal, R., Rekhter, Y., and E. Rosen, E., " MPLS "MPLS Upstream
              Label Assignment and Context-Specific Label Space", RFC5331
              RFC 5331, DOI 10.17487/RFC5331, August 2008, <http://www.rfc-
             editor.org/info/rfc5331>.
              <https://www.rfc-editor.org/info/rfc5331>.

   [RFC7510]  Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black,
              "Encapsulating MPLS in UDP", RFC 7510, DOI
             10.17487/RFC7510, April 2015, <https://www.rfc-
             editor.org/info/rfc7510>.

   [RFC4817] Townsley, M., Pignataro, C., Wainner, S., Seely, T., Young,
             T., "Encapsulation of MPLS over Layer 2 Tunneling Protocol
             Version 3", RFC4817, 7510,
              DOI 10.17487/RFC7510, April 2015,
              <https://www.rfc-editor.org/info/rfc7510>.

   [RFC7855]  Previdi, S., Ed., Filsfils, C., Ed., Decraene, B.,
              Litkowski, S., Horneffer, M., and R. Shakir, "Source
              Packet Routing in Networking (SPRING) Problem Statement
              and Requirements", RFC 7855, DOI 10.17487/RFC4817, March 2007,
             <https://www.rfc-editor.org/info/rfc4817> 10.17487/RFC7855, May
              2016, <https://www.rfc-editor.org/info/rfc7855>.

   [RFC8287] N.  Kumar, C. N., Ed., Pignataro, G. C., Ed., Swallow, N. G., Akiya, S.
              N., Kini, S., and M. Chen " Label Chen, "Label Switched Path (LSP)
              Ping/Traceroute for Segment Routing (SR) IGP-Prefix and
              IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data Planes" RFC8287,
              Planes", RFC 8287, DOI 10.17487/RFC8287, December 2017, https://www.rfc-
             editor.org/info/rfc8287
              <https://www.rfc-editor.org/info/rfc8287>.

   [RFC8403] R.  Geib, C. R., Ed., Filsfils, C. C., Pignataro, C., Ed., and N.
              Kumar, "A Scalable and Topology-Aware MPLS Data-Plane
              Monitoring System",
             RFC8403, RFC 8403, DOI 10.17487/RFC8403, July
              2018, <https://www.rfc-
             editor.org/info/rfc8403>

   [I-D.ietf-spring-segment-routing-policy] <https://www.rfc-editor.org/info/rfc8403>.

   [RFC8661]  Bashandy, A., Ed., Filsfils, C.,  Sivabalan, Ed., Previdi, S., Raza, K., Liste,
              Decraene, B., and S. Litkowski, "Segment Routing
              Interworking with LDP", RFC 8661, DOI 10.17487/RFC8661,
              September 2019, <https://www.rfc-editor.org/info/rfC8661>.

   [RFC8665]  Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler,
              H., Shakir, R., Henderickx, W., and J. , Clad, F., Voyer,  D., Bogdanov, A.,
   Mattes, Tantsura, "OSPF
              Extensions for Segment Routing", RFC 8665,
              DOI 10.17487/RFC8665, September 2019,
              <https://www.rfc-editor.org/info/rfc8665>.

   [RFC8666]  Psenak, P., " Ed. and S. Previdi, Ed., "OSPFv3 Extensions
              for Segment Routing", RFC 8666, DOI 10.17487/RFC8666,
              September 2019, <https://www.rfc-editor.org/info/rfc8666>.

   [RFC8667]  Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C.,
              Bashandy, A., Gredler, H., and B. Decraene, "IS-IS
              Extensions for Segment Routing", RFC 8667,
              DOI 10.17487/RFC8667, September 2019,
              <https://www.rfc-editor.org/info/rfc8667>.

   [ROUTING-POLICY]
              Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d.,
              bogdanov@google.com, b., and P. Mattes, "Segment Routing
              Policy for Traffic Engineering",
   draft-ietf-spring-segment-routing-policy-01 (work Architecture", Work in progress), June
   2018 Progress, Internet-Draft,
              draft-ietf-spring-segment-routing-policy-03, 12 May 2019,
              <https://tools.ietf.org/html/draft-ietf-spring-segment-
              routing-policy-03>.

Appendix A.  Examples

A.1.  IGP Segments Example Segment Examples

   Consider the network diagram of Figure 1 and the IP address addresses and IGP
   Segment allocation
   segment allocations of Figure 2.  Assume that the network is running
   IS-IS with SR extensions [I-D.ietf-isis-segment-routing-extensions] [RFC8667], and all links have the same
   metric.  The following examples can be constructed.

                                +--------+
                               /          \
                R0-----R1-----R2----------R3-----R8
                              | \        / |
                              |  +--R4--+  |
                              |            |
                              +-----R5-----+

                   Figure 1: IGP Segments - -- Illustration

          +-----------------------------------------------------------+
          | IP address addresses allocated by the operator:                   |
          |                      192.0.2.1/32 as a loopback of R1     |
          |                      192.0.2.2/32 as a loopback of R2     |
          |                      192.0.2.3/32 as a loopback of R3     |
          |                      192.0.2.4/32 as a loopback of R4     |
          |                      192.0.2.5/32 as a loopback of R5     |
          |                      192.0.2.8/32 as a loopback of R8     |
          |              198.51.100.9/32 as an anycast loopback of R4 |
          |              198.51.100.9/32 as an anycast loopback of R5 |
          |                                                           |
          | SRGB defined by the operator as 1000-5000 [1000,5000]               |
          |                                                           |
          | Global IGP SID indices allocated by the operator:         |
          |                      1 allocated to 192.0.2.1/32          |
          |                      2 allocated to 192.0.2.2/32          |
          |                      3 allocated to 192.0.2.3/32          |
          |                      4 allocated to 192.0.2.4/32          |
          |                      8 allocated to 192.0.2.8/32          |
          |                   1009 allocated to 198.51.100.9/32       |
          |                                                           |
          | Local IGP SID allocated dynamically by R2                 |
          |                     for its "north" adjacency to R3: 9001 |
          |                     for its "east" adjacency to R3 : 9002 |
          |                     for its "south" adjacency to R3: 9003 |
          |                     for its only adjacency to R4   : 9004 |
          |                     for its only adjacency to R1   : 9005 |
          +-----------------------------------------------------------+

        Figure 2: IGP Address and Segment Allocation - -- Illustration

   Suppose R1 wants to send an IPv4 packet P1 to R8.  In this case, R1
   needs to apply the PUSH operation to the IPv4 packet.

   Remember that the SID index "8" is a global IGP segment attached to
   the IP prefix 192.0.2.8/32.  Its semantic is global within the IGP
   domain: any router forwards a packet received with active segment 8
   to the next-hop along the ECMP-aware shortest-path shortest path to the related
   prefix.

   R2 is the next-hop along the shortest path towards R8.  By applying
   the steps in Section 2.8 2.8, the outgoing label downloaded to R1's FIB
   corresponding to the global SID index 8 "8" is 1008 because the SRGB of
   R2 is = [1000,5000] as shown in Figure 2.

   Because the packet is IPv4, R1 applies the PUSH operation using the
   label value 1008 as specified in Section 2.10.1.  The resulting MPLS
   header will have the "S" bit [RFC3032] set because it is followed
   directly by an IPv4 packet.

   The packet arrives at router R2.  Because the top label 1008 corresponds
   to the IGP SID index "8", which is the prefix-SID attached to the
   prefix 192.0.2.8/32 owned by the node R8, then the instruction associated with
   the SID is "forward the packet using all ECMP/UCMP one of the ECMP interfaces and all ECMP/UCMP next-hop(s) or
   next-hops along the shortest/useable shortest path(s) towards R8".  Because R2 is not
   the penultimate hop, R2 applies the CONTINUE operation to the packet
   and sends it to R3 using one of the two links connected to R3 with
   top label 1008 as specified in Section 2.10.1.

   R3 receives the packet with top label 1008.  Because the top label 1008
   corresponds to the IGP SID index "8", which is the prefix-SID
   attached to the prefix 192.0.2.8/32 owned by the node R8, then the instruction
   associated with the SID is "send the packet using all one of the ECMP
   interfaces and all next-hop(s) next-hops along the shortest path towards R8".
   Because R3 is the penultimate hop, we assume that R3 performs penumtimate
   penultimate hop popping, which corresponds to the NEXT operation, then sends operation; the
   packet is then sent to R8.  The NEXT operation results in popping the
   outer label and sending the packet as a pure IPv4 packet to R8.

   In conclusion, the path followed by P1 is R1-R2--R3-R8.  The ECMP- ECMP
   awareness ensures that the traffic be is load-shared between any ECMP
   path,
   path; in this case case, it's the two links between R2 and R3.

A.2.  Incoming Label Collision Examples

   This section describes few outlines several examples to illustrate the handling of
   label collision described in Section 2.5.

   For the examples in this section, we assume that Node node A has the
   following:

   o

   *  OSPF default admin distance for implementation=50

   o  ISIS

   *  IS-IS default admin distance for implementation=60

A.2.1.  Example 1

   Illustration of

   The following example illustrates incoming label collision resolution
   for the same FEC type using MCC administrative distance.

   FEC1:
   o

   Node A receives an OSPF prefix Prefix SID advertisement from node B for
   198.51.100.5/32 with
      index=5

   o index=5.  Assuming that OSPF SRGB on node A = [1000,1999]

   o  Incoming label=1005
   [1000,1999], the incoming label is 1005.

   FEC2:
   o  ISIS prefix

   IS-IS on node A receives a Prefix SID advertisement from node C for
   203.0.113.105/32 with index=5

   o  ISIS index=5.  Assuming that IS-IS SRGB on node A = [1000,1999]

   o  Incoming label=1005 A =
   [1000,1999], the incoming label is 1005.

   FEC1 and FEC2 both use dynamic SID assignment.  Since neither ofthe
   FEC types is SR Policy, of the
   FECs are of type 'SR Policy', we use the default admin distances of
   50 and 60 to break the tie.  So FEC1 wins.

A.2.2.  Example 2

   Illustration of

   The following example Illustrates incoming label collision resolution
   for different FEC types using the MCC administrative distance.

   FEC1:
   o

   Node A receives an OSPF prefix sid Prefix SID advertisement from node B for
   198.51.100.6/32 with index=6

   o index=6.  Assuming that OSPF SRGB on node A = [1000,1999]

   o  Hence
   [1000,1999], the incoming label on node A corresponding to
   198.51.100.6/32 is 1006 1006.

   FEC2:
   ISIS

   IS-IS on node A assigns the label 1006 to the globally significant
   adj-SID (I.e. Adj-
   SID (i.e., when advertised advertised, the "L" flag is clear in the adj-SID
   sub-TLV Adj-SID sub-
   TLV as described in [I-D.ietf-isis-segment-routing-extensions])
   towards one of its neighbors. Hence [RFC8667]).  Hence, the incoming label
   corresponding to this adj-SID Adj-SID is 1006.  Assume Node node A allocates this adj-SID
   Adj-SID dynamically, and it may differ across router reboots.

   FEC1 and FEC2 both use dynamic SID assignment.  Since neither of the
   FEC types is SR Policy,
   FECs are of type 'SR Policy', we use the default admin distances of
   50 and 60 to break the tie.  So FEC1 wins.

A.2.3.  Example 3

   Illustration of

   The following example illustrates incoming label collision resolution
   based on preferring static over dynamic SID assignment assignment.

   FEC1:

   OSPF on node A receives a prefix Prefix SID advertisement from node B for
   198.51.100.7/32 with index=7.  Assuming that the OSPF SRGB on node A
   is
   = [1000,1999], then the incoming label corresponding to 198.51.100.7/32 is 1007
   1007.

   FEC2:

   The operator on node A configures ISIS IS-IS on node A to assign the label
   1007 to the globally significant adj-SID (I.e. Adj-SID (i.e., when advertised advertised, the
   "L" flag is clear in the adj-SID Adj-SID sub-TLV as described in [I-D.ietf-
   isis-segment-routing-extensions]) towards one of its neighbor
   advertisement from node A with label=1007 [RFC8667]).

   Node A assigns this adj-SID Adj-SID explicitly via configuration, so the adj-
   SID
   Adj-SID survives router reboots.

   FEC1 uses dynamic SID assignment, while FEC2 uses explicit SID
   assignment.  So FEC2 wins.

A.2.4.  Example 4

   Illustration of

   The following example illustrates incoming label collision resolution
   using FEC type default administrative distance distance.

   FEC1:

   OSPF on node A receives a prefix Prefix SID advertisement from node B for
   198.51.100.8/32 with index=8.  Assuming that OSPF SRGB on node A =
   [1000,1999], the incoming label corresponding to 198.51.100.8/32 is
   1008.

   FEC2:

   Suppose the SR Policy advertisement from the controller to node A for
   the policy identified by (Endpoint = 192.0.2.208, color = 100) and
   consisting that
   consists of SID-List = <S1, SID-List=<S1, S2> assigns the globally significant
   Binding-SID label 1008 1008.

   From the point of view of node A, FEC1 and FEC2 both use dynamic SID
   assignment.  Based on the default administrative distance outlined in
   Section 2.5.1, the binding Binding SID has a higher administrative distance
   than the prefix-SID and hence prefix-SID; hence, FEC1 wins.

A.2.5.  Example 5

   Illustration of

   The following example illustrates incoming label collision resolution
   based on FEC type
   preference preference.

   FEC1:
   ISIS

   IS-IS on node A receives a prefix Prefix SID advertisement from node B for
   203.0.113.110/32 with index=10.  Assuming that the ISIS IS-IS SRGB on node
   A
   is = [1000,1999], then the incoming label corresponding to 203.0.113.110/32
   is 1010.

   FEC2:
   ISIS

   IS-IS on node A assigns the label 1010 to the globally significant
   adj-SID (I.e. Adj-
   SID (i.e., when advertised advertised, the "L" flag is clear in the adj-SID
   sub-TLV Adj-SID sub-
   TLV as described in [I-D.ietf-isis-segment-routing-extensions])
   towards one of its neighbors). [RFC8667]).

   Node A allocates this adj-SID Adj-SID dynamically, and it may differ across
   router reboots. Hence  Hence, both FEC1 and FEC2 both use dynamic SID
   assignment.

   Since both FECs are from the same MCC, they have the same default
   admin distance.  So we compare the FEC type code-point. code points.  FEC1 has
   FEC type code-point=120, while FEC2 has FEC type code-point=130.
   Therefore, FEC1 wins.

A.2.6.  Example 6

   Illustration of

   The following example illustrates incoming label collision resolution
   based on address family preference.

   FEC1:
   ISIS

   IS-IS on node A receives prefix a Prefix SID advertisement from node B for
   203.0.113.111/32 with index 11. index=11.  Assuming that the ISIS IS-IS SRGB on node
   A
   is = [1000,1999], the incoming label on node A for 203.0.113.111/32 is
   1011.

   FEC2:
   ISIS

   IS-IS on node A prefix receives a Prefix SID advertisement from node C for
   2001:DB8:1000::11/128 with index=11.  Assuming that the ISIS IS-IS SRGB on
   node A is = [1000,1999], the incoming label on node A for
   2001:DB8:1000::11/128 is 1011 1011.

   FEC1 and FEC2 both use dynamic SID assignment.  Since both FECs are
   from the same MCC, they have the same default admin distance.  So we
   compare the FEC type code-point. code points.  Both FECs have FEC type
   code-point=120.  So we compare the address family.  Since IPv4 is
   preferred over IPv6, FEC1 wins.

A.2.7.  Example 7

   Illustration

   The following example illustrates incoming label collision resolution
   based on prefix length.

   FEC1:
   ISIS

   IS-IS on node A receives a prefix Prefix SID advertisement from node B for
   203.0.113.112/32 with index 12. index=12.  Assuming that ISIS IS-IS SRGB on node A is =
   [1000,1999], the incoming label for 203.0.113.112/32 on node A is
   1012.

   FEC2:
   ISIS

   IS-IS on node A receives a prefix Prefix SID advertisement from node C for
   203.0.113.128/30 with index 12. index=12.  Assuming that the ISIS IS-IS SRGB on node
   A
   is = [1000,1999], then the incoming label for 203.0.113.128/30 on node A is
   1012
   1012.

   FEC1 and FEC2 both use dynamic SID assignment.  Since both FECs are
   from the same MCC, they have the same default admin distance.  So we
   compare the FEC type code-point. code points.  Both FECs have FEC type
   code-point=120.  So we compare the address family.  Both are a part
   of the IPv4 address family, so we compare the prefix length.  FEC1
   has prefix length=32, and FEC2 has prefix length=30, so FEC2 wins.

A.2.8.  Example 8

   Illustration of

   The following example illustrates incoming label collision resolution
   based on the numerical value of the FECs.

   FEC1:
   ISIS

   IS-IS on node A receives a prefix Prefix SID advertisement from node B for
   203.0.113.113/32 with index 13. index=13.  Assuming that ISIS IS-IS SRGB on node A is =
   [1000,1999], then the incoming label for 203.0.113.113/32 on node A is 1013
   1013.

   FEC2:
   ISIS

   IS-IS on node A receives a prefix Prefix SID advertisement from node C for
   203.0.113.213/32 with index 13. index=13.  Assuming that ISIS IS-IS SRGB on node A is =
   [1000,1999], then the incoming label for 203.0.113.213/32 on node A is 1013
   1013.

   FEC1 and FEC2 both use dynamic SID assignment.  Since both FECs are
   from the same MCC, they have the same default admin distance.  So we
   compare the FEC type code-point. code points.  Both FECs have FEC type
   code-point=120.  So we compare the address family.  Both are a part
   of the IPv4 address family, so we compare the prefix length.  Prefix
   lengths are the same, so we compare the prefix.  FEC1 has the lower
   prefix, so FEC1 wins.

A.2.9.  Example 9

   Illustration of

   The following example illustrates incoming label collision resolution
   based on routing
   instance the Routing Instance ID.

   FEC1:
   ISIS

   IS-IS on node A receives a prefix Prefix SID advertisement from node B for
   203.0.113.114/32 with index 14. index=14.  Assume that this ISIS IS-IS instance on
   node A has the Routing Instance ID = 1000 and SRGB = [1000,1999]. Hence  Hence,
   the incoming label for 203.0.113.114/32 on node A is 1014 1014.

   FEC2:
   ISIS

   IS-IS on node A receives a prefix Prefix SID advertisement from node C for
   203.0.113.114/32 with index=14.  Assume that this is another instance
   of ISIS IS-IS on node A with a different routing but Routing Instance ID = 2000 but the
   same is different and
   SRGB [1000,1999]. Hence = [1000,1999] is the same.  Hence, the incoming label for
   203.0.113.114/32 on node A 1014 is 1014.

   These two FECs match all the way through the prefix length and
   prefix.  So the Routing Instance ID breaks the tie, with and FEC1 winning. wins.

A.2.10.  Example 10

   Illustration of

   The following example illustrates incoming label collision resolution
   based on the topology ID.

   FEC1:
   ISIS

   IS-IS on node A receives a prefix Prefix SID advertisement from node B for
   203.0.113.115/32 with index=15.  Assume that this ISIS IS-IS instance on
   node A has Routing Instance ID = 1000.  Assume that the prefix
   advertisement of 203.0.113.115/32 was received in ISIS Multi-topology the IS-IS Multi-
   topology advertisement with ID = 50.  If the ISIS IS-IS SRGB for this
   routing instance on node A is = [1000,1999], then the incoming label of
   203.0.113.115/32 for topology 50 on node A is 1015 1015.

   FEC2:
   ISIS

   IS-IS on node A receives a prefix Prefix SID advertisement from node C for
   203.0.113.115/32 with index 15. index=15.  Assume that it is has the same routing Routing
   Instance ID = 1000 1000, but 203.0.113.115/32 was advertised with a
   different ISIS IS-IS
   Multi-topology ID = 40. 40, which is different.  If the ISIS IS-IS SRGB on
   node A is = [1000,1999], then the incoming label of 203.0.113.115/32 for
   topology 40 on node A is also 1015

   These 1015.

   Since these two FECs match all the way through the prefix length,
   prefix, and Routing Instance ID.  We ID, we compare ISIS the IS-IS Multi-topology
   ID, so FEC2 wins.

A.2.11.  Example 11

   Illustration of

   The following example illustrates incoming label collision for
   resolution based on the algorithm ID.

   FEC1:
   ISIS

   IS-IS on node A receives a prefix Prefix SID advertisement from node B for
   203.0.113.116/32 with index=16 index=16.  Assume that ISIS IS-IS on node A has
   Routing Instance ID = 1000.  Assume that node B advertised
   203.0.113.116/32 with ISIS IS-IS Multi-topology ID = 50 and SR algorithm =
   0.  Assume that the ISIS IS-IS SRGB on node A = [1000,1999]. Hence  Hence, the
   incoming label corresponding to this advertisement of
   203.0.113.116/32 is 1016.

   FEC2:
   ISIS

   IS-IS on node A receives a prefix Prefix SID advertisement from node C for
   203.0.113.116/32 with index=16.  Assume that it is the same ISIS IS-IS
   instance on node A with Routing Instance ID = 1000.  Also assume that
   node C advertised 203.0.113.116/32 with ISIS IS-IS Multi-topology ID = 50
   but with SR algorithm = 22.  Since it is the same routing instance,
   the SRGB on node A = [1000,1999]. Hence  Hence, the incoming label
   corresponding to this advertisement of 203.0.113.116/32 by node C is
   also 1016.

   These

   Since these two FECs match all the way through in terms of the prefix
   length, prefix,
   and Routing Instance ID, and Multi-topology ID. We ID, we
   compare the SR algorithm ID, IDs, so FEC1 wins.

A.2.12.  Example 12

   Illustration of

   The following example illustrates incoming label collision resolution
   based on the FEC numerical value and value, independent of how the SID is
   assigned to the colliding FECs.

   FEC1:
   ISIS

   IS-IS on node A receives a prefix Prefix SID advertisement from node B for
   203.0.113.117/32 with index 17. index=17.  Assume that the ISIS IS-IS SRGB on node A
   is [1000,1999], then
   = [1000,1999]; thus, the incoming label is 1017 1017.

   FEC2:

   Suppose there is an ISIS IS-IS mapping server advertisement (SID/Label (SID / Label
   Binding TLV) from node D that has Range range = 100 and Prefix prefix =
   203.0.113.1/32.  Suppose this mapping server advertisement generates
   100 mappings, one of which maps 203.0.113.17/32 to index 17. index=17.
   Assuming that it is the same ISIS IS-IS instance, then the SRGB is = [1000,1999]
   and hence the incoming label for 1017.

   The fact that

   Even though FEC1 comes from a normal prefix Prefix SID advertisement and
   FEC2 is generated from a mapping server advertisement advertisement, it is not used
   as a tie-breaking tiebreaking parameter.  Both FECs use dynamic SID assignment,
   are from the same MCC, and have the same FEC type code-point=120.
   Their prefix lengths are the same as well.  FEC2 wins based on its
   lower numerical prefix value, since 203.0.113.17 is less than
   203.0.113.117.

A.2.13.  Example 13

   Illustration of

   The following example illustrates incoming label collision resolution
   based on address family preference preference.

   FEC1:

   SR Policy advertisement from the controller to node A.  Endpoint
   address=2001:DB8:3000::100, color=100, SID-List=<S1, S2> S2>, and the
   Binding-SID label=1020 label=1020.

   FEC2:

   SR Policy advertisement from controller to node A.  Endpoint
   address=192.0.2.60, color=100, SID-List=<S3, S4> S4>, and the Binding-SID
   label=1020
   label=1020.

   The FECs match through the tie-breaks up to FEC tiebreakers match, and including having they have the same FEC type code-point=140. code-
   point=140.  Thus, FEC2 wins based on the IPv4 address family being
   preferred over IPv6.

A.2.14.  Example 14

   Illustration of

   The following example illustrates incoming label resolution based on
   the numerical value of the policy endpoint.

   FEC1:

   SR Policy advertisement from the controller to node A.  Endpoint
   address=192.0.2.70, color=100, SID-List=<S1, S2> S2>, and Binding-SID
   label=1021
   label=1021.

   FEC2:

   SR Policy advertisement from the controller to node A A.  Endpoint
   address=192.0.2.71, color=100, SID-List=<S3, S4> S4>, and Binding-SID
   label=1021
   label=1021.

   The FECs match through the tie-breaks up to FEC tiebreakers match, and including having they have the same address family.
   Thus, FEC1 wins by having the lower numerical endpoint address value.

A.3.  Examples for the Effect of Incoming Label Collision on an Outgoing
      Label

   This section presents examples to illustrate the effect of incoming
   label collision on the selection of the outgoing label as described
   in Section 2.6.

A.3.1.  Example 1

   Illustration of

   The following example illustrates the effect of incoming label
   resolution on the outgoing label label.

   FEC1:
   ISIS

   IS-IS on node A receives a prefix Prefix SID advertisement from node B for
   203.0.113.122/32 with index 22. index=22.  Assuming that the ISIS IS-IS SRGB on node
   A
   is [1000,1999] = [1000,1999], the corresponding incoming label is 1022.

   FEC2:
   ISIS

   IS-IS on node A receives a prefix Prefix SID advertisement from node C for
   203.0.113.222/32 with index=22 index=22.  Assuming that the ISIS IS-IS SRGB on node
   A
   is [1000,1999] = [1000,1999], the corresponding incoming label is 1022.

   FEC1 wins based on the lowest numerical prefix value.  This means
   that node A installs a transit MPLS forwarding entry to SWAP swap incoming
   label 1022, 1022 with outgoing label N and to use outgoing interface I.  N
   is determined by the index associated with FEC1 (index 22) (index=22) and the
   SRGB advertised by the next-hop node on the shortest path to reach
   203.0.113.122/32.

   Node A will generally also install an imposition MPLS forwarding
   entry corresponding to FEC1 for incoming prefix=203.0.113.122/32
   pushing outgoing label N, and using outgoing interface I.

   The rule in Section 2.6 means node A MUST NOT install an ingress MPLS
   forwarding entry corresponding to FEC2 (the losing FEC, which would
   be for prefix 203.0.113.222/32).

A.3.2.  Example 2

   Illustration of

   The following example illustrates the effect of incoming label
   collision resolution on outgoing label programming on node A A.

   FEC1:
   o

   SR Policy advertisement from the controller to node A

   o A.  Endpoint
   address=192.0.2.80, color=100, SID-List=<S1, S2>

   o S2>, and Binding-SID label=1023
   label=1023.

   FEC2:
   o

   SR Policy advertisement from controller to node A

   o A.  Endpoint
   address=192.0.2.81, color=100, SID-List=<S3, S4>

   o S4>, and Binding-SID label=1023
   label=1023.

   FEC1 wins by having the lower numerical endpoint address value.  This
   means that node A installs a transit MPLS forwarding entry to SWAP swap
   incoming label=1023, label=1023 with outgoing labels labels, and the outgoing interface
   is determined by the SID-List for FEC1.

   In this example, we assume that node A receives two BGP/VPN routes:

   o

   *  R1 with VPN label=V1, BGP next-hop = 192.0.2.80, and color=100,

   o color=100

   *  R2 with VPN label=V2, BGP next-hop = 192.0.2.81, and color=100, color=100

   We also assume that node A has a BGP policy which that matches on color=100
   that
   and allows that its usage as SLA Service Level Agreement (SLA) steering
   information.  In this case, node A will install a VPN route with
   label stack = <S1,S2,V1> (corresponding to FEC1).

   The rule described in section Section 2.6 means that node A MUST NOT install
   a VPN route with label stack = <S3,S4,V1> (corresponding to FEC2.)

7.

Acknowledgements

   The authors would like to thank Les Ginsberg, Chris Bowers, Himanshu
   Shah, Adrian Farrel, Alexander Vainshtein, Przemyslaw Krol, Darren
   Dukes, Zafar Ali, and Martin Vigoureux for their valuable comments on
   this document.

6.

Contributors

   The following contributors have substantially helped the definition
   and editing of the content of this document:

   Martin Horneffer
   Deutsche Telekom
   Email: Martin.Horneffer@telekom.de

   Wim Henderickx
   Nokia
   Email: wim.henderickx@nokia.com

   Jeff Tantsura
   Email: jefftant@gmail.com

   Edward Crabbe
   Email: edward.crabbe@gmail.com

   Igor Milojevic
   Email: milojevicigor@gmail.com

   Saku Ytti
   Email: saku@ytti.fi

9.

Authors' Addresses

   Ahmed Bashandy (editor)
   Arrcus

   Email: abashandy.ietf@gmail.com

   Clarence Filsfils (editor)
   Cisco Systems, Inc.
   Brussels
     BE
   Belgium

   Email: cfilsfil@cisco.com

   Stefano Previdi
   Cisco Systems, Inc.
   Italy

   Email: stefano@previdi.net

   Bruno Decraene
   Orange
     FR
   France

   Email: bruno.decraene@orange.com

   Stephane Litkowski
   Orange
     FR
   France

   Email: stephane.litkowski@orange.com

   Rob Shakir
   Google
     US
   United States of America

   Email: robjs@google.com