Skip to main content

Segment Routing interworking with LDP
draft-ietf-spring-segment-routing-ldp-interop-08

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 8661.
Authors Clarence Filsfils , Stefano Previdi , Ahmed Bashandy , Bruno Decraene , Stephane Litkowski
Last updated 2017-07-12 (Latest revision 2017-06-15)
Replaces draft-filsfils-spring-segment-routing-ldp-interop
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state Submitted to IESG for Publication
Document shepherd Martin Vigoureux
Shepherd write-up Show Last changed 2017-07-12
IESG IESG state Became RFC 8661 (Proposed Standard)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD Alvaro Retana
Send notices to (None)
draft-ietf-spring-segment-routing-ldp-interop-08
Network Working Group                                   C. Filsfils, Ed.
Internet-Draft                                           S. Previdi, Ed.
Intended status: Standards Track                             A. Bashandy
Expires: December 17, 2017                           Cisco Systems, Inc.
                                                             B. Decraene
                                                            S. Litkowski
                                                                  Orange
                                                           June 15, 2017

                 Segment Routing interworking with LDP
            draft-ietf-spring-segment-routing-ldp-interop-08

Abstract

   A Segment Routing (SR) node steers a packet through a controlled set
   of instructions, called segments, by prepending the packet with an SR
   header.  A segment can represent any instruction, topological or
   service-based.  SR allows to enforce a flow through any topological
   path and service chain while maintaining per-flow state only at the
   ingress node to the SR domain.

   The Segment Routing architecture can be directly applied to the MPLS
   data plane with no change in the forwarding plane.  This drafts
   describes how Segment Routing operates in a network where LDP is
   deployed and in the case where SR-capable and non-SR-capable nodes
   coexist.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

Status of This Memo

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

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

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

Filsfils, et al.        Expires December 17, 2017               [Page 1]
Internet-Draft           Segment Routing and LDP               June 2017

   This Internet-Draft will expire on December 17, 2017.

Copyright Notice

   Copyright (c) 2017 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) 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
   2.  SR/LDP Ship-in-the-night coexistence  . . . . . . . . . . . .   3
     2.1.  MPLS2MPLS co-existence  . . . . . . . . . . . . . . . . .   5
     2.2.  IP2MPLS co-existence  . . . . . . . . . . . . . . . . . .   6
   3.  Migration from LDP to SR  . . . . . . . . . . . . . . . . . .   6
   4.  SR and LDP Interworking . . . . . . . . . . . . . . . . . . .   7
     4.1.  LDP to SR . . . . . . . . . . . . . . . . . . . . . . . .   8
       4.1.1.  LDP to SR Behavior  . . . . . . . . . . . . . . . . .   8
     4.2.  SR to LDP . . . . . . . . . . . . . . . . . . . . . . . .   8
       4.2.1.  SR to LDP Behavior  . . . . . . . . . . . . . . . . .  10
   5.  SR/LDP Interworking Use Cases . . . . . . . . . . . . . . . .  11
     5.1.  SR Protection of LDP-based Traffic  . . . . . . . . . . .  11
     5.2.  Eliminating Targeted LDP Session  . . . . . . . . . . . .  13
     5.3.  Guaranteed FRR coverage . . . . . . . . . . . . . . . . .  14
     5.4.  Inter-AS Option C, Carrier's Carrier  . . . . . . . . . .  15
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  16
   7.  Manageability Considerations  . . . . . . . . . . . . . . . .  16
     7.1.  SR and LDP co-existence . . . . . . . . . . . . . . . . .  16
     7.2.  SRMS Management . . . . . . . . . . . . . . . . . . . . .  16
     7.3.  Dataplane Verification  . . . . . . . . . . . . . . . . .  17
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  17
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  17
   10. Contributors' Addresses . . . . . . . . . . . . . . . . . . .  17
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  18
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  18
     11.2.  Informative References . . . . . . . . . . . . . . . . .  19
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  19

Filsfils, et al.        Expires December 17, 2017               [Page 2]
Internet-Draft           Segment Routing and LDP               June 2017

