Internet DRAFT - draft-hegde-spring-traffic-accounting-for-sr-paths

draft-hegde-spring-traffic-accounting-for-sr-paths







SPRING WG                                                       S. Hegde
Internet-Draft                                    Juniper Networks, Inc.
Intended status: Standards Track                        October 17, 2018
Expires: April 20, 2019


           Traffic Accounting for MPLS Segment Routing Paths
         draft-hegde-spring-traffic-accounting-for-sr-paths-02

Abstract

   Traffic statistics form an important part of operations and
   maintenance data that are used to create demand matrices and for
   capacity planning in networks.  Segment Routing (SR) is a source
   routing paradigm that uses stack of labels to represent a path.  The
   SR path specific state is not stored in any other node in the network
   except the head-end node of the SR path.  Traffic statistics specific
   to each SR path are an important component of the data which helps
   the controllers to lay out the SR paths in a way that optimizes the
   use of network resources.  SR paths are inherently ECMP aware.

   As SR paths do not have state in the core of the network, it is not
   possible to collect the SR path traffic statistics accurately on each
   interface.  This document describes an MPLS forwarding plane
   mechanism to identify the SR path to which a packet belongs and so
   facilitate accounting of traffic for MPLS SR paths.

   The mechanisms described in this document may also be applied to
   other MPLS paths (i.e., Label Switched Paths) and can be used to
   track traffic statistics in multipoint-to-point environments such as
   those where LDP is in use.

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 https://datatracker.ietf.org/drafts/current/.




Hegde                    Expires April 20, 2019                 [Page 1]

Internet-Draft       Traffic accounting for SR-Paths        October 2018


   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, 2019.

Copyright Notice

   Copyright (c) 2018 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
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Motivation  . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  SR-Path Identifier  . . . . . . . . . . . . . . . . . . . . .   5
     4.1.  Centrally Managed SR Paths  . . . . . . . . . . . . . . .   5
     4.2.  Locally Managed SR Paths  . . . . . . . . . . . . . . . .   5
   5.  Use of the SR-Path-Identifier and Source-SID  . . . . . . . .   6
   6.  Inserting the SR-Path-Identifier in Packets . . . . . . . . .   7
   7.  Traffic-Accounting for Sub SR-Paths in the Network  . . . . .   8
   8.  Forwarding Plane Procedures . . . . . . . . . . . . . . . . .   8
   9.  Consideration of Protection Mechanisms  . . . . . . . . . . .  10
   10. Backward Compatibility  . . . . . . . . . . . . . . . . . . .  10
   11. Scalability Considerations  . . . . . . . . . . . . . . . . .  11
   12. Security Considerations . . . . . . . . . . . . . . . . . . .  11
   13. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   14. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  12
   15. Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  12
   16. References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     16.1.  Normative References . . . . . . . . . . . . . . . . . .  12
     16.2.  Informative References . . . . . . . . . . . . . . . . .  13
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  14






Hegde                    Expires April 20, 2019                 [Page 2]

Internet-Draft       Traffic accounting for SR-Paths        October 2018


1.  Introduction

   Figure 1 describes an SR enabled network with Node-SIDs and Anycast-
   SIDs assigned.  The SR-Paths with label stacks are as shown in the
   diagram.  The SR-Paths are created (possibly by a central controller)
   so as to maximize the network resource utilization such as bandwidth.
   Based on the traffic carried by the SR-Paths, they need to be re-
   routed occasionally to balance the bandwidth utilization.  SR-Paths
   are inherently ECMP aware.

   For example, SR-Path3 in the diagram is balanced across equal cost
   paths B->C->D and B->G->D.  When there is congestion on the link
   between B and C, the SR path causing the congestion needs to be
   identified and re-routed.  SR paths do not have separate control or
   forwarding state in any node other than the head-end.  Traffic
   measurement at the head-end node is insufficient to determine the
   contribution of each SR path to the congestion on the link because of
   ECMP or Weighted ECMP balancing.

   Per-SID traffic measurement on every interface gives some informtion
   about the traffic carried, but is not sufficient to correctly measure
   traffic carried by each SR path on the link.  If it were possible to
   identify to which SR path each packet belonged, that information
   could be used by an external entity to re-route the SR paths to
   maximize resource utilization.

   As SR paths do not have state in the core of the network, it is not
   possible to collect the SR path traffic statistics accurately on each
   interface.  This document describes an MPLS forwarding plane
   mechanism to identify the SR path to which a packet belongs and so
   facilitate accounting of traffic for MPLS SR paths.

   The mechanisms described in this document may also be applied to
   other MPLS paths (i.e., Label Switched Paths) and can be used to
   track traffic statistics in multipoint-to-point environments such as
   those where LDP is in use.















