Skip to main content

IS-IS Extensions for Segment Routing
draft-previdi-isis-segment-routing-extensions-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
Authors Stefano Previdi , Clarence Filsfils , Ahmed Bashandy , Bruno Decraene , Stephane Litkowski , Rudiger Geib , Igor Milojevic , Rob Shakir , Saku Ytti , Wim Henderickx , Jeff Tantsura
Last updated 2013-06-28
Replaced by draft-ietf-isis-segment-routing-extensions, RFC 8667
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-previdi-isis-segment-routing-extensions-00
IS-IS for IP Internets                                   S. Previdi, Ed.
Internet-Draft                                               C. Filsfils
Intended status: Standards Track                             A. Bashandy
Expires: December 30, 2013                           Cisco Systems, Inc.
                                                             B. Decraene
                                                            S. Litkowski
                                                                  Orange
                                                                 R. Geib
                                                        Deutsche Telekom
                                                            I. Milojevic
                                                          Telekom Srbija
                                                               R. Shakir
                                                         British Telecom
                                                                 S. Ytti
                                                                  TDC Oy
                                                           W. Henderickx
                                                          Alcatel-Lucent
                                                             J. Tantsura
                                                                Ericsson
                                                           June 28, 2013

                  IS-IS Extensions for Segment Routing
            draft-previdi-isis-segment-routing-extensions-00

Abstract

   Segment Routing (SR) allows for a flexible definition of end-to-end
   paths within IGP topologies by encoding paths as sequences of
   topological sub-paths, called "segments".  These segments are
   advertised by the link-state routing protocols (IS-IS and OSPF).

   This draft describes the necessary IS-IS extensions that need to be
   introduced for Segment Routing.

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

Previdi, et al.         Expires December 30, 2013               [Page 1]
Internet-Draft    IS-IS Extensions for Segment Routing         June 2013

   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."

   This Internet-Draft will expire on December 30, 2013.

Copyright Notice

   Copyright (c) 2013 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.

Previdi, et al.         Expires December 30, 2013               [Page 2]
Internet-Draft    IS-IS Extensions for Segment Routing         June 2013

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Segment Routing Identifiers  . . . . . . . . . . . . . . . . .  4
     2.1.  Prefix Segment Identifier (Prefix-SID Sub-TLV) . . . . . .  4
     2.2.  Adjacency Segment Identifier (Adj-SID) . . . . . . . . . .  6
       2.2.1.  Adj-SID and Interface Address  . . . . . . . . . . . .  7
       2.2.2.  Adj-SID and Forwarding Adjacencies . . . . . . . . . .  7
       2.2.3.  Adjacency Segment Identifier (Adj-SID) Sub-TLV . . . .  7
       2.2.4.  Adjacency Segment Identifiers in LANs  . . . . . . . . 10
   3.  Segment Routing Capabilities . . . . . . . . . . . . . . . . . 12
     3.1.  Segment Routing Capability Sub-TLV (SR-Cap)  . . . . . . . 12
     3.2.  Segment Routing Mapping Server . . . . . . . . . . . . . . 14
       3.2.1.  SR Mapping Server Sub-TLV  . . . . . . . . . . . . . . 14
     3.3.  Segment Routing Mirroring Context Sub-TLV (SRMC) . . . . . 17
   4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 18
   5.  Manageability Considerations . . . . . . . . . . . . . . . . . 18
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 18
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 19
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 20
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20

Previdi, et al.         Expires December 30, 2013               [Page 3]
Internet-Draft    IS-IS Extensions for Segment Routing         June 2013