1.  Introduction

   Segment Routing, as described in [I-D.ietf-spring-segment-routing],
   can be used on top of the MPLS data plane without any modification as
   described in [I-D.ietf-spring-segment-routing-mpls].

   Segment Routing control plane can co-exist with current label
   distribution protocols such as LDP ([RFC5036]).

   This draft outlines the mechanisms through which SR interworks with
   LDP in cases where a mix of SR-capable and non-SR-capable routers co-
   exist within the same network and more precisely in the same routing
   domain.

   Section 2 describes the co-existence of SR with other MPLS Control
   Plane.  Section 3 documents a method to migrate from LDP to SR-based
   MPLS tunneling.  Section 4 documents the interworking between SR and
   LDP in the case of non-homogeneous deployment.  Section 5 describes
   how a partial SR deployment can be used to provide SR benefits to
   LDP-based traffic including a possible application of SR in the
   context of inter-domain MPLS use-cases.

   Typically, an implementation will allow an operator to select
   (through configuration) which of the described modes of SR and LDP
   co-existence to use.

2.  SR/LDP Ship-in-the-night coexistence

   We call "MPLS Control Plane Client (MCC)" any control plane protocol
   installing forwarding entries in the MPLS data plane.  SR, LDP, RSVP-
   TE, BGP 3107, VPNv4, etc are examples of MCCs.

   An MCC, operating at node N, MUST ensure that the incoming label it
   installs in the MPLS data plane of Node N has been uniquely allocated
   to himself.

   Segment Routing makes use of the Segment Routing Global Block (SRGB,
   as defined in [I-D.ietf-spring-segment-routing]) for the label
   allocation.  The use of the SRGB allows SR to co-exist with any other
   MCC.

   This is clearly the case for the adjacency segment: it is a local
   label allocated by the label manager, as for any MCC.

   This is clearly the case for the prefix segment: the label manager
   allocates the SRGB set of labels to the SR MCC client and the
   operator ensures the unique allocation of each global prefix segment/
   label within the allocated SRGB set.