Hegde                    Expires April 20, 2019                 [Page 3]

Internet-Draft       Traffic accounting for SR-Paths        October 2018


                         Anycast-SID:100
      SID:10    SID:20   SID:30          SID:40    SID:50
      +----+    +----+   +----+          +----+    +----+
      | A  |----| B  |---| C  |----------| D  |----| E  |
      +----+    +----+   +----+          +----+    +----+
                 /  \     |               /
                /    \    |              /
               /      \   |             /
          +----+      +----+           /
          | F  |      | G  |-----------
          +----+      +----+
          SID:60      SID:70
                      Anycast-SID:100

       SRGB: 1000-2000 on all routers
       SR-Path1: A-> 1020,1030
       SR-Path2: A-> 1020,1100,1040
       SR-Path3: F-> 1020,1040
       SR-Path4: A-> 1020,1040,1060


                         Figure 1: Sample Network

2.  Motivation

   The motivation of this document is to provide a solution to enable
   traffic measurement statistics per SR-Path on any node and any link
   in the network.  The objectives listed below help to achieve the
   requirements in a variety of deployments.

   1.  The control plane MUST be free of any per SR path state.

   2.  The forwarding plane MUST be free of any per SR path state.

   3.  The number of counters created to measure traffic SHOULD be
       optimized.

   4.  The additional information carried in each packet SHOULD be
       minimized.

   5.  The mechanism SHOULD be applicable to all MPLS environments.

3.  Terminology

   Source-SID:  The (globally unique) Node-SID of the head-end node
      which places traffic on the SR path.  This is a 20 bit number
      excluding 0-15 and may be encoded in an MPLS label field.




Hegde                    Expires April 20, 2019                 [Page 4]

Internet-Draft       Traffic accounting for SR-Paths        October 2018


   SR-Path-Identifier:  An SR-Path-Identifier is an identifier for each
      SR path in the network.  It is unique within the scope of the node
      that allocated the identifier.  If the identifier is allocated by
      the head-end node (the source) the combination of Source-SID and
      SR-Path Identifier uniquely identifies an SR path within a
      network.  If the identifier is allocated by a central controller
      then the SR-Path Identifier is network unique.  The SR-Path
      Identifier is a 19 bit number excluding the values 0-15 and may be
      encoded in an MPLS label field.  See Section 4.

   SR-Path-Indicator:  The SR-Path-Indicator is an MPLS Special Purpose
      Label [RFC7274].  This label indicates the presence of an SR-Path
      Identifier and an Source Node-SID encoded in MPLS label stack
      entries and situated immediately below this label stack entry in
      the label stack.

   SR-Path-Stats Labels:  The SR-Path-Indicator, SR-Path-Identifier, and
      Source-SID together are termed as the SR-Path-Stats Labels.

4.  SR-Path Identifier

4.1.  Centrally Managed SR Paths

   In controller-based deployments, a controller creates an SR policy,
   associates a segment list and a Binding SID to the policy, and sends
   it to the head-end of the SR path as described in
   [I-D.filsfils-spring-segment-routing-policy].  The controller may
   also allocate a network-unique SR-Path-Identifier and send it to the
   head-end along with the policy.  When the head-end node receives this
   policy, if it has not been supplied with an SR-Path-Identifier, it
   creates a locally-unique identifier for each the SR path network and
   associates it with SR-TE Policy and advertizes it back to the
   controller using mechanisms described in
   [I-D.ietf-idr-te-lsp-distribution].

   The SR-Path-Identifier is used for the purpose of traffic accounting
   as described in Section 5.

4.2.  Locally Managed SR Paths

   Deployments which do not use a central controller for managing the
   network configure locally manage SR-Paths on the head-end router.
   Every SR path in the network is identified using a Source-SID and a
   source-unique SR-Path-Identifier.  The head-end node generates the
   SR-Path-Identifier for each SR path and associates it with the SR
   path.  An Operator MAY also configure 19-bit globally unique
   Identifiers on each SR-Path and use it for accounting traffic as
   described in Section 5