1.  Introduction

   Segment Routing (SR) allows for a flexible definition of end-to-end
   paths within IGP topologies by encoding paths as sequences of
   topological sub-paths, called "segments".  These segments are
   advertised by the link-state routing protocols (IS-IS and OSPF).  Two
   types of segments are defined, Prefix segments and Adjacency
   segments.  Prefix segments represent an ecmp-aware shortest-path to a
   prefix, as per the state of the IGP topology.  Adjacency segments
   represent a hop over a specific adjacency between two nodes in the
   IGP.  A prefix segment is typically a multi-hop path while an
   adjacency segment, in most of the cases, is a one-hop path.  SR's
   control-plane can be applied to both IPv6 and MPLS data-planes, and
   do not require any additional signaling (other than the regular IGP).
   For example, when used in MPLS networks, SR paths do not require any
   LDP or RSVP-TE signaling.  Still, SR can interoperate in the presence
   of LSPs established with RSVP or LDP .

   This draft describes the necessary IS-IS extensions that need to be
   introduced for Segment Routing.

   This draft replaces [I-D.previdi-filsfils-isis-segment-routing].

   Segment Routing architecture is described in
   [draft-filsfils-rtgwg-segment-routing-00].

   Segment Routing use cases are described in
   [draft-filsfils-rtgwg-segment-routing-use-cases-00].

2.  Segment Routing Identifiers

   Segment Routing architecture defines different types of Segment
   Identifiers (SID).  This document defines the IS-IS encodings for the
   IGP-Prefix-SID and IGP-Adjacency-SID.

2.1.  Prefix Segment Identifier (Prefix-SID Sub-TLV)

   A new IS-IS Sub-TLV is defined: the Prefix Segment Identifier Sub-TLV
   (Prefix-SID Sub-TLV).

   The Prefix-SID Sub-TLV carries the Segment Routing IGP-Prefix-SID and
   has flags and fields that may be used, in future extensions of
   Segment Routing, for carrying other types of SIDs.

   A Prefix-SID Sub-TLV is associated to a prefix advertised by a node
   and MAY be present in any of the following TLVs:

Previdi, et al.         Expires December 30, 2013               [Page 4]
Internet-Draft    IS-IS Extensions for Segment Routing         June 2013

      TLV-135 (IPv4) defined in [RFC5305].

      TLV-235 (MT-ipv4) defined in [RFC5120].

      TLV-236 (IPv6) defined in [RFC5308].

      TLV-237 (MT-IPv6) defined in [RFC5120].

   The Prefix-SID Sub-TLV has the following format:
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type        |     Length    |            Flags              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Prefix Segment Identifier (SID)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   where:

      Type: TBA

      Length: multiple of 6 octets.

      Flags: 2 octets field of following flags:
          0                   1
          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |R|N|P|G|                       |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         where:

         R-Flag: Re-advertisement flag.  If set, then the prefix to
         which this Prefix-SID is attached, has been propagated by the
         router either from another level (i.e.: from level-1 to level-2
         or the opposite) or from redistribution (e.g.: from another
         protocol).

         N-Flag: Node-SID flag.  If set, then the Prefix-SID refers to
         the router identified by the prefix.  Typically, the N-Flag is
         set on Prefix-SIDs attached to a router loopback address.  The
         N-Flag is set when the Prefix-SID is a Node-SID as described in
         [draft-filsfils-rtgwg-segment-routing-00].  This flag is
         optional.

Previdi, et al.         Expires December 30, 2013               [Page 5]
Internet-Draft    IS-IS Extensions for Segment Routing         June 2013

         P-Flag: no-PHP flag.  If set, then the penultimate hop MUST NOT
         pop the Prefix-SID before delivering the packet to the node
         that advertised the Prefix-SID.

         G-Flag: Global flag.  When set, the SID value has global
         significance which means the SID has been allocated from the
         Global Segment Routing Block (SRGB) as described in
         [draft-filsfils-rtgwg-segment-routing-00].  When unset, the SID
         value has local (within the router) significance which means
         the SID has NOT been allocated from the SRGB.  When the IS-IS
         Prefix-SID Sub-TLV carries an IGP Prefix SID, then the G-flag
         MUST be set.

         Other bits: MUST be zero when originated and ignored when
         received.

      Prefix Segment Identifier (SID): 32 bits of Prefix-SID.

   Multiple Prefix-SIDs MAY appear on the same prefix in which case each
   SID is encoded as a tuple <flags, Prefix-SID>.  When multiple Prefix-
   SIDs are present, the receiving router MUST use the first encoded SID
   and MAY use the subsequent ones.

   The No-PHP flag MUST be set on the Prefix-SIDs allocated to Level-2
   prefixes that are originated by the router based on Level-1
   reachability (i.e.: prefixes that are propagated from Level-1 into
   Level-2).

   The No-PHP flag MUST be set on Prefix-SIDs allocated to Level-1
   prefixes that are originated by the router based on Level-2
   reachability (i.e.: prefixes that are leaked from Level-2 into
   Level-1).

   The R-Flag MUST be set for prefixes that are advertised because of
   propagation (Level-1 into Level-2), leaking (Level-2 into Level-1)
   and redistribution (e.g.: from another protocol).