Filsfils, et al.        Expires December 17, 2017               [Page 3]
Internet-Draft           Segment Routing and LDP               June 2017

   Note that this static label allocation capability of the label
   manager exists for many years across several vendors and hence is not
   new.  Furthermore, note that the label-manager ability to statically
   allocate a range of labels to a specific application is not new
   either.  This is required for MPLS-TP operation.  In this case, the
   range is reserved by the label manager and it is the MPLS-TP
   ([RFC5960]) NMS (acting as an MCC) that ensures the unique allocation
   of any label within the allocated range and the creation of the
   related MPLS forwarding entry.

   Let us illustrate an example of ship-in-the-night (SIN) coexistence.

                              PE2          PE4
                                \          /
                          PE1----A----B---C---PE3

                         Figure 1: SIN coexistence

   The EVEN VPN service is supported by PE2 and PE4 while the ODD VPN
   service is supported by PE1 and PE3.  The operator wants to tunnel
   the ODD service via LDP and the EVEN service via SR.

   This can be achieved in the following manner:

      The operator configures PE1, PE2, PE3, PE4 with respective
      loopbacks 192.0.2.201/32, 192.0.2.202/32, 192.0.2.203/32,
      192.0.2.204/32.  These PE's advertised their VPN routes with next-
      hop set on their respective loopback address.

      The operator configures A, B, C with respective loopbacks
      192.0.2.1/32, 192.0.2.2/32, 192.0.2.3/32.

      The operator configures PE2, A, B, C and PE4 with SRGB [100, 300].

      The operator attaches the respective Node Segment Identifiers
      (Node-SID's, as defined in [I-D.ietf-spring-segment-routing]):
      202, 101, 102, 103 and 204 to the loopbacks of nodes PE2, A, B, C
      and PE4.  The Node-SID's are configured to request penultimate-
      hop-popping.

      PE1, A, B, C and PE3 are LDP capable.

      PE1 and PE3 are not SR capable.

   PE3 sends an ODD VPN route to PE1 with next-hop 192.0.2.203 and VPN
   label 10001.

Filsfils, et al.        Expires December 17, 2017               [Page 4]
Internet-Draft           Segment Routing and LDP               June 2017

   From an LDP viewpoint: PE1 received an LDP label binding (1037) for
   FEC 192.0.2.203/32 from its next-hop A.  A received an LDP label
   binding (2048) for that FEC from its next-hop B.  B received an LDP
   label binding (3059) for that FEC from its next-hop C.  C received
   implicit-null LDP binding from its next-hop PE3.

   As a result, PE1 sends its traffic to the ODD service route
   advertised by PE3 to next-hop A with two labels: the top label is
   1037 and the bottom label is 10001.  Node A swaps 1037 with 2048 and
   forwards to B.  B swaps 2048 with 3059 and forwards to C.  C pops
   3059 and forwards to PE3.

   PE4 sends an EVEN VPN route to PE2 with next-hop 192.0.2.204 and VPN
   label 10002.

   From an SR viewpoint: PE2 maps the IGP route 192.0.2.204/32 onto
   Node-SID 204; node A swaps 204 with 204 and forwards to B; B swaps
   204 with 204 and forwards to C; C pops 204 and forwards to PE4.

   As a result, PE2 sends its traffic to the VPN service route
   advertised by PE4 to next-hop A with two labels: the top label is 204
   and the bottom label is 10002.  Node A swaps 204 with 204 and
   forwards to B.  B swaps 204 with 204 and forwards to C.  C pops 204
   and forwards to PE4.

   The two modes of MPLS tunneling co-exist.

      The ODD service is tunneled from PE1 to PE3 through a continuous
      LDP LSP traversing A, B and C.

      The EVEN service is tunneled from PE2 to PE4 through a continuous
      SR node segment traversing A, B and C.

2.1.  MPLS2MPLS co-existence

   We want to highlight that several MPLS2MPLS entries can be installed
   in the data plane for the same prefix.

   Let us examine A's MPLS forwarding table as an example:

      Incoming label: 1037

          - outgoing label: 2048
          - outgoing next-hop: B
          Note: this entry is programmed by LDP for 192.0.2.203/32

      Incoming label: 203

Filsfils, et al.        Expires December 17, 2017               [Page 5]
Internet-Draft           Segment Routing and LDP               June 2017

          - outgoing label: 203
          - outgoing next-hop: B
          Note: this entry is programmed by SR for 192.0.2.203/32

   These two entries can co-exist because their incoming label is
   unique.  The uniqueness is guaranteed by the label manager allocation
   rules.

   The same applies for the MPLS2IP forwarding entries.

2.2.  IP2MPLS co-existence

   By default, if both LDP and SR propose an IP to MPLS entry (IP2MPLS)
   for the same IP prefix, then the LDP route SHOULD be selected.

   A local policy on a router MUST allow to prefer the SR-provided
   IP2MPLS entry.

   Note that this policy MAY be locally defined.  There is no
   requirement that all routers use the same policy.

3.  Migration from LDP to SR

                               PE2        PE4
                                 \        /
                          PE1----P5--P6--P7---PE3

                            Figure 2: Migration

   Several migration techniques are possible.  We describe one technique
   inspired by the commonly used method to migrate from one IGP to
   another.

   At time T0, all the routers run LDP.  Any service is tunneled from an
   ingress PE to an egress PE over a continuous LDP LSP.

   At time T1, all the routers are upgraded to SR.  They are configured
   with the SRGB range [100, 300].  PE1, PE2, PE3, PE4, P5, P6 and P7
   are respectively configured with the node segments 101, 102, 103,
   104, 105, 106 and 107 (attached to their service-recursing loopback).

      At this time, the service traffic is still tunneled over LDP LSP.
      For example, PE1 has an SR node segment to PE3 and an LDP LSP to
      PE3 but by default, as seen earlier, the LDP IP2MPLS encapsulation
      is preferred.  However, it has to be noted that the SR
      infrastructure is usable, e.g. for Fast Reroute (FRR) or IGP Loop
      Free Convergence to protect existing IP and LDP traffic.  FRR

Filsfils, et al.        Expires December 17, 2017               [Page 6]
Internet-Draft           Segment Routing and LDP               June 2017

      mechanisms are described in
      [I-D.bashandy-rtgwg-segment-routing-ti-lfa].

   At time T2, the operator enables the local policy at PE1 to prefer SR
   IP2MPLS encapsulation over LDP IP2MPLS.

      The service from PE1 to any other PE is now riding over SR.  All
      other service traffic is still transported over LDP LSP.

   At time T3, gradually, the operator enables the preference for SR
   IP2MPLS encapsulation across all the edge routers.

      All the service traffic is now transported over SR.  LDP is still
      operational and services could be reverted to LDP.

      However, any traffic switched through LDP entries will still
      suffer from LDP-IGP synchronization.

   At time T4, LDP is unconfigured from all routers.

4.  SR and LDP Interworking

   In this section, we analyze the case where SR is available in one
   part of the network and LDP is available in another part.  We
   describe how a continuous MPLS tunnel can be built throughout the
   network.

                             PE2            PE4
                               \            /
                        PE1----P5--P6--P7--P8---PE3

                     Figure 3: SR and LDP Interworking

   Let us analyze the following example:

      P6, P7, P8, PE4 and PE3 are LDP capable.

      PE1, PE2, P5 and P6 are SR capable.  PE1, PE2, P5 and P6 are
      configured with SRGB (100, 200) and respectively with node
      segments 101, 102, 105 and 106.

      A service flow must be tunneled from PE1 to PE3 over a continuous
      MPLS tunnel encapsulation.  We need SR and LDP to interwork.

   If the SR/LDP node operates in LDP ordered label distribution control
   mode (as defined in [RFC5036]), then the SR/LDP node MUST consider SR
   learned labels as if they were learned through an LDP neighbor and

Filsfils, et al.        Expires December 17, 2017               [Page 7]
Internet-Draft           Segment Routing and LDP               June 2017

   create LDP bindings for each Prefix-SID and Node-SID learned in the
   SR domain.

4.1.  LDP to SR

   In this section, we analyze a right-to-left traffic flow.

   PE3 has learned a service route whose next-hop is PE1.  PE3 has an
   LDP label binding from the next-hop P8 for the FEC "PE1".  Hence PE3
   sends its service packet to P8 as per classic LDP behavior.

   P8 has an LDP label binding from its next-hop P7 for the FEC "PE1"
   and hence P8 forwards to P7 as per classic LDP behavior.

   P7 has an LDP label binding from its next-hop P6 for the FEC "PE1"
   and hence P7 forwards to P6 as per classic LDP behavior.

   P6 does not have an LDP binding from its next-hop P5 for the FEC
   "PE1".  However P6 has an SR node segment to the IGP route "PE1".
   Hence, P6 forwards the packet to P5 and swaps its local LDP-label for
   FEC "PE1" by the equivalent node segment (i.e. 101).

   P5 pops 101 (assuming PE1 advertised its node segment 101 with the
   penultimate-pop flag set) and forwards to PE1.

   PE1 receives the tunneled packet and processes the service label.

   The end-to-end MPLS tunnel is built from an LDP LSP from PE3 to P6
   and the related node segment from P6 to PE1.

4.1.1.  LDP to SR Behavior

   It has to be noted that no additional signaling or state is required
   in order to provide interworking in the direction LDP to SR.

   A SR node having LDP neighbors MUST create LDP bindings for each
   Prefix-SID and Node-SID learned in the SR domain and, for each FEC,
   stitch the incoming LDP label to the outgoing SR label.  This has to
   be done in both LDP independent and ordered label distribution
   control modes as defined in [RFC5036].

4.2.  SR to LDP

   In this section, we analyze the left-to-right traffic flow.

   We introduce the definition of the Segment Routing Mapping Server
   (SRMS) which consists of an IGP (IS-IS, OSPF and OSPFv3) extension
   allowing an SR capable router to advertise mappings between prefixes

Filsfils, et al.        Expires December 17, 2017               [Page 8]
Internet-Draft           Segment Routing and LDP               June 2017

   and Segment Identifiers (SID).  The details on how the mappings are
   encoded and advertised are protocol specific and defined in
   [I-D.ietf-isis-segment-routing-extensions],
   [I-D.ietf-ospf-segment-routing-extensions] and
   [I-D.ietf-ospf-ospfv3-segment-routing-extensions].

   The SRMS function of a SR capable router allows distribution of
   mappings for prefixes not locally attached to the advertising router
   and therefore allows advertisement of mappings on behalf of non-SR
   capable routers.

   The SRMS is a control plane only function which may be located
   anywhere in the IGP flooding scope.  Multiple SRMSs may be present in
   the same network (for redundancy).  This implies that there are
   multiple ways a prefix-to-SID mapping can be advertised.  Conflicts
   resulting from inconsistent advertisements are addressed by
   [I-D.ietf-spring-conflict-resolution].

   In the example diagram depicted in Figure 3, we assume that the
   operator configures P5 to act as a Segment Routing Mapping Server
   (SRMS) and advertises the following mappings: (P7, 107), (P8, 108),
   (PE3, 103) and (PE4, 104).

   The mappings advertised by one or more SRMSs result from local policy
   information configured by the operator.

   If PE3 had been SR capable, the operator would have configured PE3
   with node segment 103.  Instead, as PE3 is not SR capable, the
   operator configures that policy at the SRMS and it is the latter
   which advertises the mapping.

   The mapping server advertisements are only understood by SR capable
   routers.  The SR capable routers install the related node segments in
   the MPLS data plane exactly like the node segments had been
   advertised by the nodes themselves.

   For example, PE1 installs the node segment 103 with next-hop P5
   exactly as if PE3 had advertised node segment 103.

   PE1 has a service route whose next-hop is PE3.  PE1 has a node
   segment for that IGP route: 103 with next-hop P5.  Hence PE1 sends
   its service packet to P5 with two labels: the bottom label is the
   service label and the top label is 103.

   P5 swaps 103 for 103 and forwards to P6.

   P6's next-hop for the IGP route "PE3" is not SR capable (P7 does not
   advertise the SR capability).  However, P6 has an LDP label binding