Hegde                    Expires April 20, 2019                 [Page 5]

Internet-Draft       Traffic accounting for SR-Paths        October 2018


5.  Use of the SR-Path-Identifier and Source-SID

   The SR-Path-Identifier is a 19 bit number created by the head-end
   node as described in Section 4.  The SR-Path-Identifier and Source-
   SID are inserted in the packet below a Special Purpose Label called
   the SR-Path-Indicator.  The three values are each carried in a label
   stack entry as shown in Figure 2.


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          SR-Path-Indicator            | TC  |S|       TTL     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |C|        SR-Path-Identifier           | TC  |S|       TTL     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Source-SID                   | TC  |S|       TTL     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


     Figure 2: The SR-Path-Stats Labels Encoded in Label Stack Entries

   The SR-Path-Indicator label value is TBD-1 to be assigned by IANA.

   The SR-Path-Indicator label indicates that the MPLS label stack
   entries that follow carry an identifier of SR path.  These label
   stack entries MUST NOT be used for forwarding, and if they are
   encountered at the top of the label stack (for example, at the egress
   node) they MUST be stripped.

   The SR-Path-Identifier label stack entry is inserted immediately
   below the SR-Path-Indicator.  The label field contains two elements:

   o  The C-flag indicates whether the SR-Path-Identifier is allocated
      by a central controller or not.  If the C-flag is set (one) then
      this indicates that the SR-Path-Identifier was allocated by a
      central controller and has global scope, and that a Source-SID is
      not included.  If the C-flag is clear (zero) then the SR-Path-
      Identifier is scoped by the Source-SID that is included after the
      SR-Path-Identifier.

   o  The SR-Path-Identifier identifies the SR path as described in
      Section 4.

   The Source-SID is inserted immediately below the SR-Path-Identifier
   and is present only if indicated by the setting of the C-flag in the
   SR-Path-Identifier label stack entry.  If present the Source-SID




Hegde                    Expires April 20, 2019                 [Page 6]

Internet-Draft       Traffic accounting for SR-Paths        October 2018


   gives scope to the SR-Path-Identifier.  The Source-SID is described
   in Section 4.

   An intermediate node in the network can look into the packet and
   account the traffic based on the SR-Path-Identifier and Source-SID.

   Because it is necessary that the SR-Path-Stats labels are removed
   when they are found at the top of the label stack, the node imposing
   the label stack (the ingress) must know which nodes are capable of
   stripping the labels.  This ability is advertised in IGP
   advertisements defined in TBD and TBD.

6.  Inserting the SR-Path-Identifier in Packets

   The SR-Path-Identifier and Source-SID are used as a key to account
   the SR path traffic.  The forwarding plane entities should look up
   the SR-Path-Identifier and Source-SID (if present) values to account
   the traffic against the right path counters.

   The SR-Path-Stats Labels are normally placed at the bottom of the
   label stack.

   Forwarding hardware may have limitations and not support accessing
   the label stack beyond certain depth.  In such cases, the hardware
   will not be able to find the SR-Path-Stats Labels at the bottom of
   the label stack if the stack is too deep.  To support traffic
   accounting in such cases it is necessary to insert the SR-Path-Stats
   Labels within the Readable Label Stack Depth Capability (RLDC) of the
   nodes in the SR path.  The extensions defined in
   [I-D.ietf-ospf-segment-routing-msd] and
   [I-D.ietf-isis-segment-routing-msd] describe how the MSD supported by
   each node is advertised.  The head-end node SHOULD insert the SR-
   Path-Stats Labels at a depth in the label stack such that the nodes
   in the SR path can access the SR-Path-Identifier for accounting.  The
   SR-Path-Stats Labels may be present multiple times in the label stack
   of a packet.

   In general, if all the nodes in the network support RLDC which is
   more than the label-stack depth being pushed at the head-end node
   then the SR-Path-Stats Labels SHOULD be pushed at the bottom of the
   label-stack.  If there are service labels to be inserted, they MUST
   be pushed at the bottom of the stack.  If entropy labels [RFC6790]
   are to be inserted they SHOULD be pushed next.  The SR-Path-Stats
   Labels SHOULD be pushed next.

   It is possible to partially deploy this feature when not all the
   nodes in the network support the extensions defined in this document.
   In such scenarios, the special labels MUST NOT get exposed on the top