2.2.  Adjacency Segment Identifier (Adj-SID)

   A new IS-IS Sub-TLV is defined: the Adjacency Segment Identifier Sub-
   TLV (Adj-SID Sub-TLV).

   The Adj-SID Sub-TLV is an optional Sub-TLV carrying the Segment
   Routing IGP-Adjacency-SID with flags and fields that may be used, in
   future extensions of Segment Routing, for carrying other types of
   SIDs.

   IS-IS adjacencies are advertised using one of the IS-Neighbor TLVs

Previdi, et al.         Expires December 30, 2013               [Page 6]
Internet-Draft    IS-IS Extensions for Segment Routing         June 2013

   below:

      TLV-22 [RFC5305]

      TLV-222 [RFC5120]

      TLV-23 [RFC5311]

      TLV-223 [RFC5311]

      TLV-141 [RFC5316]

   Currently, [RFC5316] defines TLV-141 with the purpose of inter-AS
   connectivity.  In the Segment Routing context, we relax the
   constraint and we allow TLV-141 to be used for advertising any link
   that is external to the IS-IS domain no matter if it connects another
   AS or not.

   Multiple Adj-SID Sub-TLVs MAY be associated with a single IS-
   neighbor.  Examples where more than one Adj-SID may be used per IS-
   neighbor are described in
   [draft-filsfils-rtgwg-segment-routing-use-cases-00].

2.2.1.  Adj-SID and Interface Address

   When advertising one or more Adj-SID Sub-TLVs, the router MUST also
   advertise Interface Address and Neighbor Address Sub-TLVs (IPv4 or
   IPv6).  The encoding is defined in [RFC5305] for IPv4 and in
   [RFC6119] for IPv6.

2.2.2.  Adj-SID and Forwarding Adjacencies

   Forwarding Adjacencies are defined in [RFC4206] and allow a router to
   advertise an MPLS RSVP-TE LSP as if it was a regular IS-IS adjacency.

   Segment Routing supports FAs and Adj-SIDs can be assigned to FA
   advertisements.  A new sub-TLV (defined below) is introduced in order
   to give the optional ability to advertise the explicit path
   represented by a FA.

2.2.3.  Adjacency Segment Identifier (Adj-SID) Sub-TLV

   The following format is defined for the Adj-SID Sub-TLV:

Previdi, et al.         Expires December 30, 2013               [Page 7]
Internet-Draft    IS-IS Extensions for Segment Routing         June 2013

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type        |     Length    |             Flags             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Adj-SID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     ERO (optional and variable)               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   where:

      Type: TBA

      Length: variable.

      Flags: 2 octets field of following flags:
          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |F|I|V|E|G|T|                   |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         where:

         F-Flag: FA flag.  Optional and, if set, then Adj-SID refers to
         a Forwarding Adjacency.

         I-Flag: IPv4 flag.  Optional and, if set, then the Adj-SID
         refers to an adjacency with outgoing IPv4 encapsulation.

         V-Flag: IPv6 flag.  Optional and, if set, then the Adj-SID
         refers to an adjacency with outgoing IPv6 encapsulation.

         E-Flag: ERO presence flag.  Optional and, If set, it indicates
         presence of the ERO object.

         G-Flag: Global flag.  When set, the SID value has global
         significance which means the SID has been allocated from the
         Segment Routing Global Block (SRGB) as described in
         [draft-filsfils-rtgwg-segment-routing-00].  When unset, the SID
         value has local (within the router) significance which means
         the SID has NOT been allocated from the SRGB.  When the IS-IS
         Adj-SID Sub-TLV carries the IGP Adjacency SID, then the G-Flag
         MUST be unset.