Filsfils, et al.        Expires December 17, 2017               [Page 9]
Internet-Draft           Segment Routing and LDP               June 2017

   from that next-hop for the same FEC (e.g.  LDP label 1037).  Hence,
   P6 swaps 103 for 1037 and forwards to P7.

   P7 swaps this label with the LDP-label received from P8 and forwards
   to P8.

   P8 pops the LDP label and forwards to PE3.

   PE3 receives the tunneled packet and processes the service label.

   The end-to-end MPLS tunnel is built from an SR node segment from PE1
   to P6 and an LDP LSP from P6 to PE3.

   Note: SR mappings advertisements cannot set Penultimate Hop Popping.
   In the previous example, P6 requires the presence of the segment 103
   such as to map it to the LDP label 1037.  For that reason, the P flag
   available in the Prefix-SID is not available in the Remote-Binding
   SID.

4.2.1.  SR to LDP Behavior

   SR to LDP interworking requires a SRMS as defined above.

   The SRMS MUST be configured by the operator in order to advertise
   Node-SIDs on behalf of non-SR nodes.

   At least one SRMS MUST be present in the routing domain.  Multiple
   SRMSs SHOULD be present for redundancy.

   Each SR capable router installs in the MPLS data plane Node-SIDs
   learned from the SRMS exactly like if these SIDs had been advertised
   by the nodes themselves.

   A SR node having LDP neighbors MUST create LDP bindings for each
   Prefix-SID and Node-SID learned in the SR domain and, for each FEC,
   stitch the incoming SR label to the outgoing LDP label.  This has to
   be done in both LDP independent and ordered label distribution
   control modes as defined in [RFC5036].

   It has to be noted that the SR to LDP behavior does not propagate the
   status of the LDP FEC which was signaled if LDP was configured to use
   the ordered mode.

   It has to be noted that in the case of SR to LDP, the label binding
   is equivalent to the independent LDP Label Distribution Control Mode
   ([RFC5036]) where a label in bound to a FEC independently from the
   received binding for the same FEC.