Hegde                    Expires April 20, 2019                 [Page 7]

Internet-Draft       Traffic accounting for SR-Paths        October 2018


   of the label stack at a node that does not support the extensions
   defined in this document.  This may require multiple blocks of SR-
   Path-Stats Labels to be inserted in the packet header.

   If the egress has not indicated that it is capable of removing the
   SR-Path-Stats Labels, then they MUST NOT be placed at the bottom of
   the label stack.  In this case the SR-Path-Stats Labels SHOULD be
   placed at a point in the label stack such that they will be found at
   the top of stack by the latest node in the SR path that is capable of
   removing them.  In this way, traffic accounting can be performed
   along as much of the SR path as possible.

7.  Traffic-Accounting for Sub SR-Paths in the Network

   SR paths may require large label stacks.  Some hardware platforms do
   not support creating such large label stacks (i.e., imposing a large
   number of labels at once).  To overcome this limitation sub-paths are
   created within the network, and Binding-SIDs are allocated to these
   sub-paths.  When the label representing a Binding-SID is processed it
   is swapped for a stack of labels.  When a head-end node builds the
   label stack for an SR path, it may use these Binding-SIDs to reduce
   the depth of the label stack it has to impose and effectively
   constructs the end-to-end SR path from a series of sub-paths

   The sub-paths are not accounted separately.  Accounting is performed
   on the end-to-end SR paths.  However, edge routers MAY create
   Binding-SIDs for BGP-SR-TE Policies as described in
   [I-D.ietf-idr-segment-routing-te-policy].  Traffic accounting for the
   traffic carried on the SR paths indicated by these Binding-SIDs can
   be done separately by allocating separate SR-Path-Identifiers for
   these sub-paths.

8.  Forwarding Plane Procedures

   To support per-path traffic accounting, the forwarding plane in a
   router MUST look through the label stack of a packet for the first
   instance of the SR-Path-Indicator.  The label value in the next label
   stack entry is the SR-Path-Identifierand the C-flag indicates whether
   a Source-SID label stack entry is also present.  The label values are
   used as the key for accounting SR path traffic.  If the Source-SID
   label stack entry is absent, an implementation may find it helpful to
   use a mock Source-SID value of zero for accounting purposes.

   The SR-Path-Identifier may be located at different depth in the
   packet based on the RLDC of nodes in the network as described in
   Section 6.  Finding the SR-Path-Identifier in the packet may be a
   costly operation and MUST NOT be done unless if SR path accounting is
   enabled on the device.  Implementations MUST include a device-wide



Hegde                    Expires April 20, 2019                 [Page 8]

Internet-Draft       Traffic accounting for SR-Paths        October 2018


   configuration option to enable and disable SR path accounting, and
   this option MUST default to "off".  Implementations SHOULD include
   more granular configuration (such as per-interface).

   A further configuration option is to limit the type of packets to
   which the procedures described in this section are applied.  Thus,
   the forwarding plane could be configured to inspect only SR packets,
   or only MPLS packets established using a specific control plane
   technique (such as LDP).  The top label on the incoming packet can be
   used to determine the nature of the packet and whether to search for
   the SR-Path-Identifier.  The SR labels are predictable and are mostly
   assigned from SRGB or SRLB.  If the top label belongs to any of these
   label blocks the procedures described in this section may be applied.
   If the SR label is allocated dynamically as in case of dynamic
   Adjacency-SIDs, it may be difficult to identify whether the label
   belongs to SR.  It is RECOMMENDED to use configured Adjacency-SIDs
   when SR path traffic accounting is enabled.

   If the top label of the incoming packet is of the right type for
   accounting and if other appropriate configuration options are
   enabled, then packet's label stack MUST be examined label by label
   until an SR-Path-Indicator label is found.  The label below SR-Path-
   Indicator label is the SR-Path-Identifier label and the Source-SID
   label follows according to the setting of the C-flag.  The {incoming
   interface, SR-Path-Identifier, Source SID} together are the key for
   traffic accounting.  If the Source-SID label stack entry is absent,
   an implementation may find it helpful to use a mock Source-SID value
   of zero for accounting purposes.

   If a counter does not already exist for that three-tuple, a new
   counter SHOULD be created.  If a counter already exists, it MUST be
   incremented.

   There is no requirement to preemptively create counters for every
   incoming interface and every SID: the counters need only be created,
   when a packet is received with the new SR-Path-identifier.  This will
   significantly reduce the number of counters that need to be
   instantiated as not every interface will receive traffic for any
   particular SR path.

   If the SR-Path-Indicator is the top label in a packet, the SR-Path-
   Stats labels are popped and further processing is based on the
   remaining labels in the label stack.  Implementations MUST make sure
   the traffic accounting is carried out before the SR-Path-Stats labels
   are popped.