Previdi, et al.         Expires December 30, 2013               [Page 8]
Internet-Draft    IS-IS Extensions for Segment Routing         June 2013

         T-Flag: Protected-flag.  Optional and, if set, the Adj-SID
         refers to an adjacency being protected (e.g.: using IPFRR or
         MPLS-FRR) as described in
         [draft-filsfils-rtgwg-segment-routing-use-cases-00].

         Other bits: MUST be zero when originated and ignored when
         received.

      Adj-SID: 32 bits of Adjacency Segment Identifier (Adj-SID).

      An SR capable router SHOULD allocate an Adj-SID for each of its
      adjacencies and set the T-Flag when the adjacency is protected by
      a FRR mechanism (IP or MPLS) as described in
      [draft-filsfils-rtgwg-segment-routing-use-cases-00].

      If both the I and V flag are set, then the encapsulation MUST be
      determined by the inspection of the first 4 bits of the IP packet
      (IPv4 or IPv6).

      Both the I and V flags are optional.  When the I or V flags are
      set, they take precedence over the I or V flags defined in
      Section 3.1.

   If the E-flag is set, then the explicit path taken by the Forwarding
   Adjacency MUST be encoded using the following format:
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Length    |     Flags     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Explicit Route Hop  #1                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Explicit Route Hop  #...                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             ....                              |

   where:

      Length: 1 octet of length of the ERO object.

      Flags: 1 octet flag field where following flags are defined:
          0 1 2 3 4 5 6 7
         +-+-+-+-+-+-+-+-+
         |I|V|R|         |
         +-+-+-+-+-+-+-+-+

         where:

Previdi, et al.         Expires December 30, 2013               [Page 9]
Internet-Draft    IS-IS Extensions for Segment Routing         June 2013

         I-Flag is the IPv4 flag.  When set the content of the Explicit
         Route Object contains IPv4 addresses.

         V-Flag is the IPv6 flag.  When set the content of the Explicit
         Route Object contains IPv6 addresses.

         R-Flag is the Segment Routing flag.  When set the content of
         the Explicit Route Object contains SIDs.

      Explicit Route Hop: addresses of the explicit route.  IPv4 and SR
      hops are encoded using a 32 bit value while IPv6 hops are encoded
      as 128 bit values.

      Only one flag MUST be set among the I, V and R flags.  If more
      than one are set , the receiving router MUST ignore the ERO object
      and SHOULD log an error.

2.2.4.  Adjacency Segment Identifiers in LANs

   In LAN subnetworks, the Designated Intermediate System (DIS) is
   elected and originates the Pseudonode-LSP (PN-LSP) including all
   neighbors of the DIS.

   When Segment Routing is used, each router in the LAN MUST advertise
   the Adj-SID of each of its neighbors.  Since, on LANs, each router
   only advertises one adjacency to the DIS (and doesn't advertise any
   other adjacency), each router advertises the set of Adj-SIDs (for
   each of its neighbors) inside a newly defined Sub-TLV part of the TLV
   advertising the adjacency to the DIS (e.g.: TLV-22).

   Inside the Adj-SID Sub-TLV described in Section 2.2.3 the following
   new Sub-TLV is defined: LAN-Adj-SID which contains the set of Adj-
   SIDs the router assigned to each of its LAN neighbors.  The format of
   the LAN-Adj-SID Sub-TLV is as follows:

Previdi, et al.         Expires December 30, 2013              [Page 10]
Internet-Draft    IS-IS Extensions for Segment Routing         June 2013

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type        |     Length    |               Flags           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Adj-SID    #1 (4 octets)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     System-ID  #1 (6 octets)                  |
   +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             ....

   |                             ....                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Adj-SID    #n (4 octets)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     System-ID  #n                             |
   +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   where:

      Type: TBA.

      Length: is 2 + multiple of 10 octets.

      Flags: 2 octets field of following flags:
          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |I|V|T|                         |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         where:

         I-Flag: IPv4 flag.  If set, then the Adj-SID refers to an
         adjacency with outgoing SR IPv4 encapsulation.

         V-Flag: IPv6 flag.  If set, then the Adj-SID refers to an
         adjacency with outgoing SR IPv6 encapsulation.

         T-Flag: Protected-flag: set if the LAN interface is being
         protected (e.g.: using IPFRR or MPLS-FRR) as described in
         [draft-filsfils-rtgwg-segment-routing-use-cases-00].

Previdi, et al.         Expires December 30, 2013              [Page 11]
Internet-Draft    IS-IS Extensions for Segment Routing         June 2013

         Other bits: MUST be zero when originated and ignored when
         received.

      Adj-SID: 32 bits of SID.

      System-ID: IS-IS System-ID of length "ID Length" as defined in
      [ISO10589].

   Multiple tuples <Adj-SID, System-ID> SHOULD be encoded in one Sub-
   TLV.

   In case one TLV-22/23/222/223 (reporting the adjacency to the DIS)
   can't contain the whole set of Adj-SID Sub-TLVs, multiple
   advertisement of the adjacency to the DIS MUST be used.

   Each router within the level, by receiving the DIS PN LSP as well as
   the non-PN LSP of each router in the LAN, is capable of
   reconstructing the LAN topology as well as the set of Adj-SID each
   router uses for each of its neighbors.

3.  Segment Routing Capabilities

   Segment Routing requires each router to advertise its capabilities to
   the rest of the routing domain.  IS-IS Router Capability TLV-242 is
   defined in [RFC4971] and describes the router capabilities.  For the
   purposes of Segment Routing we define following additional Sub-TLVs:

      Segment Routing Capability Sub-TLV (SR-Cap)

      Segment Routing Mapping Server Sub-TLV (SRMS)

      Segment Routing Mirroring Context SID Sub-TLV (SRMC)

   The Router Capability TLV specifies flags that control its
   advertisement.  The SR-Cap, SRMS and SRMC Sub-TLVs MUST be propagated
   throughout the entire routing domain and therefore the Router
   Capability TLV distribution flags MUST be set accordingly, i.e.: the
   S flag must be set and the D flag MUST be set when the Capability TLV
   is leaked into level-1.

3.1.  Segment Routing Capability Sub-TLV (SR-Cap)

   The SR-Cap Sub-TLV is advertised by the SR-capable router in order to
   advertise its support of SR signaling.

   The SR-Cap Sub-TLV MUST appear only once and has following format:

Previdi, et al.         Expires December 30, 2013              [Page 12]
Internet-Draft    IS-IS Extensions for Segment Routing         June 2013

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type        |     Length    |           Flags               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        First SID Value                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Last SID Value                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   where:

      Type: TBA.

      Length: 2 octets + 8 octets if SID Values are advertised.

      Flags: 2 octets field of following flags:
           0                   1
           0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          |X|M|I|V|                       |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          where:

         X-Flag: Index flag.  If set, then each SID with the G-Flag set
         that is advertised by this router represents an index in the
         label space also advertised by this router (using the encodings
         defined below).  Indexed SID values are described in
         [draft-filsfils-rtgwg-segment-routing-00].  If the X-Flag is
         not set, then SID values 0-63 are reserved and MUST NOT be used
         by the SR control plane for either node or adjacency segments.
         Any SID which is received with a value 0-63 and the X-Flag
         unset MUST be ignored and the router SHOULD log an error.

         M-Flag: SID space flag.  If set, the router advertises SID
         space.

         I-Flag: IPv4 flag.  If set, then the router is capable of
         outgoing IPv4 encapsulation on all interfaces.

         V-Flag: IPv6 flag.  If set, then the router is capable of
         outgoing IPv6 encapsulation on all interfaces.

         Other bits: MUST be zero when originated and ignored when
         received.

