Internet DRAFT - draft-geib-spring-te-discussion

draft-geib-spring-te-discussion



spring                                                      R. Geib, Ed.
Internet-Draft                                              M. Horneffer
Intended status: Informational                          Deutsche Telekom
Expires: April 20, 2015                                     S. Schnitter
                                                                 Detecon
                                                              M. Franzke
                                                        Deutsche Telekom
                                                        October 17, 2014


 Requirements and approaches to combine Traffic Engineering and Segment
                                Routing
                 draft-geib-spring-te-discussion-00.txt

Abstract

   MPLS Traffic engineering heavily relies on the correct simulation of
   traffic under normal and failure conditions.  Currently traffic
   simulations rely on RSVP TE or on SPF routing with ECMP.  SR
   introduces basically a new overlay on top of the L3 topology, the SR
   topology.  The SR-topology is demand dependant.  This document
   discusses issues, requirements and some solution approaches to
   combine Segment Routing and Traffic Engineering.

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 April 20, 2015.

Copyright Notice

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



Geib, et al.             Expires April 20, 2015                 [Page 1]


Internet-Draft              SR TE approaches                October 2014


   (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.  Traffic Engineering requirements  . . . . . . . . . . . . . .   3
     2.1.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.2.  Traffic Matrix Requirements . . . . . . . . . . . . . . .   3
     2.3.  LDP based Traffic Matrix Measurement  . . . . . . . . . .   4
   3.  Solution approaches . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Approach 1: Double Label operation  . . . . . . . . . . .   4
     3.2.  Approach 2: A Top Label always identifying the
           destination . . . . . . . . . . . . . . . . . . . . . . .   7
   4.  Standardized QoS counters . . . . . . . . . . . . . . . . . .   8
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   7.  Acknowledgement . . . . . . . . . . . . . . . . . . . . . . .   8
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   Traffic engineering heavily relies on the correct simulation of
   traffic under normal and failure conditions.  Correct simulation
   means that the simulated network utilization of the traffic matrix is
   the same as the measured load.  Currently traffic simulations rely on
   RSVP TE or on SPF routing with ECMP.  SR introduces basically a new
   overlay on top of the L3 topology, the SR topology.  The SR-topology
   is demand dependant.  Edges of the SR-topology are not used for all
   demands.

   As basic input for traffic engineering use cases operators need to
   measure end-to-end traffic matrices and it is common that they use
   MPLS based traffic statistics for this, e.g.  LDP statistics of the
   label swap actions [tr_mat].  With the Introduction of the segment
   routing [ID.sr-req], [ID.sr-arch], these mechanisms should continue
   to work.  The present document describes requirements and solution
   options of some approaches combining Segment Routing and Traffic
   Engineering.




Geib, et al.             Expires April 20, 2015                 [Page 2]


Internet-Draft              SR TE approaches                October 2014


   To start a discussion how to combine Segment Routing and Traffic
   Engineering in MPLS networks, this document is focused on the
   simplest case of a two label Segment stack.

   In general two different Label values are assumed for the typical SR
   based traffic engineering scenario: One label identifies the end-to-
   end traffic matrix or destination and one label identifies the
   intermediate traffic engineering segment or a path deviating from SPF
   routing (or ECMP path selection).

   The solution pursued should integrate smoothly with routing (i.e. not
   require serious configuration effort).  Further, the core MPLS
   network must remain BGP free.

   For the sake of simplicity, we assume a global label space where a
   single global label identifies a single Node Segment in the
   following.

2.  Traffic Engineering requirements

2.1.  Use Cases

   Out of many possible use cases for segment routing the following
   three are currently considered most relevant

   o  A and B plane selection: Use anycast segments on ingress A or
      B-plane routers that can be used for traffic that requires strict
      A or B plane routing (like Sigtran traffic)

   o  Link group selection: Use anycast segments on routers defining a
      certain set of links that shall be used for certain part of the
      traffic, e.g. to force voice/delay sensitive traffic via a
      geographically shorter route from Europe to Asia.

   o  Intermediate node selection: Enforce the use of a particular route
      for traffic for traffic engineering reasons that cannot be modeled
      with IGP based traffic engineering (in normal or failure case,
      potentially only on demand in specific failure situations).

2.2.  Traffic Matrix Requirements

   With segment routing the need for IP traffic matrices becomes more
   complex.  With SR, two type of IP traffic matrices are needed in
   order to carry out the traffic engineering tasks that operators have
   introduced (without SR they are the same):

   o  End-to-End traffic matrix: Traffic matrix of end-to-end demands in
      the IP-MPLS network.  The end-to-end traffic matrix contains the



Geib, et al.             Expires April 20, 2015                 [Page 3]


Internet-Draft              SR TE approaches                October 2014


      traffic levels (e.g. 5 min or 15 min average traffic level)
      between the entry and final exit routers.  End-to-end traffic
      matrices are needed for network planning and global traffic
      engineering optimizations.

   o  Segment traffic matrix: Traffic matrix of segmented demands using
      the configured segments.  The segment traffic matrix is needed for
      correct traffic simulations (normal and failure cases) based on
      the IP topology and configured segments as well as for incremental
      traffic engineering optimizations.

2.3.  LDP based Traffic Matrix Measurement

   LDP statistics in current router implementations provide a useful
   tool for both path and traffic discovery in MPLS networks today.  The
   following mechanisms of LDP statistics are used in operator networks
   today:

   o  Number of bytes transferred per (X-to-Y) label swap operation per
      outgoing interface and tracing of traffic path to sink.

   o  Detection of the sink (end of path) within the topology under
      consideration if the outgoing interface points to a router not
      included in the topology.

   o  Detection of source traffic (in contrast to transit traffic)
      through algorithmic operation: Add traffic to the entry (N,S) of
      the traffic matrix.  (if N is the current router under
      consideration and S the identified sink of the traffic in this
      forwarding equivalence class (FEC) ) and subtract the traffic from
      the entry (N+1,S), if N+1 is the next router on the path towards
      S.

   o  Measurement of ECMP split level based on label swap statistic per
      multiple outgoing interfaces.

3.  Solution approaches

3.1.  Approach 1: Double Label operation

   As we have discussed we need two different values for the typical
   traffic engineering scenario: One for the end-to-end traffic matrix
   and one for the intermediate traffic engineering segment.

   In this proposed solution we suggest to achieve this by replacing the
   typical swap MPLS operations by a double-pop-double-push operation,
   which could also be considered a pop-swap-push operation.  Also the
   pop operation normally executed at the end of the traffic engineering



Geib, et al.             Expires April 20, 2015                 [Page 4]


Internet-Draft              SR TE approaches                October 2014


   segment would be replaced by a pop-swap operation.  An example
   operation is illustrated by figure 1, where the following signs and
   symbols are used:


                      +------+
Router with Id R101:  | R101 |
                      +------+

MPLS byte counter:                              MPLS label stack,
+----------------+                              different frame
|R101 Counter    |                              characters denote
| In|Out|Byte| If|                              different flows:
+---+---+----+---+                              #####  %%%%%
|105|pop|4321|3/1|                              #103#  %103%
+---+---+----+---+                              #106#  %105%
|106|106|1234|3/1|                              # IP#  % IP%
+---+---+----+---+                              #####  %%%%%

+----------------+         +----------------+   +----------------+
|R107 Counter    |         |R103 Counter    |   |R105 Counter    |
| In|Out|Byte| If|         | In|Out|Byte| If|   | In|Out|Byte| If|
+---+---+----+---+         +---+---+----+---+   +---+---+----+---+
|103|103|   0|7/1|         |105|pop|4321|3/1|   |106|pop|4321|5/1|
|105|105|    |   |         +---+---+----+---+   +---+---+----+---+
+---+---+----+---+         |106|106|1234|3/1|   |   |    |   |   |
|103|103|1234|7/1|         +---+---+----+---+   +---+---+----+---+
|106|106|    |   |
+---+---+----+---+
          #####
          #103#            %%%%%
          #106#      ##### %105%         #####
          # IP#      #106# % IP%         #106#
          #####      # IP# %%%%%         # IP# %%%%%
+------+             #####      +------+ ##### % IP%     #####
| R107 |__                    __| R103 |__     %%%%%     # IP#
+------+  \__ 7/1       2/1__/  +------+  \__3/1         #####
             \__+------+__/                  \__+------+ 5/1    +------+
              __| R102 |__                    __| R105 |--------| R106 |
+------+   __/  +------+  \__   +------+   __/  +------+        +------+
| R101 |__/   1/1       2/2  \__| R104 |__/  4/1
+------+                        +------+
          %%%%%
          %103%
          %105%
          % IP%
          %%%%%




Geib, et al.             Expires April 20, 2015                 [Page 5]


Internet-Draft              SR TE approaches                October 2014


+----------------+    +----------------+
|R101 Counter    |    |R102 Counter    |
| In|Out|Byte| If|    | In|Out|Byte| If|
+---+---+----+---+    +---+---+----+---+
|103|103|4321|1/1|    |103|pop|4321|2/1|
|105|105|    |   |    |105|105|    |   |
+---+---+----+---+    +---+---+----+---+
|103|103|   0|1/1|    |103|pop|1234|2/1|
|106|106|    |   |    |106|106|    |   |
+---+---+----+---+    +---+---+----+---+


   Double label operation

                                 Figure 1

   Consider a typical LSR such as R101 in figure 1:

   o  The transport label of 103 would just be swapped against 103.  The
      associated traffic counter would only count traffic of the
      aggregated traffic engineering segment.

   o  We suggest that instead the lookup of label 103 would lead to the
      command to do another lookup of the following label.  In this
      case, that could be 105 or 106.  In both cases the resulting
      action would be to push two labels - 105 (or 106 respectively) and
      103.  An equivalent implementation would be to swap 105 against
      105 and push 103 again.  An entry to count bytes for this
      operation shall be contained in the MPLS forwarding table.

   o  A plain label of 105 as top label, i.e. the final destination
      without an additional traffic engineering segment, does need a
      separate entry in the MPLS forwarding table, and consequently a
      separate counter.

   Consider an LSR at the end of a traffic engineering segment such as
   R102:

   o  Normally label 103 would just be popped and the remainder of the
      packet would be forwarded.  Only the aggregated traffic of the
      traffic engineering segment would be counted.

   o  We suggest that instead the lookup of label 103 would lead to the
      command to do another lookup of the following label.  The
      resulting action for both label 105 and 106 would be to swap this
      one against the same number just before forwarding the packet.
      (Or pop the second label and push it again.)




Geib, et al.             Expires April 20, 2015                 [Page 6]


Internet-Draft              SR TE approaches                October 2014


   The result would be to have two different counters for all the
   traffic of segment 103 - one for each final destination.  The traffic
   of traffic engineering segment 103 itself can be derived by adding
   both counters.

   This can be generalized to any number of final destination and any
   number of traffic engineering segments.  The number of entries in the
   MPLS forwarding table and counters would be equivalent to the number
   of final destinations multiplied by the number of segment routing
   segments.

   We strongly recommend to limit the amount of additional paths (or
   labels respectively) for traffic engineering purposes to one.
   Otherwise even more labels would have to be inspected and the number
   of entries in the MPLS forwarding tables would explode.  This
   limitation seems quite reasonable for all scenarios and use-cases we
   have seen so far.  Also we recommend to limit the use of the relevant
   type of traffic engineering tunnels.  It should be the responsibility
   of the network operator to know about the scalability of their LSR
   devices with respect to the possible size of the forwarding table,
   and to limit the configured traffic engineering segments accordingly.
   It must be possible for the operator to indicate to the routers which
   segments are eligible as traffic engineering segments that are
   treated in the way described above.

3.2.  Approach 2: A Top Label always identifying the destination

   This may be a new routing paradigm rather than a Segment Routing TE
   solution approach.  The idea is inspired by ECMP: While the top label
   identifies the destination of a packet, the specific path the packet
   takes depends on information below the top label.  In todays
   environments, ECMP is a hash based random method working within Equal
   Cost SPF routes.

   The idea is, to generalize this method.  The top label identifies the
   destination.  The address information below the top label determines
   the path deterministically.  This could be a particular SPF path, if
   the route is SPF based.  This could be a non SPF path in other cases.

   Capturing the traffic matrix is simple in this case.  If the top
   label always identifies the destination, the label stack below may be
   deeper.  The second label may be called path selector or key label.
   A specific value of this second label may indicate that the packet
   should execute a specific SPF path or a non SPF path.  If the key
   label is missing, standard SPF routing including ECMP should be
   executed.  ECMP may be applicable within a route set deviating from
   standard SPF, if the key label is present.




Geib, et al.             Expires April 20, 2015                 [Page 7]


Internet-Draft              SR TE approaches                October 2014


   This approach is optimistically a research topic.  It has decent
   properties though, thats why considering it might be worthwhile.

4.  Standardized QoS counters

   QoS aware MPLS traffic engineering requires to capture QoS
   differentiating traffic matrices.  This draft does not suggest a
   specific granularity above the basic one of a single load counter per
   MPLS Ordered Aggregate on a physical interface.  So far, only the MIB
   II interface counter captures a largely standardized packet size on
   Ethernet interfaces [RFC1213].  In analogy, the total number of
   octets received on the interface which are classified for a
   particular QoS class, including framing characters, should be
   captured.  The interpretation of framing characters should be non
   ambiguous (it should e.g. be clear whether CRC bytes are part of the
   Layer 2 frame or not).  To support QoS aware traffic engineering (and
   other purposes like billing at IP interfaces, configuration of
   policers and schedulers), the packet length captured by a QoS aware
   counter per MPLS Ordered Aggregate must be standardized.  Counters
   with proprietary QoS packet length definitions may be dealt with if
   the captured packet size is known and the number of packets per QoS
   class is captured in parallel.  This requires additional counters and
   additional operational overhead however.

5.  IANA Considerations

   This memo includes no request to IANA.

6.  Security Considerations

   A security discussion should be added in a later version.

7.  Acknowledgement

   Fabian Perko provided reviews of this draft.

8.  References

8.1.  Normative References

   [RFC1213]  McCloghrie, K. and M. Rose, "Management Information Base
              for Network Management of TCP/IP-based internets:MIB-II",
              STD 17, RFC 1213, March 1991.








Geib, et al.             Expires April 20, 2015                 [Page 8]


Internet-Draft              SR TE approaches                October 2014


8.2.  Informative References

   [ID.sr-arch]
              IETF, "Segment Routing Architecture", IETF,
              https://datatracker.ietf.org/doc/draft-filsfils-spring-
              segment-routing/, 2014.

   [ID.sr-req]
              IETF, "SPRING Problem Statement and Requirements", IETF,
              http://datatracker.ietf.org/doc/
              draft-ietf-spring-problem-statement/, 2014.

   [tr_mat]   Schnitter, S. and M. Horneffer, "Traffic matrices for MPLS
              networks with LDP traffic statistics", 2004.

Authors' Addresses

   Ruediger Geib (editor)
   Deutsche Telekom
   Heinrich Hertz Str. 3-7
   Darmstadt  64295
   Germany

   Phone: +49 6151 5812747
   Email: Ruediger.Geib@telekom.de


   Martin Horneffer
   Deutsche Telekom
   Dahlweg 100
   Muenster  48153
   Germany

   Phone: +49 251 788773788
   Email: Martin.Horneffer@telekom.de


   Stefan Schnitter
   Detecon
   Oberkasseler Str. 2
   Bonn  53227
   Germany

   Phone: +49 221 91612968
   Email: Stefan.Schnitter@detecon.com






Geib, et al.             Expires April 20, 2015                 [Page 9]


Internet-Draft              SR TE approaches                October 2014


   Martin Franzke
   Deutsche Telekom
   Deutsche-Telekom-Allee 7
   Darmstadt  64295
   Germany

   Phone: +49 6151 5833097
   Email: Martin.Franzke@telekom.de











































Geib, et al.             Expires April 20, 2015                [Page 10]