Internet DRAFT - draft-filsfils-spring-sr-recursing-info

draft-filsfils-spring-sr-recursing-info







SPRING                                                       C. Filsfils
Internet-Draft                                                S. Previdi
Intended status: Standards Track                               P. Psenak
Expires: December 22, 2017                                   L. Ginsberg
                                                     Cisco Systems, Inc.
                                                           June 20, 2017


                 Segment Routing Recursive Information
               draft-filsfils-spring-sr-recursing-info-05

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

   There are use cases where it is desirable to utilize a SID associated
   with a given node in order to transport traffic destined to different
   local services supported by such node.  This document defines the
   mechanism to do so and illustrates it.

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

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






Filsfils, et al.        Expires December 22, 2017               [Page 1]

Internet-Draft          SR Recursive Information               June 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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Segment Routing Recursing Information (SRRI)  . . . . . . . .   3
   4.  Illustration  . . . . . . . . . . . . . . . . . . . . . . . .   5
     4.1.  Reference Diagram . . . . . . . . . . . . . . . . . . . .   5
     4.2.  Description . . . . . . . . . . . . . . . . . . . . . . .   5
   5.  Benefits  . . . . . . . . . . . . . . . . . . . . . . . . . .   6
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7
   9.  Normative References  . . . . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   Segment Routing (SR) as defined in [I-D.ietf-spring-segment-routing]
   utilizes forwarding instructions called "segments" to direct packets
   through the network.  When an MPLS dataplane is in use Segment
   Identifiers (SIDs) are assigned to prefixes and are associated with a
   specific algorithm.  SIDs may be Local or Global in scope.  When a
   SID has global scope the SID is mapped via the Segment Routing Global
   Block (SRGB) to a node specific label which acts as the forwarding
   instruction.

   There are use cases where it is desirable to utilize a SID associated
   with a node N to transport traffic destined to different local
   services supported by N.  This document defines the mechanism to do
   so and illustrates it.






Filsfils, et al.        Expires December 22, 2017               [Page 2]

Internet-Draft          SR Recursive Information               June 2017


2.  Use Cases

   In some deployments, multiple loopback addresses are configured in a
   single router.  Each of these loopback addresses can serve as the
   address of the node.  Specific addresses within this set of node
   addresses may be used as the endpoint for a particular service or
   capability.  If the number of labeled entries installed in the
   forwarding plane is a concern, the use of a single label for the set
   of node addresses (or for some subset of the set of node addresses)
   can be used in order to reduce the number of forwarding entries
   required to reach any of the node addresses.  This, in turn, would
   require sharing of a SID among multiple prefixes.

   Some deployments attach different services to an edge router in a
   network via unique interfaces.  Rather than assigning a unique SID
   for the address associated with each service the desired behavior is
   to use a Node-SID to reach the edge router and then utilize a service
   specific Local SID to direct the packet to the correct service.

   The first use case is a sub-case of the second one where the local
   SID is not present (e.g. encoded as implicit-null).  Hence in the
   remainder of this document, we will focus on the more generic use
   case, i.e., utilizing a single Node-SID in combination with an
   optional Local SID to transport traffic up to the node and then have
   the node apply the correct service based on the local SID (if
   present).

3.  Segment Routing Recursing Information (SRRI)

   This document introduces and defines the concept of a "Segment
   Routing Recursing Information (SRRI) that needs to be carried into
   IGPs (ISIS and OSPF), e.g., as a TLV (or SubTLV) attached to the
   prefix advertisement.

   The description in this document is protocol agnostic and can be
   applied to both IGPs (IS-IS and OSPF).  The protocol specific format
   of this advertisement will be defined in protocol specific
   specifications.

   Advertisement of a prefix P with SRRI (R, Alg, SID-L) indicates that
   a remote node M MUST use a segment list {SID(R), SID-L) to transport
   traffic to P; where SID(R) is the prefix SID of R for the specified
   algorithm.  The generic advertisement format is then:








Filsfils, et al.        Expires December 22, 2017               [Page 3]

Internet-Draft          SR Recursive Information               June 2017


   IPv4 SRRI

          +-----------------------+
          | Flags                 | 1 byte
          +-----------------------+
          | Algorithm             | 1 byte
          +-----------------------+
          | Recursing SID Address | 4 bytes
          +-----------------------+
          | Local SID             | 4 bytes (optional)
          +-----------------------+

   IPv6 SRRI

          +-----------------------+
          | Flags                 | 1 byte
          +-----------------------+
          | Algorithm             | 1 byte
          +-----------------------+
          | Recursing SID Address | 16 bytes
          +-----------------------+
          | Local SID             | 4 bytes (optional)
          +-----------------------+

   where:

   o  "Flags" is one byte field of flags.  Only one flag is currently
      defined: the V-flag.  If set, the receiver of the SRRI MUST verify
      that the originator of the prefix the SRRI is attached to and the
      prefix covering the Recursing SID address are originated by the
      same node ("same origin node").

   o  "Algorithm" defines the algorithm related to the prefix
      reachability as defined in [I-D.ietf-spring-segment-routing].

   o  "Recursing SID Address" contains an IPv4 or IPv6 address whose
      Node-SID is to be used in order to reach the prefix with which the
      SRRI information is associated.

   o  "Local SID" is the local SID allocated to the prefix the SRRI is
      attached to.

   The SRRI is associated with a prefix reachability advertisement.  The
   manner of this association is protocol specific.

   The following apply to the SRRI:





Filsfils, et al.        Expires December 22, 2017               [Page 4]

Internet-Draft          SR Recursive Information               June 2017


   o  The prefix reachability advertisement this SRRI is attached to
      MUST NOT have a Prefix-SID assigned for the algorithm specified in
      the SRRI.

   o  Multiple "Recursing SID Address" and "Local SID" MAY be associated
      with the same parent prefix.

4.  Illustration

4.1.  Reference Diagram

   The following reference topology diagram is used:

         A----B----D
          \    \  /
           \    \/
            \   /\
             \ /  \
              C----E

       |------|------|
         Area   Area
          0      1

      A is in Area 0
      B and C are ABRs
      D and E are in Area 1

      D has a loopback 1.0.0.4/32 and Node SID 16004
      D has a local service 1.0.0.99/32 with Local SID 30004
      E has a loopback 1.0.0.5/32 and Node SID 16005
      E has a local service 1.0.0.99/32 with Local SID 30005

   For simplicity, we abstracted the algorithm variable in the SRRI and
   process.

4.2.  Description

   D advertises prefix 1.0.0.99/32 with SRRI (1.0.0.4, 30004, V=1)

   B receives the 1.0.0.99/32 prefix advertisement from D.  Since the
   V-flag is set, B MUST confirm that D also originates the "Recursing
   SID address" 1.0.0.4/32 (i.e.: "same origin node").

   If same origin node is not confirmed, then B does not install any SR
   RIB entry for prefix 1.0.0.99/32.  If same origin node is confirmed,
   B installs an SR RIB entry for 1.0.0.99/32 which uses the segment
   list {16004, 30004} and the OIF to 16004.



Filsfils, et al.        Expires December 22, 2017               [Page 5]

Internet-Draft          SR Recursive Information               June 2017


   Furthermore, B leaks the prefix in area 0 and advertises it with the
   SRRI (1.0.0.4, 30004, V=0).  The V-flag unset indicates that area 0
   nodes do not need to perform the "same origin node" check.

   E advertises prefix 1.0.0.99/32 with the SRRI (1.0.0.5, 30005, V=1)

   B does the same for the route from E as he did for the route from D.

   Specifically, let us highlight two elements:

   o  First, B ends up with an ECMP SR-based RIB entry to 1.0.0.99/32:

   - {16004, 30004} OIF to 16004
   - {16005, 30005} OIF to 16005

   o  Second, B advertises 1.0.0.99/32 in area 0 with two SRRI's:

   - (1.0.0.4, 30004, V=0)
   - (1.0.0.5, 30005, V=0)

   C does the same for the routes from D and E.  Briefly, C advertises
   1.0.0.99/32 in area 0 with two SRRI's:

   - (1.0.0.4, 30004, V=0)
   - (1.0.0.5, 30005, V=0)

   A learns 1.0.0.99/32 from B and C and uses normal IGP process to
   select one, the other or both.

   Let us assume A prefers the path via B.

   A receives the 1.0.0.99/32 prefix advertisement from B.  Since the
   V-flag is unset, no "same origin node" is verified.  A installs an SR
   RIB entry for 1.0.0.99/32 with an ECMP set of path:

   path 1 is {16004, 30004} and the OIF to 16004
   path 2 is {16005, 30005} and the OIF to 16005

5.  Benefits

   The mechanism and SR Recursive Information defined in this document
   supports:

   o  single-area and multi-area deployments.

   o  single-homed and multi-homed prefixes.

   o  the presence of a Local-SID or not.



Filsfils, et al.        Expires December 22, 2017               [Page 6]

Internet-Draft          SR Recursive Information               June 2017


   o  Any combination of the above.

   The Segment Routing Recursive Information minimize the number of
   global prefix SID's.

   Finally, the Segment Routing Recursive Information is consistent with
   the MPLS FIB structure: different FEC's have different entries.

6.  IANA Considerations

   This document doesn't introduce any new code-point.

7.  Security Considerations

   TBD

8.  Acknowledgements

   We would like to thank Les Ginsberg and Ahmed Bashandy for their
   contributions.

9.  Normative References

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

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

Authors' Addresses

   Clarence Filsfils
   Cisco Systems, Inc.
   Brussels
   BE

   Email: cfilsfil@cisco.com









Filsfils, et al.        Expires December 22, 2017               [Page 7]

Internet-Draft          SR Recursive Information               June 2017


   Stefano Previdi
   Cisco Systems, Inc.
   Italy

   Email: stefano@previdi.net


   Peter Psenak
   Cisco Systems, Inc.
   Apollo Business Center
   Mlynske nivy 43
   Bratislava  821 09
   Slovakia

   Email: ppsenak@cisco.com


   Les Ginsberg
   Cisco Systems, Inc.
   US

   Email: ginsberg@cisco.com





























Filsfils, et al.        Expires December 22, 2017               [Page 8]