draft-ietf-mpls-flow-ident-06.txt   draft-ietf-mpls-flow-ident-07.txt 
MPLS Working Group S. Bryant MPLS Working Group S. Bryant
Internet-Draft Huawei Internet-Draft Huawei
Intended status: Informational C. Pignataro Intended status: Informational C. Pignataro
Expires: June 17, 2018 Cisco Systems Expires: September 2, 2018 Cisco Systems
M. Chen M. Chen
Z. Li Z. Li
Huawei Huawei
G. Mirsky G. Mirsky
ZTE Corp. ZTE Corp.
December 14, 2017 March 01, 2018
MPLS Flow Identification Considerations MPLS Flow Identification Considerations
draft-ietf-mpls-flow-ident-06 draft-ietf-mpls-flow-ident-07
Abstract Abstract
This document discusses the aspects that need to be be considered This document discusses the aspects that need to be be considered
when developing a solution for MPLS flow identification. The key when developing a solution for MPLS flow identification. The key
application that needs this is in-band performance monitoring of MPLS application that needs this is in-band performance monitoring of MPLS
flows when MPLS is used to encapsulate user data packets. flows when MPLS is used to encapsulate user data packets.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 http://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 June 17, 2018. This Internet-Draft will expire on September 2, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 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
(http://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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 2. Loss Measurement Considerations . . . . . . . . . . . . . . . 3
3. Loss Measurement Considerations . . . . . . . . . . . . . . . 3 3. Delay Measurement Considerations . . . . . . . . . . . . . . 4
4. Delay Measurement Considerations . . . . . . . . . . . . . . 4 4. Units of identification . . . . . . . . . . . . . . . . . . . 4
5. Units of identification . . . . . . . . . . . . . . . . . . . 4 5. Types of LSP . . . . . . . . . . . . . . . . . . . . . . . . 5
6. Types of LSP . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Network Scope . . . . . . . . . . . . . . . . . . . . . . . . 6
7. Network Scope . . . . . . . . . . . . . . . . . . . . . . . . 7 7. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 7
8. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 7 8. Dataplane . . . . . . . . . . . . . . . . . . . . . . . . . . 7
9. Dataplane . . . . . . . . . . . . . . . . . . . . . . . . . . 7 9. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 8
10. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 9 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 8
11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9 11. Security Considerations . . . . . . . . . . . . . . . . . . . 9
12. Security Considerations . . . . . . . . . . . . . . . . . . . 9 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 14. Informative References . . . . . . . . . . . . . . . . . . . 9
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
15.1. Normative References . . . . . . . . . . . . . . . . . . 10
15.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
This document discusses the aspects that need to be considered when This document discusses the aspects that need to be considered when
developing a solution for MPLS flow identification.The key developing a solution for MPLS flow identification. The key
application that needs this is in-band performance monitoring of MPLS application that needs this is in-band performance monitoring of MPLS
flows when MPL is used for the encapsulation of user data packets. flows when MPLS is used for the encapsulation of user data packets.
There is a need to identify flows in MPLS networks for various There is a need to identify flows in MPLS networks for various
applications such as determining packet loss and packet delay applications such as determining packet loss and packet delay
measurement. A method of loss and delay measurement in MPLS networks measurement. A method of loss and delay measurement in MPLS networks
was defined in [RFC6374]. When used to measure packet loss [RFC6374] was defined in [RFC6374]. When used to measure packet loss [RFC6374]
depends on the use of injected Operations, Administration, and depends on the use of injected Operations, Administration, and
Maintenance (OAM) packets to designate the beginning and the end of Maintenance (OAM) packets to designate the beginning and the end of
the packet group over which packet loss is being measured. Where the the packet group over which packet loss is being measured. Where the
misordering of packets from one group relative to the following misordering of packets from one group relative to the following
group, or misordering of one of the packets being counted relative to group, or misordering of one of the packets being counted relative to
skipping to change at page 3, line 15 skipping to change at page 3, line 13
more destinations. more destinations.
Improvements in link and transmission technologies have made it more Improvements in link and transmission technologies have made it more
difficult to assess packet loss using active performance measurement difficult to assess packet loss using active performance measurement
methods with synthetic traffic, due to the very low loss rate in methods with synthetic traffic, due to the very low loss rate in
normal operation. That, together with more demanding service level normal operation. That, together with more demanding service level
requirements, means that network operators now need to be able to requirements, means that network operators now need to be able to
measure the loss of the actual user data traffic by using passive measure the loss of the actual user data traffic by using passive
performance measurement methods. Any technique deployed needs to be performance measurement methods. Any technique deployed needs to be
transparent to the end user, and it needs to be assumed that they transparent to the end user, and it needs to be assumed that they
will not take any active part in the measurement process. Indeed it will not take any active part in the measurement process.
is important that any flow identification technique be invisible to Indeed it is important that any flow identification technique be
them and that no remnant of the identification of measurement process invisible to them, and that no remnant of the measurement process
leaked into their network. leaks into their network.
Additionally where there are multiple traffic sources, such as in Additionally where there are multiple traffic sources, such as in
multi-point to point and multi-point to multi-point network multi-point to point and multi-point to multi-point network
environments there needs to be a method whereby the sink can environments there needs to be a method whereby the sink can
distinguish between packets from the various sources, that is to say, distinguish between packets from the various sources, that is to say,
that a multi-point to multi-point measurement model needs to be that a multi-point to multi-point measurement model needs to be
developed. developed.
2. Requirements Language 2. Loss Measurement Considerations
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 RFC2119 [RFC2119].
3. Loss Measurement Considerations
Modern networks, if not oversubscribed, potentially drop relatively Modern networks, if not oversubscribed, generally drop relatively few
few packets, thus packet loss measurement is highly sensitive to the packets, thus packet loss measurement is highly sensitive to the
common demarcation of the exact set of packets to be measured for common demarcation of the exact set of packets to be measured for
loss. Without some form of coloring or batch marking such as that loss. Without some form of coloring or batch marking such as that
proposed in [I-D.ietf-ippm-alt-mark] it may not be possible to proposed in [RFC8321] it may not be possible to achieve the required
achieve the required accuracy in the loss measurement of customer accuracy in the loss measurement of customer data traffic. Thus
data traffic. Thus where accurate measurement of packet loss is where accurate measurement of packet loss is required, it may be
required, it may be economically advantageous, or even a technical economically advantageous, or even a technical requirement, to
requirement, to include some form of marking in the packets to assign include some form of marking in the packets to assign each packet to
each packet to a particular counter for loss measurement purposes. a particular counter for loss measurement purposes.
Where this level of accuracy is required and the traffic between a Where this level of accuracy is required and the traffic between a
source-destination pair is subject to Equal-Cost Multipath (ECMP) a source-destination pair is subject to Equal-Cost Multipath (ECMP) a
demarcation mechanism is needed to group the packets into batches. demarcation mechanism is needed to group the packets into batches.
Once a batch is correlated at both ingress and egress, the packet Once a batch is correlated at both ingress and egress, the packet
accounting mechanism is then able to operate on the batch of packets accounting mechanism is then able to operate on the batch of packets
which can be accounted for at both the packet ingress and the packet which can be accounted for at both the packet ingress and the packet
egress. Errors in the accounting are particularly acute in Label egress. Errors in the accounting are particularly acute in Label
Switched Paths (LSPs) subjected to ECMP because the network transit Switched Paths (LSPs) subjected to ECMP because the network transit
time will be different for the various ECMP paths since: time will be different for the various ECMP paths since:
skipping to change at page 4, line 28 skipping to change at page 4, line 20
Network, Pseudowire etc) to indicate the batch is the impact that Network, Pseudowire etc) to indicate the batch is the impact that
this has on the path chosen by the ECMP mechanism. When the member this has on the path chosen by the ECMP mechanism. When the member
of the ECMP path set is chosen by deep packet inspection a change of of the ECMP path set is chosen by deep packet inspection a change of
batch represented by a change of identity label will have no impact batch represented by a change of identity label will have no impact
on the ECMP path. Where the path member is chosen by reference to an on the ECMP path. Where the path member is chosen by reference to an
entropy label [RFC6790] then changing the batch identifier will not entropy label [RFC6790] then changing the batch identifier will not
result in a change to the chosen ECMP path. ECMP is so pervasive in result in a change to the chosen ECMP path. ECMP is so pervasive in
multi-point to (multi-) point networks that some method of avoiding multi-point to (multi-) point networks that some method of avoiding
accounting errors introduced by ECMP needs to be supported. accounting errors introduced by ECMP needs to be supported.
4. Delay Measurement Considerations 3. Delay Measurement Considerations
Most of the existing delay measurement methods are active measurement Most of the existing delay measurement methods are active methods
that depend on the extra injected test packet to evaluate the delay that depend on the extra injected test packet to evaluate the delay
of a path. With the active measurement method, the rate, numbers and of a path. With the active measurement method, the rate, numbers and
interval between the injected packets may affect the accuracy of the interval between the injected packets may affect the accuracy of the
results. Also, for injected test packets, these may not be co-routed results. Due to ECMP (or link aggregation techniques) injected test
with the data traffic due to ECMP, or various link aggregation packets may traverse different links from the ones used by the data
technologies all of which distribute flows across a number of paths traffic. Thus there exists a requirement to measure the delay of the
at the network, or data-link and hence at the physical layer. real traffic.
Thus there exists a requirement to measure the delay of the real
traffic.
For combined loss-delay measurements, both the loss and the delay For combined loss-delay measurements, both the loss and the delay
considerations apply. considerations apply.
5. Units of identification 4. Units of identification
The most basic unit of identification is the identity of the node The most basic unit of identification is the identity of the node
that processed the packet on its entry to the MPLS network. However, that processed the packet on its entry to the MPLS network. However,
the required unit of identification may vary depending on the use the required unit of identification may vary depending on the use
case for accounting, performance measurement or other types of packet case for accounting, performance measurement or other types of packet
observations. In particular note that there may be a need to impose observations. In particular note that there may be a need to impose
identify at several different layers of the MPLS label stack. identity at several different layers of the MPLS label stack.
This document considers following units of identifications: This document considers following units of identifications:
o Per source LSR - everything from one source is aggregated. o Per source LSR - everything from one source is aggregated.
o Per group of LSPs chosen by an ingress LSR - an ingress LSP o Per group of LSPs chosen by an ingress LSR - an ingress LSP
aggregates group of LSPs (ex: all LSPs of a tunnel). aggregates group of LSPs (ex: all LSPs of a tunnel).
o Per LSP - the basic form. o Per LSP - the basic form.
o Per flow [RFC6790] within an LSP - fine grained method. o Per flow [RFC6790] within an LSP - fine grained method.
Note that a fine grained identity resolution is needed when there is Note that a fine grained identity resolution is needed when there is
a need to perform these operations on a flow not readily identified a need to perform these operations on a flow not readily identified
by some other element in the label stack. Such fine grained by some other element in the label stack.
resolution may be possible by deep packet inspection, but this may Such fine-grained resolution may be possible by deep packet
not always be possible, or it may be desired to minimize processing inspection. However, this may not always be possible, or it may be
costs by doing this only in entry to the network, and adding a desired to minimize processing costs by doing this only on entry to
suitable identifier to the packet for reference by other network the network. Adding a suitable identifier to the packet for
elements. An example of such a fine grained case might be traffic reference by other network elements minumises the processing needed
from a specific application, or from a specific application from a by other network elements. An example of such a fine grained case
specific source, particularly if matters related to service level might be traffic belonging to a certain service or from a specific
agreement or application performance were being investigated. source, particularly if matters related to service level agreement or
application performance were being investigated
We can thus characterize the identification requirement in the We can thus characterize the identification requirement in the
following broad terms: following broad terms:
o There needs to be some way for an egress LSR to identify the o There needs to be some way for an egress LSR to identify the
ingress LSR with an appropriate degree of scope. This concept is ingress LSR with an appropriate degree of scope. This concept is
discussed further in Section 7. discussed further in Section 6.
o There needs to be a way to identify a specific LSP at the egress o There needs to be a way to identify a specific LSP at the egress
node. This allows for the case of instrumenting multiple LSPs node. This allows for the case of instrumenting multiple LSPs
operate between the same pair of nodes. In such cases the operating between the same pair of nodes. In such cases the
identity of the ingress LSR is insufficient. identity of the ingress LSR is insufficient.
o In order to conserve resources such as labels, counters and/or o In order to conserve resources such as labels, counters and/or
compute cycles it may be desirable to identify an LSP group so compute cycles it may be desirable to identify an LSP group so
that a operation can be performed on the group as an aggregate. that a operation can be performed on the group as an aggregate.
o There needs to be a way to identify a flow within an LSP. This is o There needs to be a way to identify a flow within an LSP. This is
necessary when investigating a specific flow that has been necessary when investigating a specific flow that has been
aggregated into an LSP. aggregated into an LSP.
The unit of identification and the method of determining which The unit of identification and the method of determining which
packets constitute a flow will be application or use-case specific packets constitute a flow will be application or use-case specific
and is out of scope of this document. and is out of scope of this document.
6. Types of LSP 5. Types of LSP
We need to consider a number of types of LSP. The two simplest types We need to consider a number of types of LSP. The two simplest types
to monitor are point to point LSPs and point to multi-point LSPs. to monitor are point to point LSPs and point to multi-point LSPs.
The ingress LSR for a point to point LSP, such as those created using The ingress LSR for a point to point LSP, such as those created using
the Resource Reservation Protocol - Traffic Engineering (RSVP-TE) the Resource Reservation Protocol - Traffic Engineering (RSVP-TE)
[RFC5420] Signaling protocol, or those that conform to the MPLS [RFC5420] Signaling protocol, or those that conform to the MPLS
Transport Profile (MPLS-TP) [RFC5654] may be identified by inspection Transport Profile (MPLS-TP) [RFC5654] may be identified by inspection
of the top label in the stack, since at any provider-edge (PE) or of the top label in the stack, since at any provider-edge (PE) or
provider (P) router on the path this is unique to the ingress-egress provider (P) router on the path this is unique to the ingress-egress
pair at every hop at a given layer in the LSP hierarchy. Provided pair at every hop at a given layer in the LSP hierarchy. Provided
skipping to change at page 6, line 41 skipping to change at page 6, line 29
desirable that a common method of LSP group identification be used. desirable that a common method of LSP group identification be used.
In the above cases, a context label [RFC5331] needs to be used to In the above cases, a context label [RFC5331] needs to be used to
provide the required identity information. This is widely supported provide the required identity information. This is widely supported
MPLS feature. MPLS feature.
A more interesting case is the case of a multi-point to point LSP. A more interesting case is the case of a multi-point to point LSP.
In this case the same label is normally used by multiple ingress or In this case the same label is normally used by multiple ingress or
upstream LSRs and hence source identification is not possible by upstream LSRs and hence source identification is not possible by
inspection of the top label by the egress LSRs. It is therefore inspection of the top label by the egress LSRs. It is therefore
necessary for a packet to be able to explicitly convey any of the necessary for a packet to be able to explicitly convey any of the
identity types described in Section 5. identity types described in Section 4.
Similarly, in the case of a multi-point to multi-point LSP the same Similarly, in the case of a multi-point to multi-point LSP the same
label is normally used by multiple ingress or upstream LSRs and hence label is normally used by multiple ingress or upstream LSRs and hence
source identification is not possible by inspection of the top label source identification is not possible by inspection of the top label
by egress LSRs. The various types of identity described in Section 5 by egress LSRs. The various types of identity described in Section 4
are again needed. Note however, that the scope of the identity may are again needed. Note however, that the scope of the identity may
be constrained to be unique within the set of multi-point to multi- be constrained to be unique within the set of multi-point to multi-
point LSPs terminating on any common node. point LSPs terminating on any common node.
7. Network Scope 6. Network Scope
The scope of identification can be constrained to the set of flows The scope of identification can be constrained to the set of flows
that are uniquely identifiable at an ingress LSR, or some aggregation that are uniquely identifiable at an ingress LSR, or some aggregation
thereof. There is no need of an ingress LSR seeking assistance from thereof. There is no need of an ingress LSR seeking assistance from
outside the MPLS protocol domain. outside the MPLS protocol domain.
In any solution that constrains itself to carrying the required In any solution that constrains itself to carrying the required
identity in the MPLS label stack rather than in some different identity in the MPLS label stack rather than in some different
associated data structure, constraints on the choice of label and associated data structure, constraints on the choice of label and
label stack size imply that the scope of identity resides within that label stack size imply that the scope of identity resides within that
MPLS domain. For similar reasons the identity scope of a component MPLS domain. For similar reasons the identity scope of a component
of an LSP is constrained to the scope of that LSP. of an LSP is constrained to the scope of that LSP.
8. Backwards Compatibility 7. Backwards Compatibility
In any network it is unlikely that all LSRs will have the same In any network it is unlikely that all LSRs will have the same
capability to support the methods of identification discussed in this capability to support the methods of identification discussed in this
document. It is therefore an important constraint on any flow document. It is therefore an important constraint on any flow
identity solution that it is backwards compatible with deployed MPLS identity solution that it is backwards compatible with deployed MPLS
equipment to the extent that deploying the new feature will not equipment to the extent that deploying the new feature will not
disable anything that currently works on a legacy equipment. disable anything that currently works on a legacy equipment.
This is particularly the case when the deployment is incremental or This is particularly the case when the deployment is incremental or
the feature is not required for all LSRs or all LSPs. Thus, the flow the feature is not required for all LSRs or all LSPs. Thus, the flow
identification design MUST support the co-existence of both LSRs that identification design must support the co-existence of both LSRs that
can, and cannot, identify the traffic components described in can, and cannot, identify the traffic components described in
Section 5. In addition the identification of the traffic components Section 4. In addition the identification of the traffic components
described in Section 5 MUST be an optional feature that is disabled described in Section 4 must be an optional feature that is disabled
by default. As a design simplification, a solution MAY require that by default. As a design simplification, a solution may require that
all egress LSRs of a point to multi-point or a multi- point to multi- all egress LSRs of a point to multi-point or a multi- point to multi-
point LSP support the identification type in use so that a single point LSP support the identification type in use so that a single
packet can be correctly processed by all egress devices. The packet can be correctly processed by all egress devices. The
corollary of this last point is that either all egress LSRs are corollary of this last point is that either all egress LSRs are
enabled to support the required identity type, or none of them are. enabled to support the required identity type, or none of them are.
9. Dataplane 8. Dataplane
There is a huge installed base of MPLS equipment, typically this type There is a huge installed base of MPLS equipment, typically this type
of equipment remains in service for an extended period of time, and of equipment remains in service for an extended period of time, and
in many cases hardware constraints mean that it is not possible to in many cases hardware constraints mean that it is not possible to
upgrade its dataplane functionality. Changes to the MPLS data plane upgrade its dataplane functionality. Changes to the MPLS data plane
are therefore expensive to implement, add complexity to the network, are therefore expensive to implement, add complexity to the network,
and may significantly impact the deployability of a solution that and may significantly impact the deployability of a solution that
requires such changes. For these reasons, MPLS users have set a very requires such changes. For these reasons, MPLS users have set a very
high bar to changes to the MPLS data plane, and only a very small high bar to changes to the MPLS data plane, and only a very small
number have been adopted. Hence, it is important that the method of number have been adopted. Hence, it is important that the method of
skipping to change at page 8, line 26 skipping to change at page 8, line 12
Stack size is an issue with many MPLS implementations both as a Stack size is an issue with many MPLS implementations both as a
result of hardware limitations, and due to the impact on networks and result of hardware limitations, and due to the impact on networks and
applications where a large number of small payloads need to be applications where a large number of small payloads need to be
transported In particular one MPLS payload may be carried inside transported In particular one MPLS payload may be carried inside
another. For example, one LSP may be carried over another LSP, or a another. For example, one LSP may be carried over another LSP, or a
PW or similar multiplexing construct may be carried over an LSP and PW or similar multiplexing construct may be carried over an LSP and
identification may be required at both layers. Of particular concern identification may be required at both layers. Of particular concern
is the implementation of low cost edge LSRs that for cost reasons is the implementation of low cost edge LSRs that for cost reasons
have a significant limit on the number of Label Stack Elements (LSEs) have a significant limit on the number of Label Stack Elements (LSEs)
that they can impose or dispose. Therefore, any method of identity that they can impose or dispose. Therefore, any method of identity
MUST NOT consume an excessive number of unique labels, and MUST NOT must not consume an excessive number of unique labels, and must not
result in an excessive increase in the size of the label stack. result in an excessive increase in the size of the label stack.
The MPLS data plane design provides two types of special purpose The MPLS data plane design provides two types of special purpose
labels: the original 16 reserved labels and the much larger set of labels: the original 16 reserved labels and the much larger set of
special purpose labels defined in [RFC7274]. The original reserved special purpose labels defined in [RFC7274]. The original reserved
labels need one LSE, and the newer [RFC7274] special purpose labels labels need one LSE, and the newer [RFC7274] special purpose labels
need two LSEs. Given the tiny number of original reserved labels, it need two LSEs. Given the tiny number of original reserved labels, it
is core to the MPLS design philosophy that this scarce resource is is core to the MPLS design philosophy that this scarce resource is
only used when it is absolutely necessary. Using a single LSE only used when it is absolutely necessary. Using a single LSE
reserved or special purpose label to encode flow identity thus reserved or special purpose label to encode flow identity thus
skipping to change at page 9, line 5 skipping to change at page 8, line 34
the flow identity. The larger set of [RFC7274] labels requires two the flow identity. The larger set of [RFC7274] labels requires two
labels stack entries for the special purpose label itself and hence a labels stack entries for the special purpose label itself and hence a
total of three label stack entries to encode the flow identity. total of three label stack entries to encode the flow identity.
The use of special purpose labels (SPL) [RFC7274] as part of a method The use of special purpose labels (SPL) [RFC7274] as part of a method
to encode the identity information therefore has a number of to encode the identity information therefore has a number of
undesirable implications for the data plane and hence whilst a undesirable implications for the data plane and hence whilst a
solution may use SPL(s), methods that do not require SPLs need to be solution may use SPL(s), methods that do not require SPLs need to be
carefully considered. carefully considered.
10. Control Plane 9. Control Plane
Any flow identity design should both seek to minimise the complexity Any flow identity design should both seek to minimise the complexity
of the control plane and should minimise the amount of label co- of the control plane and should minimise the amount of label co-
ordination needed amongst LSRs. ordination needed amongst LSRs.
11. Privacy Considerations 10. Privacy Considerations
The inclusion of originating and/or flow information in a packet The inclusion of originating and/or flow information in a packet
provides more identity information and hence potentially degrades the provides more identity information and hence potentially degrades the
privacy of the communication. Recent IETF concerns on pervasive privacy of the communication. Recent IETF concerns on pervasive
monitoring [RFC7258] would lead it to prefer a solution that does not monitoring [RFC7258] would lead it to prefer a solution that does not
degrade the privacy of user traffic below that of an MPLS network not degrade the privacy of user traffic below that of an MPLS network not
implementing the flow identification feature. The choice of using implementing the flow identification feature. The choice of using
MPLS technology for this OAM solution has a privacy advantage as the MPLS technology for this OAM solution has a privacy advantage as the
choice of the label identifying a flow is limited to the scope of the choice of the label identifying a flow is limited to the scope of the
MPLS domain and does not have any dependency on the user data's MPLS domain and does not have any dependency on the user data's
identification. This minimizes the observability of the flow identification. This minimizes the observability of the flow
characteristics. characteristics.
12. Security Considerations 11. Security Considerations
Any solution to the flow identification needs must not degrade the Any solution to the flow identification needs must not degrade the
security of the MPLS network below that of an equivalent network not security of the MPLS network below that of an equivalent network not
deploying the specified identity solution. Propagation of deploying the specified identity solution.
identification information outside the MPLS network imposing it must In order to preserve present assumptions about MPLS privacy
be disabled by default. Any solution should provide for the properties, propagation of identification information outside the
restriction of the identity information to those components of the MPLS network imposing it must be disabled by default. Any solution
network that need to know it. It is thus desirable to limit the should provide for the restriction of the identity information to
knowledge of the identify of an endpoint to only those LSRs that need those components of the network that need to know it. It is thus
to participate in traffic flow. The choice of using MPLS technology desirable to limit the knowledge of the identify of an endpoint to
for this OAM solution, with MPLS encapsulation of user traffic, only those LSRs that need to participate in traffic flow. The choice
provides for a key advantage over other data plane solutions, as it of using MPLS technology for this OAM solution, with MPLS
provides for a controlled access and trusted domain within a Service encapsulation of user traffic, provides for a key advantage over
Provider's network. other data plane solutions, as it provides for a controlled access
and trusted domain within a Service Provider's network.
For a more comprehensive discussion of MPLS security and attack For a more comprehensive discussion of MPLS security and attack
mitigation techniques, please see the Security Framework for MPLS and mitigation techniques, please see the Security Framework for MPLS and
GMPLS Networks [RFC5920]. GMPLS Networks [RFC5920].
13. IANA Considerations 12. IANA Considerations
This document has no IANA considerations. (At the discression of the This document has no IANA considerations. (At the discretion of the
RFC Editor this section may be removed before publication). RFC Editor this section may be removed before publication).
14. Acknowledgements 13. Acknowledgments
The authors thank Nobo Akiya, Nagendra Kumar Nainar, George Swallow The authors thank Nobo Akiya, Nagendra Kumar Nainar, George Swallow
and Deborah Brungard for their comments. and Deborah Brungard for their comments.
15. References 14. Informative References
15.1. Normative References
[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>.
15.2. Informative References
[I-D.ietf-ippm-alt-mark]
Fioccola, G., Capello, A., Cociglio, M., Castaldelli, L.,
Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi,
"Alternate Marking method for passive and hybrid
performance monitoring", draft-ietf-ippm-alt-mark-14 (work
in progress), December 2017.
[RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream
Label Assignment and Context-Specific Label Space", Label Assignment and Context-Specific Label Space",
RFC 5331, DOI 10.17487/RFC5331, August 2008, RFC 5331, DOI 10.17487/RFC5331, August 2008,
<https://www.rfc-editor.org/info/rfc5331>. <https://www.rfc-editor.org/info/rfc5331>.
[RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and A. [RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and A.
Ayyangarps, "Encoding of Attributes for MPLS LSP Ayyangarps, "Encoding of Attributes for MPLS LSP
Establishment Using Resource Reservation Protocol Traffic Establishment Using Resource Reservation Protocol Traffic
Engineering (RSVP-TE)", RFC 5420, DOI 10.17487/RFC5420, Engineering (RSVP-TE)", RFC 5420, DOI 10.17487/RFC5420,
skipping to change at page 10, line 50 skipping to change at page 10, line 16
Sprecher, N., and S. Ueno, "Requirements of an MPLS Sprecher, N., and S. Ueno, "Requirements of an MPLS
Transport Profile", RFC 5654, DOI 10.17487/RFC5654, Transport Profile", RFC 5654, DOI 10.17487/RFC5654,
September 2009, <https://www.rfc-editor.org/info/rfc5654>. September 2009, <https://www.rfc-editor.org/info/rfc5654>.
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010,
<https://www.rfc-editor.org/info/rfc5920>. <https://www.rfc-editor.org/info/rfc5920>.
[RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay
Measurement for MPLS Networks", RFC 6374, Measurement for MPLS Networks", RFC 6374,
DOI 10.17487/RFC6374, September 2011, <https://www.rfc- DOI 10.17487/RFC6374, September 2011,
editor.org/info/rfc6374>. <https://www.rfc-editor.org/info/rfc6374>.
[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and
L. Yong, "The Use of Entropy Labels in MPLS Forwarding", L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
RFC 6790, DOI 10.17487/RFC6790, November 2012, RFC 6790, DOI 10.17487/RFC6790, November 2012,
<https://www.rfc-editor.org/info/rfc6790>. <https://www.rfc-editor.org/info/rfc6790>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
2014, <https://www.rfc-editor.org/info/rfc7258>. 2014, <https://www.rfc-editor.org/info/rfc7258>.
[RFC7274] Kompella, K., Andersson, L., and A. Farrel, "Allocating [RFC7274] Kompella, K., Andersson, L., and A. Farrel, "Allocating
and Retiring Special-Purpose MPLS Labels", RFC 7274, and Retiring Special-Purpose MPLS Labels", RFC 7274,
DOI 10.17487/RFC7274, June 2014, <https://www.rfc- DOI 10.17487/RFC7274, June 2014,
editor.org/info/rfc7274>. <https://www.rfc-editor.org/info/rfc7274>.
[RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli,
L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi,
"Alternate-Marking Method for Passive and Hybrid
Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321,
January 2018, <https://www.rfc-editor.org/info/rfc8321>.
Authors' Addresses Authors' Addresses
Stewart Bryant Stewart Bryant
Huawei Huawei
Email: stewart.bryant@gmail.com Email: stewart.bryant@gmail.com
Carlos Pignataro Carlos Pignataro
Cisco Systems Cisco Systems
 End of changes. 41 change blocks. 
115 lines changed or deleted 96 lines changed or added

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