Filsfils, et al.        Expires December 17, 2017              [Page 10]
Internet-Draft           Segment Routing and LDP               June 2017

5.  SR/LDP Interworking Use Cases

   SR can be deployed such as to enhance LDP transport.  The SR
   deployment can be limited to the network region where the SR benefits
   are most desired.

5.1.  SR Protection of LDP-based Traffic

   In Figure 4, let us assume:

      All link costs are 10 except FG which is 30.

      All routers are LDP capable.

      X, Y and Z are PE's participating to an important service S.

      The operator requires 50msec link-based Fast Reroute (FRR) for
      service S.

      A, B, C, D, E, F and G are SR capable.

      X, Y, Z are not SR capable, e.g. as part of a staged migration
      from LDP to SR, the operator deploys SR first in a sub-part of the
      network and then everywhere.

                                     X
                                     |
                              Y--A---B---E--Z
                                 |   |    \
                                 D---C--F--G
                                         30

                   Figure 4: SR/LDP interworking example

   The operator would like to resolve the following issues:

      To protect the link BA along the shortest-path of the important
      flow XY, B requires a Remote LFA (RLFA, [RFC7490]) repair tunnel
      to D and hence a targeted LDP session from B to D.  Typically,
      network operators prefer avoiding these dynamically established
      multi-hop LDP sessions in order to reduce the number of protocols
      running in the network and hence simplify network operations.

      There is no LFA/RLFA solution to protect the link BE along the
      shortest path of the important flow XZ.  The operator wants a
      guaranteed link-based FRR solution.

