< draft-hegde-spring-traffic-accounting-for-sr-paths-00.txt   draft-hegde-spring-traffic-accounting-for-sr-paths-01.txt >
SPRING WG S. Hegde SPRING WG S. Hegde
Internet-Draft Juniper Networks, Inc. Internet-Draft Juniper Networks, Inc.
Intended status: Standards Track October 19, 2017 Intended status: Standards Track October 30, 2017
Expires: April 22, 2018 Expires: May 3, 2018
Traffic Accounting for MPLS Segment Routing Paths Traffic Accounting for MPLS Segment Routing Paths
draft-hegde-spring-traffic-accounting-for-sr-paths-00 draft-hegde-spring-traffic-accounting-for-sr-paths-01
Abstract Abstract
Traffic statistics form an important part of operations and Traffic statistics form an important part of operations and
maintenance data that are used to create demand matrices and for maintenance data that are used to create demand matrices and for
capacity planning in networks. Segment Routing (SR) is a source capacity planning in networks. Segment Routing (SR) is a source
routing paradigm that uses stack of labels to represent a path. The 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 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 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 to each SR path are an important component of the data which helps
skipping to change at page 2, line 10 skipping to change at page 2, line 10
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 22, 2018. This Internet-Draft will expire on May 3, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 35 skipping to change at page 2, line 35
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. SR-Path Identifier . . . . . . . . . . . . . . . . . . . . . 5 4. SR-Path Identifier . . . . . . . . . . . . . . . . . . . . . 5
4.1. Centrally Managed SR Paths . . . . . . . . . . . . . . . 5 4.1. Centrally Managed SR Paths . . . . . . . . . . . . . . . 5
4.2. Locally Managed SR Paths . . . . . . . . . . . . . . . . 5 4.2. Locally Managed SR Paths . . . . . . . . . . . . . . . . 5
5. Use of the SR-Path-Identifier and Source-SID . . . . . . . . 5 5. Use of the SR-Path-Identifier and Source-SID . . . . . . . . 6
6. Inserting the SR-Path-Identifier in Packets . . . . . . . . . 6 6. Inserting the SR-Path-Identifier in Packets . . . . . . . . . 7
7. Traffic-Accounting for Sub SR-Paths in the Network . . . . . 7 7. Traffic-Accounting for Sub SR-Paths in the Network . . . . . 8
8. Forwarding Plane Procedures . . . . . . . . . . . . . . . . . 8 8. Forwarding Plane Procedures . . . . . . . . . . . . . . . . . 8
9. Consideration of Protection Mechanisms . . . . . . . . . . . 9 9. Consideration of Protection Mechanisms . . . . . . . . . . . 10
10. Backward Compatibility . . . . . . . . . . . . . . . . . . . 9 10. Backward Compatibility . . . . . . . . . . . . . . . . . . . 10
11. Scalability Considerations . . . . . . . . . . . . . . . . . 10 11. Scalability Considerations . . . . . . . . . . . . . . . . . 11
12. Security Considerations . . . . . . . . . . . . . . . . . . . 10 12. Security Considerations . . . . . . . . . . . . . . . . . . . 11
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11 15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 12
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
16.1. Normative References . . . . . . . . . . . . . . . . . . 11 16.1. Normative References . . . . . . . . . . . . . . . . . . 12
16.2. Informative References . . . . . . . . . . . . . . . . . 11 16.2. Informative References . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
Figure 1 describes an SR enabled network with Node-SIDs and Anycast- 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 SIDs assigned. The SR-Paths with label stacks are as shown in the
diagram. The SR-Paths are created (possibly by a central controller) diagram. The SR-Paths are created (possibly by a central controller)
so as to maximize the network resource utilization such as bandwidth. 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- Based on the traffic carried by the SR-Paths, they need to be re-
routed occasionally to balance the bandwidth utilization. SR-Paths routed occasionally to balance the bandwidth utilization. SR-Paths
are inherently ECMP aware. are inherently ECMP aware.
skipping to change at page 5, line 6 skipping to change at page 5, line 6
5. The mechanism SHOULD be applicable to all MPLS environments. 5. The mechanism SHOULD be applicable to all MPLS environments.
3. Terminology 3. Terminology
Source-SID: The (globally unique) Node-SID of the head-end node 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 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. excluding 0-15 and may be encoded in an MPLS label field.
SR-Path-Identifier: An SR-Path-Identifier is an identifier for each SR-Path-Identifier: An SR-Path-Identifier is an identifier for each
SR path in the network. It is unique per source (head-end) node. SR path in the network. It is unique within the scope of the node
Thus the combination of Source-SID and SR-Path Identifier uniquely that allocated the identifier. If the identifier is allocated by
identifies an SR path within a network. The SR-Path Identifier is the head-end node (the source) the combination of Source-SID and
a 20 bit number excluding 0-15 and may be encoded in an MPLS label SR-Path Identifier uniquely identifies an SR path within a
field. See Section 4. 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 SR-Path-Indicator: The SR-Path-Indicator is an MPLS Special Purpose
Label [RFC7274]. This label indicates the presence of an SR-Path Label [RFC7274]. This label indicates the presence of an SR-Path
Identifier and an Source Node-SID encoded in MPLS label stack Identifier and an Source Node-SID encoded in MPLS label stack
entries and situated immediately below this label stack entry in entries and situated immediately below this label stack entry in
the label stack. the label stack.
SR-Path-Stats Labels: The SR-Path-Indicator, SR-Path-Identifier, and SR-Path-Stats Labels: The SR-Path-Indicator, SR-Path-Identifier, and
Source-SID together are termed as the SR-Path-Stats Labels. Source-SID together are termed as the SR-Path-Stats Labels.
4. SR-Path Identifier 4. SR-Path Identifier
4.1. Centrally Managed SR Paths 4.1. Centrally Managed SR Paths
In controller-based deployments, a controller creates an SR policy, In controller-based deployments, a controller creates an SR policy,
associates a segment list and a Binding SID to the policy, and sends 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 it to the head-end of the SR path as described in
[I-D.filsfils-spring-segment-routing-policy]. When the head-end node [I-D.filsfils-spring-segment-routing-policy]. The controller may
receives this policy, it creates a locally-unique identifier for each also allocate a network-unique SR-Path-Identifier and send it to the
the SR path network and associates it with SR-TE Policy. The SR- head-end along with the policy. When the head-end node receives this
Path-Identifier associated with the policy is advertised back to the 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 controller using mechanisms described in
[I-D.ietf-idr-te-lsp-distribution]. [I-D.ietf-idr-te-lsp-distribution].
The SR-Path-Identifier is used for the purpose of traffic accounting The SR-Path-Identifier is used for the purpose of traffic accounting
as described in Section 5. as described in Section 5.
4.2. Locally Managed SR Paths 4.2. Locally Managed SR Paths
Deployments which do not use a central controller for managing the Deployments which do not use a central controller for managing the
network configure locally manage SR-Paths on the head-end router. 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 Every SR path in the network is identified using a Source-SID and a
soure-unique SR-Path-Identifier. The head-end node generates the SR- source-unique SR-Path-Identifier. The head-end node generates the
Path-Identifier for each SR path and associates it with the SR path. 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
5. Use of the SR-Path-Identifier and Source-SID 5. Use of the SR-Path-Identifier and Source-SID
The SR-Path-Identifier is a 20 bit number created by the head-end 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- node as described in Section 4. The SR-Path-Identifier and Source-
SID are inserted in the packet below a Special Purpose Label called 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 the SR-Path-Indicator. The three values are each carried in a label
stack entry as shown in Figure 2. stack entry as shown in Figure 2.
0 1 2 3 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 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 | | SR-Path-Indicator | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source-SID | TC |S| TTL | |C| SR-Path-Identifier | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SR-Path-Identifier | TC |S| TTL | | Source-SID | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: The SR-Path-Stats Labels Encoded in Label Stack Entries 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 value is TBD-1 to be assigned by IANA.
The Source-SID is inserted immediately below the SR-Path-Indicator, The SR-Path-Indicator label indicates that the MPLS label stack
and the SR-Path-Identifier is inserted below the Source-SID. 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-Indicator label indicates that the two MPLS label stack The SR-Path-Identifier label stack entry is inserted immediately
entries that follow carry the Source-SID and SR-Path-Identifier. below the SR-Path-Indicator. The label field contains two elements:
These three label stack entries MUST NOT be used for forwarding, and
if they are encountered at the top of the label stack (for example, o The C-flag indicates whether the SR-Path-Identifier is allocated
at the egress node) they MUST be stripped. 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
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 An intermediate node in the network can look into the packet and
account the traffic based on the Source-SID and SR-Path-Identifier. account the traffic based on the SR-Path-Identifier and Source-SID.
Because it is necessary that the SR-Path-Stats labels are removed 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 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 the label stack (the ingress) must know which nodes are capable of
stripping the labels. This ability is advertised in IGP stripping the labels. This ability is advertised in IGP
advertisements defined in TBD and TBD. advertisements defined in TBD and TBD.
6. Inserting the SR-Path-Identifier in Packets 6. Inserting the SR-Path-Identifier in Packets
The Source-SID and SR-Path-Identifier are used as a key to account 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 traffic. The forwarding plane entities should look up
the Source-SID and SR-Path-Identifier values to account the traffic the SR-Path-Identifier and Source-SID (if present) values to account
against the right path counters. the traffic against the right path counters.
The SR-Path-Stats Labels are normally placed at the bottom of the The SR-Path-Stats Labels are normally placed at the bottom of the
label stack. label stack.
Forwarding hardware may have limitations and not support accessing Forwarding hardware may have limitations and not support accessing
the label stack beyond certain depth. In such cases, the hardware 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 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 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 accounting in such cases it is necessary to insert the SR-Path-Stats
Labels within the Readable Label Stack Depth Capability (RLDC) of the Labels within the Readable Label Stack Depth Capability (RLDC) of the
skipping to change at page 8, line 4 skipping to change at page 8, line 31
created within the network, and Binding-SIDs are allocated to these created within the network, and Binding-SIDs are allocated to these
sub-paths. When the label representing a Binding-SID is processed it 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 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 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 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 constructs the end-to-end SR path from a series of sub-paths
The sub-paths are not accounted separately. Accounting is performed The sub-paths are not accounted separately. Accounting is performed
on the end-to-end SR paths. However, edge routers MAY create on the end-to-end SR paths. However, edge routers MAY create
Binding-SIDs for BGP-SR-TE Policies as described in Binding-SIDs for BGP-SR-TE Policies as described in
[I-D.ietf-idr-segment-routing-te-policy]. Traffic accounting for the [I-D.ietf-idr-segment-routing-te-policy]. Traffic accounting for the
traffic carried on the SR paths indicated by these Binding-SIDs can traffic carried on the SR paths indicated by these Binding-SIDs can
be done separately by allocating separate SR-Path-Identifiers for be done separately by allocating separate SR-Path-Identifiers for
these sub-paths. these sub-paths.
8. Forwarding Plane Procedures 8. Forwarding Plane Procedures
To support per-path traffic accounting, the forwarding plane in a To support per-path traffic accounting, the forwarding plane in a
router MUST look through the label stack of a packet for the first router MUST look through the label stack of a packet for the first
instance of the SR-Path-Indicator. The label values in the next two instance of the SR-Path-Indicator. The label value in the next label
label stack entries are the Source-SID and the SR-Path-Identifier. stack entry is the SR-Path-Identifierand the C-flag indicates whether
These two label values are used as the key for accounting SR path a Source-SID label stack entry is also present. The label values are
traffic. 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 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 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 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 costly operation and MUST NOT be done unless if SR path accounting is
enabled on the device. Implementations MUST include a device-wide enabled on the device. Implementations MUST include a device-wide
configuration option to enable and disable SR path accounting, and configuration option to enable and disable SR path accounting, and
this option MUST default to "off". Implementations SHOULD include this option MUST default to "off". Implementations SHOULD include
more granular configuration (such as per-interface). more granular configuration (such as per-interface).
skipping to change at page 8, line 46 skipping to change at page 9, line 26
label blocks the procedures described in this section may be applied. label blocks the procedures described in this section may be applied.
If the SR label is allocated dynamically as in case of dynamic If the SR label is allocated dynamically as in case of dynamic
Adjacency-SIDs, it may be difficult to identify whether the label Adjacency-SIDs, it may be difficult to identify whether the label
belongs to SR. It is RECOMMENDED to use configured Adjacency-SIDs belongs to SR. It is RECOMMENDED to use configured Adjacency-SIDs
when SR path traffic accounting is enabled. when SR path traffic accounting is enabled.
If the top label of the incoming packet is of the right type for If the top label of the incoming packet is of the right type for
accounting and if other appropriate configuration options are accounting and if other appropriate configuration options are
enabled, then packet's label stack MUST be examined label by label 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- until an SR-Path-Indicator label is found. The label below SR-Path-
Indicator label is the Source-SID label and SR-Path-Identifier label. Indicator label is the SR-Path-Identifier label and the Source-SID
The {incoming interface, SR-Path-Identifier, Source SID} together are label follows according to the setting of the C-flag. The {incoming
the key for traffic accounting. 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 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 counter SHOULD be created. If a counter already exists, it MUST be
incremented. incremented.
There is no requirement to preemptively create counters for every There is no requirement to preemptively create counters for every
incoming interface and every SID: the counters need only be created, incoming interface and every SID: the counters need only be created,
when a packet is received with the new SR-Path-identifier. This will when a packet is received with the new SR-Path-identifier. This will
significantly reduce the number of counters that need to be significantly reduce the number of counters that need to be
instantiated as not every interface will receive traffic for any instantiated as not every interface will receive traffic for any
particular SR path. particular SR path.
If the SR-Path-Indicator is the top label in a packet, the three SR- If the SR-Path-Indicator is the top label in a packet, the SR-Path-
Path-Stats labels are popped and further processing is based on the Stats labels are popped and further processing is based on the
remaining labels in the label stack. Implementations MUST make sure remaining labels in the label stack. Implementations MUST make sure
the traffic accounting is carried out before the SR-Path-Stats labels the traffic accounting is carried out before the SR-Path-Stats labels
are popped. are popped.
9. Consideration of Protection Mechanisms 9. Consideration of Protection Mechanisms
SR paths typically consist of one or more Node-SIDs, Adjacency-SIDs, SR paths typically consist of one or more Node-SIDs, Adjacency-SIDs,
Anycast-SIDs, and Binding-SIDs. A variety of protection mechanisms Anycast-SIDs, and Binding-SIDs. A variety of protection mechanisms
may be in place for these SIDs as described in may be in place for these SIDs as described in
[I-D.ietf-spring-resiliency-use-cases]. When the head-end node [I-D.ietf-spring-resiliency-use-cases]. When the head-end node
skipping to change at page 10, line 35 skipping to change at page 11, line 23
Head-end nodes MUST NOT insert SR-Path-Stats labels by default. Head-end nodes MUST NOT insert SR-Path-Stats labels by default.
Careful configuration of which SR paths have statistics collection Careful configuration of which SR paths have statistics collection
enabled will help to minimize the number of counters that need to be enabled will help to minimize the number of counters that need to be
maintained at transit nodes. maintained at transit nodes.
Transit nodes that are constrained for the number of counters that Transit nodes that are constrained for the number of counters that
they can support MAY implement mechanisms that sacrifice some under- they can support MAY implement mechanisms that sacrifice some under-
used counters to create new counters. 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 12. Security Considerations
As noted in Section 11 the counter space is a limited resource in As noted in Section 11 the counter space is a limited resource in
hardware. This document introduces dynamic creation of counters hardware. This document introduces dynamic creation of counters
based on packet headers of the incoming packets. There is the based on packet headers of the incoming packets. There is the
possibility that a DOS attack is mounted by requesting new counter possibility that a DOS attack is mounted by requesting new counter
creation on each packet. Implementations SHOULD monitor the counter creation on each packet. Implementations SHOULD monitor the counter
space and generate appropriate warnings if the counter space is space and generate appropriate warnings if the counter space is
getting exhausted. Implementations SHOULD control the rate at which getting exhausted. Implementations SHOULD control the rate at which
the counters get created to mitigate DOS attacks. the counters get created to mitigate DOS attacks.
 End of changes. 21 change blocks. 
53 lines changed or deleted 97 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/