Hegde                    Expires April 20, 2019                 [Page 9]

Internet-Draft       Traffic accounting for SR-Paths        October 2018


9.  Consideration of Protection Mechanisms

   SR paths typically consist of one or more Node-SIDs, Adjacency-SIDs,
   Anycast-SIDs, and Binding-SIDs.  A variety of protection mechanisms
   may be in place for these SIDs as described in
   [I-D.ietf-spring-resiliency-use-cases].  When the head-end node
   inserts the SR-Path-Stats labels in the label stack, the place in the
   stack is decided based on whether the node where the special label
   gets exposed is capable of popping those labels.

   When link protection is enabled, the traffic reaches the next-hop
   node before moving to towards the destination.  With link-protection
   enabled, there is no risk of exposing the special labels at a node
   that does not support the extensions.

   When node-protection is enabled, the traffic skips the next-hop node
   and reaches the next-next-hop towards the destination.  In this case
   there is a possibility of special labels getting exposed at a node
   (the Merge Point) that does not support the extensions described in
   this document.  In such cases, the node that receives the packet with
   special label at the top will discard the packet according to the
   processing rules of Section 3.18 of [RFC3031].  When using extensions
   described in this document for traffic accounting and with node-
   protection enabled in the network, it is RECOMMENDED to make sure all
   the nodes in the network support the extension.

10.  Backward Compatibility

   The extensions described in this document are backward compatible.
   Nodes that do not support the extensions defined in this document
   will not account the traffic (they will not search for the SR-Path-
   Indicator), but will forward traffic as normal.

   While inserting the SR-Path-Stats labels, the head-end router MUST
   ensure that the labels are not exposed to the nodes that do not
   support them.  If an error is made such that the SR-Path-Stats labels
   are exposed at the top of the label stack at a node that does not
   support this document then that node will discard the packets
   according to [RFC3031].  While the packets will be black-holed, no
   further harm will be caused to the network, and since this is a
   configuration or implementation error, this is an acceptable
   situation.

   If an appropriate point in the label stack cannot be found for the
   insertion of the SR-Path-Stats labels, the head-end node, head-end
   MUST NOT insert the SR-Path-Stats labels, but SHOULD continue to
   label and transmit data.  Under such circumstances the head-end node




Hegde                    Expires April 20, 2019                [Page 10]

Internet-Draft       Traffic accounting for SR-Paths        October 2018


   SHOULD also log the event.  A head-end or central controller MAY seek
   an alternate SR path that allows traffic accounting.

11.  Scalability Considerations

   The counter space is a limited resource in hardware.  As described in
   Section 8 counters need only be created, when a packet is received
   with the an SR-Path-Identifier.  Furthermore, counters need only be
   maintained where collection of statistics is configured.

   Head-end nodes MUST NOT insert SR-Path-Stats labels by default.
   Careful configuration of which SR paths have statistics collection
   enabled will help to minimize the number of counters that need to be
   maintained at transit nodes.

   Transit nodes that are constrained for the number of counters that
   they can support MAY implement mechanisms that sacrifice some under-
   used counters to create new counters.

   As previously noted, the label stack is a prescious resource itself.
   That means that under some circumstances it is desirable to only use
   two labels in the SR-Path-Stats label sequence rather than three.
   This can be achieved by using a central controller to allocate SR-
   Path-Identifier values and set the C-flag to indicate that no Source-
   SID is used.

   Conversely, in a large network with a central controller the SR-Path-
   Identifier may be a prescious resource.  That is, there may be more
   than 2^19 SR paths that need identifiers to be allocated.  In this
   case, a central controller may use knowledge of label stack depth and
   network node capabilities to allocate SR-Path-Indicators that include
   a Source-SID (set to indicate the controller, itself) where that
   would not cause a problem in the network.