Filsfils, et al.        Expires December 17, 2017              [Page 11]
Internet-Draft           Segment Routing and LDP               June 2017

   The operator can meet these objectives by deploying SR only on A, B,
   C, D, E, F and G:

      The operator configures A, B, C, D, E, F and G with SRGB (100,
      200) and respective node segments 101, 102, 103, 104, 105, 106 and
      107.

      The operator configures D as an SR Mapping Server with the
      following policy mapping: (X, 201), (Y, 202), (Z, 203).

      Each SR node automatically advertises local adjacency segment for
      its IGP adjacencies.  Specifically, F advertises adjacency segment
      9001 for its adjacency FG.

   A, B, C, D, E, F and G keep their LDP capability and hence the flows
   XY and XZ are transported over end-to-end LDP LSP's.

   For example, LDP at B installs the following MPLS data plane entries:

   Incoming label: local LDP label bound by B for FEC Y
      Outgoing label: LDP label bound by A for FEC Y
      Outgoing next-hop: A

   Incoming label: local LDP label bound by B for FEC Z
     Outgoing label: LDP label bound by E for FEC Z
     Outgoing next-hop: E

   The novelty comes from how the backup chains are computed for these
   LDP-based entries.  While LDP labels are used for the primary next-
   hop and outgoing labels, SR information is used for the FRR
   construction.  In steady state, the traffic is transported over LDP
   LSP.  In transient FRR state, the traffic is backup thanks to the SR
   enhanced capabilities.

   The RLFA paths are dynamically pre-computed as defined in [RFC7490].
   Typically, implementations allow to enable RLFA mechanism through a
   simple configuration command that triggers both the pre-computation
   and installation of the repair path.  The details on how RLFA
   mechanisms are implemented and configured is outside the scope of
   this document and not relevant to the aspects of SR/LDP interwork
   explained in this document.

   This helps meet the requirements of the operator:

      Eliminate targeted LDP session.

      Guaranteed FRR coverage.

Filsfils, et al.        Expires December 17, 2017              [Page 12]
Internet-Draft           Segment Routing and LDP               June 2017

      Keep the traffic over LDP LSP in steady state.

      Partial SR deployment only where needed.

5.2.  Eliminating Targeted LDP Session

   B's MPLS entry to Y becomes:

   - Incoming label: local LDP label bound by B for FEC Y
       Outgoing label: LDP label bound by A for FEC Y
       Backup outgoing label: SR node segment for Y {202}
       Outgoing next-hop: A
       Backup next-hop: repair tunnel: node segment to D {104}
        with outgoing next-hop: C

   It has to be noted that D is selected as Remote Loop-Free Alternate
   (R-LFA) as defined in [RFC7490].

   In steady-state, X sends its Y-destined traffic to B with a top label
   which is the LDP label bound by B for FEC Y.  B swaps that top label
   for the LDP label bound by A for FEC Y and forwards to A.  A pops the
   LDP label and forwards to Y.

   Upon failure of the link BA, B swaps the incoming top-label with the
   node segment for Y (202) and sends the packet onto a repair tunnel to
   D (node segment 104).  Thus, B sends the packet to C with the label
   stack {104, 202}. C pops the node segment 104 and forwards to D.  D
   swaps 202 for 202 and forwards to A.  A's next-hop to Y is not SR
   capable and hence node A swaps the incoming node segment 202 to the
   LDP label announced by its next-hop (in this case, implicit null).

   After IGP convergence, B's MPLS entry to Y will become:

   - Incoming label: local LDP label bound by B for FEC Y
       Outgoing label: LDP label bound by C for FEC Y
       Outgoing next-hop: C

   And the traffic XY travels again over the LDP LSP.

   Conclusion: the operator has eliminated the need for targeted LDP
   sessions (no longer required) and the steady-state traffic is still
   transported over LDP.  The SR deployment is confined to the area
   where these benefits are required.

   Despite that in general, an implementation would not require a manual
   configuration of LDP Targeted sessions however, it is always a gain
   if the operator is able to reduce the set of protocol sessions
   running on the network infrastructure.

Filsfils, et al.        Expires December 17, 2017              [Page 13]
Internet-Draft           Segment Routing and LDP               June 2017

5.3.  Guaranteed FRR coverage

   As mentioned in Section 5.1 above, in the example topology described
   in Figure 4, there is no RLFA-based solution for protecting the
   traffic flow YZ against the failure of link BE because there is no
   intersection between the extended P-space and Q-space (see [RFC7490]
   for details).  However:

   o  G belongs to the Q space of Z.

   o  G can be reached from B via a "repair SR path" {106, 9001} that is
      not affected by failure of link BE (The method by which G and the
      repair tunnel to it from B are identified are out of scope of this
      document.)

   B's MPLS entry to Z becomes:

   - Incoming label: local LDP label bound by B for FEC Z
       Outgoing label: LDP label bound by E for FEC Z
       Backup outgoing label: SR node segment for Z {203}
       Outgoing next-hop: E
       Backup next-hop: repair tunnel to G: {106, 9001}

           G is reachable from B via the combination of a
           node segment to F {106} and an adjacency segment
           FG {9001}

           Note that {106, 107} would have equally work.
           Indeed, in many case, P's shortest path to Q is
           over the link PQ. The adjacency segment from P to
           Q is required only in very rare topologies where
           the shortest-path from P to Q is not via the link
           PQ.

   In steady-state, X sends its Z-destined traffic to B with a top label
   which is the LDP label bound by B for FEC Z.  B swaps that top label
   for the LDP label bound by E for FEC Z and forwards to E.  E pops the
   LDP label and forwards to Z.

   Upon failure of the link BE, B swaps the incoming top-label with the
   node segment for Z (203) and sends the packet onto a repair tunnel to
   G (node segment 106 followed by adjacency segment 9001).  Thus, B
   sends the packet to C with the label stack {106, 9001, 203}. C pops
   the node segment 106 and forwards to F.  F pops the adjacency segment
   9001 and forwards to G.  G swaps 203 for 203 and forwards to E.  E's
   next-hop to Z is not SR capable and hence E swaps the incoming node
   segment 203 for the LDP label announced by its next-hop (in this
   case, implicit null).