Previdi, et al.         Expires December 30, 2013              [Page 13]
Internet-Draft    IS-IS Extensions for Segment Routing         June 2013

      First SID Value and Last SID Value represent the local SID range
      of the router.  The semantic and procedures of these values are
      described in [draft-filsfils-rtgwg-segment-routing-use-cases-00].

   I-Flag and V-Flag define the outgoing encapsulations the router is
   capable of on all its interfaces.  The equivalent flags are defined
   in Section 2.2.3 and allow to advertise interface-specific outgoing
   encapsulation overriding the one advertised in the SR-Cap Sub-TLV.

3.2.  Segment Routing Mapping Server

   One or more SR capable routers may act as a Segment Routing Mapping
   Server (SRMS).

   One example (but not limited to) of SR Mapping Server use is when
   some of the routers in the network do not support Segment Routing and
   therefore they won't advertise any Prefix-SID.  In such case the SRMS
   advertises the mappings on behalf of the non-SR capable routers.

   The details on the Segment Routing Mapping Server capability are
   described in [draft-filsfils-rtgwg-segment-routing-use-cases-00].

3.2.1.  SR Mapping Server Sub-TLV

   The SR Mapping Server Sub-TLV (SRMS Sub-TLV) is used in order to
   advertise Prefix-SID mappings on behalf of routers.  The SRMS Sub-TLV
   is optional and MAY appear more than once in the Router Capability
   TLV.

   The SRMS Sub-TLV has the following format:
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type        |     Length    |             Flags             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              ...                              |

   where:

      Type: TBD.

      Length: variable.

      Flags.  Following flags are defined:

Previdi, et al.         Expires December 30, 2013              [Page 14]
Internet-Draft    IS-IS Extensions for Segment Routing         June 2013

    0                   1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |I|V|R|                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   where:

         I-flag: IPv4 flag.  If set then the carried mappings refer to
         an IPv4 prefix.

         V-flag: IPv6 flag.  If set then the carried mappings refer to
         an IPv6 prefix.

         R-Flag: Range flag.  When set, the mappings are expressed using
         range values.

   The combination of the I, V flags with the R flag tells the Address
   Family and type of encodings.  When the R-flag is not set, the
   following encoding format is used:
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type        |     Length    |             Flags             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Masklength and Prefix #1 (variable length)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Prefix-SID  #1   (4 octet length)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              ...                              |

   |                              ...                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Masklength and Prefix #n (variable length)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Prefix-SID  #n   (4 octet length)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   where:

      Masklength and Prefix: the prefix to be mapped into a Prefix-SID
      consisting of 1 octet of prefix length followed by 0 to 16 octets
      of IPv4 or IPv6 prefix (determined by the I and V flags).

      Prefix-SID: 4 octet Node Segment Identifier mapped to the prefix.

   The 8 bits of prefix length can have the values 0-128 and indicate
   the number of significant bits in the prefix.  The prefix is encoded