12.  Security Considerations

   As noted in Section 11 the counter space is a limited resource in
   hardware.  This document introduces dynamic creation of counters
   based on packet headers of the incoming packets.  There is the
   possibility that a DOS attack is mounted by requesting new counter
   creation on each packet.  Implementations SHOULD monitor the counter
   space and generate appropriate warnings if the counter space is
   getting exhausted.  Implementations SHOULD control the rate at which
   the counters get created to mitigate DOS attacks.







Hegde                    Expires April 20, 2019                [Page 11]

Internet-Draft       Traffic accounting for SR-Paths        October 2018


13.  IANA Considerations

   IANA maintains a registry called the "Multiprotocol Label Switching
   Architecture (MPLS) Label Values" registry.  IANA is requested to
   make a new assignment from this registry as follows:


    Value | Description         | Reference
   -------+---------------------+-------------
    TBD-1 | SR Path Indicator   | [This.I-D]


14.  Acknowledgements

   Thanks to John Drake, Harish Sitaraman, and Ron Bonica for helpful
   discussions.

15.  Contributors


   Adrian Farrel
   Juniper Networks

   Email: afarrel@juinper.net


16.  References

16.1.  Normative References

   [I-D.ietf-idr-te-lsp-distribution]
              Previdi, S., Talaulikar, K., Dong, J., Chen, M., Gredler,
              H., and J. Tantsura, "Distribution of Traffic Engineering
              (TE) Policies and State using BGP-LS", draft-ietf-idr-te-
              lsp-distribution-09 (work in progress), June 2018.

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

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






Hegde                    Expires April 20, 2019                [Page 12]

Internet-Draft       Traffic accounting for SR-Paths        October 2018


16.2.  Informative References

   [I-D.filsfils-spring-segment-routing-policy]
              Filsfils, C., Sivabalan, S., Hegde, S.,
              daniel.voyer@bell.ca, d., Lin, S., bogdanov@google.com,
              b., Krol, P., Horneffer, M., Steinberg, D., Decraene, B.,
              Litkowski, S., Mattes, P., Ali, Z., Talaulikar, K., Liste,
              J., Clad, F., and K. Raza, "Segment Routing Policy
              Architecture", draft-filsfils-spring-segment-routing-
              policy-06 (work in progress), May 2018.

   [I-D.ietf-idr-segment-routing-te-policy]
              Previdi, S., Filsfils, C., Jain, D., Mattes, P., Rosen,
              E., and S. Lin, "Advertising Segment Routing Policies in
              BGP", draft-ietf-idr-segment-routing-te-policy-04 (work in
              progress), July 2018.

   [I-D.ietf-isis-segment-routing-msd]
              Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg,
              "Signaling MSD (Maximum SID Depth) using IS-IS", draft-
              ietf-isis-segment-routing-msd-19 (work in progress),
              October 2018.

   [I-D.ietf-ospf-segment-routing-msd]
              Tantsura, J., Chunduri, U., Aldrin, S., and P. Psenak,
              "Signaling MSD (Maximum SID Depth) using OSPF", draft-
              ietf-ospf-segment-routing-msd-23 (work in progress),
              October 2018.

   [I-D.ietf-spring-resiliency-use-cases]
              Filsfils, C., Previdi, S., Decraene, B., and R. Shakir,
              "Resiliency use cases in SPRING networks", draft-ietf-
              spring-resiliency-use-cases-12 (work in progress),
              December 2017.

   [RFC6790]  Kompella, K., Drake, J., Amante, S., Henderickx, W., and
              L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
              RFC 6790, DOI 10.17487/RFC6790, November 2012,
              <https://www.rfc-editor.org/info/rfc6790>.

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







Hegde                    Expires April 20, 2019                [Page 13]

Internet-Draft       Traffic accounting for SR-Paths        October 2018


Author's Address

   Shraddha Hegde
   Juniper Networks, Inc.
   Embassy Business Park
   Bangalore, KA  560093
   India

   Email: shraddha@juniper.net










































Hegde                    Expires April 20, 2019                [Page 14]