Filsfils, et al.        Expires December 17, 2017              [Page 14]
Internet-Draft           Segment Routing and LDP               June 2017

   After IGP convergence, B's MPLS entry to Z will become:

   - Incoming label: local LDP label bound by B for FEC Z
       Outgoing label: LDP label bound by C for FEC Z
       Outgoing next-hop: C

   And the traffic XZ travels again over the LDP LSP.

   Conclusions:

   o  the operator has eliminated its second problem: guaranteed FRR
      coverage is provided.  The steady-state traffic is still
      transported over LDP.  The SR deployment is confined to the area
      where these benefits are required.

   o  FRR coverage has been achieved without any signaling for setting
      up the repair LSP and without setting up a targeted LDP session
      between B and G.

5.4.  Inter-AS Option C, Carrier's Carrier

   In inter-AS Option C, two interconnected ASes sets up inter-AS MPLS
   connectivity.  SR may be independently deployed in each AS.

                       PE1---R1---B1---B2---R2---PE2
                       <----------->   <----------->
                            AS1            AS2

                        Figure 5: Inter-AS Option C

   In Inter-AS Option C [RFC4364], B2 advertises to B1 a BGP3107 route
   for PE2 and B1 reflects it to its internal peers, such as PE1.  PE1
   learns from a service route reflector a service route whose next-hop
   is PE2.  PE1 resolves that service route on the BGP3107 route to PE2.
   That BGP3107 route to PE2 is itself resolved on the AS1 IGP route to
   B1.

   If AS1 operates SR, then the tunnel from PE1 to B1 is provided by the
   node segment from PE1 to B1.

   PE1 sends a service packet with three labels: the top one is the node
   segment to B1, the next-one is the BGP3107 label provided by B1 for
   the route "PE2" and the bottom one is the service label allocated by
   PE2.

Filsfils, et al.        Expires December 17, 2017              [Page 15]
Internet-Draft           Segment Routing and LDP               June 2017

6.  IANA Considerations

   This document does not introduce any new codepoint.

7.  Manageability Considerations

7.1.  SR and LDP co-existence

   As illustrated in Section 2.2, when both SR and LDP co-exist, the
   following applies:

   o  If both SR and LDP propose an IP2MPLS entry for the same IP
      prefix, then by default the LDP route MUST be selected.

   o  A local policy on a router MUST allow to prefer the SR-provided
      IP2MPLS entry.

   o  Note that this policy MAY be locally defined.  There is no
      requirement that all routers use the same policy.

7.2.  SRMS Management

   In the case of SR/LDP interoperability through the use of a SRMS,
   mappings are advertised by one or more SRMS.

   SRMS function is implemented in the link-state protocol (such as IS-
   IS and OSPF).  Link-state protocols allow propagation of updates
   across area boundaries and therefore SRMS advertisements are
   propagated through the usual inter-area advertisement procedures in
   link-state protocols.

   Multiple SRMSs can be provisioned in a network for redundancy.
   Moreover, a preference mechanism may also be used among SRMSs so to
   deploy a primary/secondary SRMS scheme allowing controlled
   modification or migration of SIDs.

   The content of SRMS advertisement (i.e.: mappings) are a matter of
   local policy determined by the operator.  When multiple SRMSs are
   active, it is necessary that the information (mappings) advertised by
   the different SRMSs is aligned and consistent.
   [I-D.ietf-spring-conflict-resolution] illustrates mechanisms through
   which such consistency is achieved.

   When the SRMS advertise mappings, an implementation SHOULD provide a
   mechanism through which the operator determines which of the IP2MPLS
   mappings are preferred among the one advertised by the SRMS and the
   ones advertised by LDP.