Previdi, et al.         Expires December 30, 2013              [Page 15]
Internet-Draft    IS-IS Extensions for Segment Routing         June 2013

   in the minimal number of octets for the given number of significant
   bits as follows:

      Prefix octets = integer of ((prefix length + 7) / 8)

   The range option (the R bit) provides the ability to specify a range
   of addresses and the associated Prefix-SIDs.  In fact, then the R bit
   allows to specify the first address, the number of addresses that
   need to be mapped into a Prefix-SID and the starting value of the
   Prefix-SID range.

   Therefore, with the R bit set, the following encoding is used:
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Type        |     Length    |             Flags             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        First Masklength and Prefix #1 (variable length)       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        First Prefix-SID #1 (4 octets)                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Range Size #1          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                              ...                              |
                                    ...
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        First Masklength and Prefix #n (variable length)       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        First Prefix-SID #n (4 octets)                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Range Size #n          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   For example, if the following router addresses (loopback addresses)
   need to be mapped into the corresponding Prefix-SIDs:
   Router-A: 192.0.2.1/32, Prefix-SID: 1001
   Router-B: 192.0.2.2/32, Prefix-SID: 1002
   Router-C: 192.0.2.3/32, Prefix-SID: 1003
   Router-D: 192.0.2.4/32, Prefix-SID: 1004

   The R-bit allows the following encoding:

Previdi, et al.         Expires December 30, 2013              [Page 16]
Internet-Draft    IS-IS Extensions for Segment Routing         June 2013

   First Masklength and Prefix:
        1 octet of length with value: 32
        4 octets of prefix with value: 192.0.2.1

   First Prefix-SID:
        4 octets of Prefix-SID with value: 1001

   Range Size:
        2 octets with value: 4

   The Segment Routing Mapping Server MUST NOT advertise overlapping
   ranges or Prefix-SID mappings.  In case of overlap, the receiver
   SHOULD log an error and ignore the smaller range or the specific
   Prefix-SID mapping which is part of a range.

3.3.  Segment Routing Mirroring Context Sub-TLV (SRMC)

   The SRMC Sub-TLV allows a node (called the mirroring node) to
   advertise its capability to mirror another node (called the mirrored
   node).  The mirroring node is identified by its IPv4/IPv6 address or
   its related Prefix-SID.  The mirroring node advertises in the SRMC
   Sub-TLV the context segment that needs to be used in order to invoke
   its mirroring service for the mirrored node.

   Examples of mirroring services use cases are defined in
   [draft-filsfils-segment-routing-use-cases] and
   [I-D.minto-rsvp-lsp-egress-fast-protection].

   The SRMC Sub-TLV is optional and MAY be present in the Router
   Capability TLV (TLV-242), MAY appear more than once and has following
   format:
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type        |     Length    |          SRMC Flags           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Mirrored Address  (variable)             |

   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Context-SID (4 octets)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   where:

Previdi, et al.         Expires December 30, 2013              [Page 17]
Internet-Draft    IS-IS Extensions for Segment Routing         June 2013

      Type: TBA.

      Length: variable.

      SRMC Flags: 2 octets field of flags.  Following flags are defined:
           0                   1
           0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          |I|V|R|                         |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          where:

         I-flag: IPv4 flag.  If set, the Mirrored Address is an IPv4
         address.

         V-flag: IPv6 flag.  If set, the Mirrored Address is an IPv6
         address.

         R-flag: Segment Routing Identifier.  If set, the Mirrored
         Address is a SID.

         Other bits: MUST be zero when originated and ignored when
         received.

      Mirrored Address: the IPv4 or IPv6 or SID value representing the
      mirrored element.

      Context-SID: 32 bit value of Segment Identifier for the Mirroring
      Service.

4.  IANA Considerations

   TBD

5.  Manageability Considerations

   TBD

6.  Security Considerations

   TBD

Previdi, et al.         Expires December 30, 2013              [Page 18]
Internet-Draft    IS-IS Extensions for Segment Routing         June 2013

7.  Acknowledgements

   We would like to thank Les Ginsberg, Dave Ward, Dan Frost, Stewart
   Bryant, Hannes Gredler, Pierre Francois and Martin Horneffer for
   their contribution to the content of this document.

8.  References