Filsfils, et al.        Expires December 17, 2017              [Page 16]
Internet-Draft           Segment Routing and LDP               June 2017

7.3.  Dataplane Verification

   When Label switch paths (LSPs) are defined by stitching LDP LSPs with
   SR LSPs, it is necessary to have mechanisms allowing the verification
   of the LSP connectivity as well as validation of the path.  These
   mechanisms are described in [I-D.ietf-mpls-spring-lsp-ping].

8.  Security Considerations

   This document does not introduce any change to the MPLS dataplane and
   therefore no additional security of the MPLS dataplane is required.

   This document introduces another form of label binding
   advertisements.  The security associated with these advertisement is
   part of the security applied to routing protocols such as IS-IS and
   OSPF which both make use of cryptographic authentication mechanisms.

9.  Acknowledgements

   We would like to thank Pierre Francois, Ruediger Geib and Alexander
   Vainshtein for their contribution to the content of this document.

10.  Contributors' Addresses

   Edward Crabbe
   Individual
   Email: edward.crabbe@gmail.com

   Igor Milojevic
   Email: milojevicigor@gmail.com

   Saku Ytti
   TDC
   Email: saku@ytti.fi

   Rob Shakir
   Google
   Email: robjs@google.com

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

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

Filsfils, et al.        Expires December 17, 2017              [Page 17]
Internet-Draft           Segment Routing and LDP               June 2017

   Jeff Tantsura
   Individual
   Email: jefftant@gmail.com

11.  References

11.1.  Normative References

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

   [I-D.ietf-ospf-ospfv3-segment-routing-extensions]
              Psenak, P., Previdi, 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.,
              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-conflict-resolution]
              Ginsberg, L., Psenak, P., Previdi, S., and M. Pilka,
              "Segment Routing MPLS Conflict Resolution", draft-ietf-
              spring-conflict-resolution-04 (work in progress), May
              2017.

   [I-D.ietf-spring-segment-routing]
              Filsfils, C., Previdi, S., Decraene, B., Litkowski, S.,
              and R. Shakir, "Segment Routing Architecture", draft-ietf-
              spring-segment-routing-11 (work in progress), February
              2017.

   [I-D.ietf-spring-segment-routing-mpls]
              Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,
              Litkowski, S., and R. Shakir, "Segment Routing with MPLS
              data plane", draft-ietf-spring-segment-routing-mpls-08
              (work in progress), March 2017.

Filsfils, et al.        Expires December 17, 2017              [Page 18]
Internet-Draft           Segment Routing and LDP               June 2017

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

11.2.  Informative References

   [I-D.bashandy-rtgwg-segment-routing-ti-lfa]
              Bashandy, A., Filsfils, C., Decraene, B., Litkowski, S.,
              and P. Francois, "Abstract", draft-bashandy-rtgwg-segment-
              routing-ti-lfa-00 (work in progress), February 2017.

   [I-D.ietf-mpls-spring-lsp-ping]
              Kumar, N., Swallow, G., Pignataro, C., Akiya, N., Kini,
              S., Gredler, H., and M. Chen, "Label Switched Path (LSP)
              Ping/Traceroute for Segment Routing Networks with MPLS
              Dataplane", draft-ietf-mpls-spring-lsp-ping-03 (work in
              progress), June 2017.

   [RFC4364]  Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
              Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
              2006, <http://www.rfc-editor.org/info/rfc4364>.

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

   [RFC5960]  Frost, D., Ed., Bryant, S., Ed., and M. Bocci, Ed., "MPLS
              Transport Profile Data Plane Architecture", RFC 5960,
              DOI 10.17487/RFC5960, August 2010,
              <http://www.rfc-editor.org/info/rfc5960>.

   [RFC7490]  Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N.
              So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)",
              RFC 7490, DOI 10.17487/RFC7490, April 2015,
              <http://www.rfc-editor.org/info/rfc7490>.

Authors' Addresses

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

   Email: cfilsfil@cisco.com

Filsfils, et al.        Expires December 17, 2017              [Page 19]
Internet-Draft           Segment Routing and LDP               June 2017

   Stefano Previdi (editor)
   Cisco Systems, Inc.
   IT

   Email: stefano@previdi.net

   Ahmed Bashandy
   Cisco Systems, Inc.
   170, West Tasman Drive
   San Jose, CA  95134
   US

   Email: bashandy@cisco.com

   Bruno Decraene
   Orange
   FR

   Email: bruno.decraene@orange.com

   Stephane Litkowski
   Orange
   FR

   Email: stephane.litkowski@orange.com

Filsfils, et al.        Expires December 17, 2017              [Page 20]