8.1.  Normative References

   [ISO10589]
              International Organization for Standardization,
              "Intermediate system to Intermediate system intra-domain
              routeing information exchange protocol for use in
              conjunction with the protocol for providing the
              connectionless-mode Network Service (ISO 8473)", ISO/
              IEC 10589:2002, Second Edition, Nov 2002.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4206]  Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP)
              Hierarchy with Generalized Multi-Protocol Label Switching
              (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.

   [RFC4971]  Vasseur, JP., Shen, N., and R. Aggarwal, "Intermediate
              System to Intermediate System (IS-IS) Extensions for
              Advertising Router Information", RFC 4971, July 2007.

   [RFC5120]  Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
              Topology (MT) Routing in Intermediate System to
              Intermediate Systems (IS-ISs)", RFC 5120, February 2008.

   [RFC5305]  Li, T. and H. Smit, "IS-IS Extensions for Traffic
              Engineering", RFC 5305, October 2008.

   [RFC5308]  Hopps, C., "Routing IPv6 with IS-IS", RFC 5308,
              October 2008.

   [RFC5311]  McPherson, D., Ginsberg, L., Previdi, S., and M. Shand,
              "Simplified Extension of Link State PDU (LSP) Space for
              IS-IS", RFC 5311, February 2009.

   [RFC5316]  Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in
              Support of Inter-Autonomous System (AS) MPLS and GMPLS
              Traffic Engineering", RFC 5316, December 2008.

Previdi, et al.         Expires December 30, 2013              [Page 19]
Internet-Draft    IS-IS Extensions for Segment Routing         June 2013

   [RFC6119]  Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic
              Engineering in IS-IS", RFC 6119, February 2011.

8.2.  Informative References

   [I-D.minto-rsvp-lsp-egress-fast-protection]
              Jeganathan, J., Gredler, H., and Y. Shen, "RSVP-TE LSP
              egress fast-protection",
              draft-minto-rsvp-lsp-egress-fast-protection-02 (work in
              progress), April 2013.

   [I-D.previdi-filsfils-isis-segment-routing]
              Previdi, S., Filsfils, C., Bashandy, A., Horneffer, M.,
              Decraene, B., Litkowski, S., Milojevic, I., Shakir, R.,
              Ytti, S., Henderickx, W., and J. Tantsura, "Segment
              Routing with IS-IS Routing Protocol",
              draft-previdi-filsfils-isis-segment-routing-02 (work in
              progress), March 2013.

   [draft-filsfils-rtgwg-segment-routing-00]
              Previdi, S. and C. Filsfils, "Segment Routing", May 2013.

   [draft-filsfils-rtgwg-segment-routing-use-cases-00]
              Filsfils, C., "Segment Routing Use Cases", May 2013.

Authors' Addresses

   Stefano Previdi (editor)
   Cisco Systems, Inc.
   Via Del Serafico, 200
   Rome  00142
   Italy

   Email: sprevidi@cisco.com

   Clarence Filsfils
   Cisco Systems, Inc.
   Brussels,
   BE

   Email: cfilsfil@cisco.com

Previdi, et al.         Expires December 30, 2013              [Page 20]
Internet-Draft    IS-IS Extensions for Segment Routing         June 2013

   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

   Rudiger Geib
   Deutsche Telekom
   DE

   Email: Rudiger.Geib@telekom.de

   Igor Milojevic
   Telekom Srbija
   Takovska 2
   Belgrade
   RS

   Email: igormilojevic@telekom.rs

   Rob Shakir
   British Telecom
   London
   UK

   Email: rob.shakir@bt.com

Previdi, et al.         Expires December 30, 2013              [Page 21]
Internet-Draft    IS-IS Extensions for Segment Routing         June 2013

   Saku Ytti
   TDC Oy
   Mechelininkatu 1a
   TDC  00094
   FI

   Email: saku@ytti.fi

   Wim Henderickx
   Alcatel-Lucent
   Copernicuslaan 50
   Antwerp  2018
   BE

   Email: wim.henderickx@alcatel-lucent.com

   Jeff Tantsura
   Ericsson
   300 Holger Way
   San Jose, CA  95134
   US

   Email: Jeff.Tantsura@ericsson.com

Previdi, et al.         Expires December 30, 2013              [Page 22]