draft-ietf-mpls-flow-ident-07.txt   rfc8372.txt 
MPLS Working Group S. Bryant Internet Engineering Task Force (IETF) S. Bryant
Internet-Draft Huawei Request for Comments: 8372 Huawei
Intended status: Informational C. Pignataro Category: Informational C. Pignataro
Expires: September 2, 2018 Cisco Systems ISSN: 2070-1721 Cisco
M. Chen M. Chen
Z. Li Z. Li
Huawei Huawei
G. Mirsky G. Mirsky
ZTE Corp. ZTE Corp.
March 01, 2018 May 2018
MPLS Flow Identification Considerations MPLS Flow Identification Considerations
draft-ietf-mpls-flow-ident-07
Abstract Abstract
This document discusses the aspects that need to be be considered This document discusses aspects to consider when developing a
when developing a solution for MPLS flow identification. The key solution for MPLS flow identification. The key application that
application that needs this is in-band performance monitoring of MPLS needs this solution is in-band performance monitoring of MPLS flows
flows when MPLS is used to encapsulate user data packets. 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 document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
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/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are candidates for any level of Internet
Standard; see Section 2 of RFC 7841.
This Internet-Draft will expire on September 2, 2018. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8372.
Copyright Notice Copyright Notice
Copyright (c) 2018 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
(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 15 skipping to change at page 2, line 25
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. Loss Measurement Considerations . . . . . . . . . . . . . . . 3 2. Loss Measurement Considerations . . . . . . . . . . . . . . . 3
3. Delay Measurement Considerations . . . . . . . . . . . . . . 4 3. Delay Measurement Considerations . . . . . . . . . . . . . . 4
4. Units of identification . . . . . . . . . . . . . . . . . . . 4 4. Units of Identification . . . . . . . . . . . . . . . . . . . 4
5. Types of LSP . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Types of LSP . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Network Scope . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Network Scope . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 7 7. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 7
8. Dataplane . . . . . . . . . . . . . . . . . . . . . . . . . . 7 8. Data Plane . . . . . . . . . . . . . . . . . . . . . . . . . 7
9. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 8 9. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 9
10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 8 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9
11. Security Considerations . . . . . . . . . . . . . . . . . . . 9 11. Security Considerations . . . . . . . . . . . . . . . . . . . 9
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 13. Informative References . . . . . . . . . . . . . . . . . . . 10
14. Informative References . . . . . . . . . . . . . . . . . . . 9 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 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 MPLS is used for the encapsulation of user data packets. flows when MPLS is used to encapsulate 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,
depends on the use of injected Operations, Administration, and [RFC6374] depends on the use of injected Operations, Administration,
Maintenance (OAM) packets to designate the beginning and the end of and Maintenance (OAM) packets to designate the beginning and the end
the packet group over which packet loss is being measured. Where the of the packet group over which packet loss is being measured. If the
misordering of packets from one group relative to the following misordering of packets from one group relative to the following group
group, or misordering of one of the packets being counted relative to or the misordering of any of the packets being counted relative to
the [RFC6374] packet occurs, then an error will occur in the packet the Loss Measurement packet [RFC6374] occurs, then an error will
loss measurement. occur in the packet loss measurement.
In addition, [RFC6374] did not support different granularities of In addition, [RFC6374] did not support different granularities of
flow or address a number of multi-point cases in which two or more flow or address a number of multipoint cases in which two or more
ingress Label Switching Routers (LSRs) could send packets to one or ingress Label Switching Routers (LSRs) could send packets to one or
more destinations. more destinations.
Improvements in link and transmission technologies have made it more Due to the very low loss rate in normal operation, improvements in
difficult to assess packet loss using active performance measurement link and transmission technologies have made it more difficult to
methods with synthetic traffic, due to the very low loss rate in assess packet loss using active performance measurement methods with
normal operation. That, together with more demanding service level synthetic traffic. 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 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. will not take any active part in the measurement process. Indeed, it
Indeed it is important that any flow identification technique be is important that any flow identification technique be invisible to
invisible to them, and that no remnant of the measurement process them and that no remnant of the measurement process leaks into their
leaks into their network. network.
Additionally where there are multiple traffic sources, such as in Additionally, when there are multiple traffic sources, such as in
multi-point to point and multi-point to multi-point network multipoint-to-point and multipoint-to-multipoint 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 a multipoint measurement model needs to be developed.
developed.
2. Loss Measurement Considerations 2. Loss Measurement Considerations
Modern networks, if not oversubscribed, generally drop relatively few Modern networks, if not oversubscribed, generally drop relatively 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 [RFC8321] it may not be possible to achieve the required proposed in [RFC8321], it may not be possible to achieve the required
accuracy in the loss measurement of customer data traffic. Thus accuracy in the loss measurement of customer data traffic. Thus,
where accurate measurement of packet loss is required, it may be when accurate measurement of packet loss is required, it may be
economically advantageous, or even a technical requirement, to economically advantageous, or even be a technical requirement, to
include some form of marking in the packets to assign each packet to include some form of marking in the packets to assign 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 When 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 that 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:
1. The packets may traverse different sets of LSRs. 1. the packets may traverse different sets of LSRs;
2. The packets may depart from different interfaces on different 2. the packets may depart from different interfaces on different
line cards on LSRs. line cards on LSRs; and
3. The packets may arrive at different interfaces on different line 3. the packets may arrive at different interfaces on different line
cards on LSRs. cards on LSRs.
A consideration with this solution on modifying the identity label A consideration with this solution on modifying the identity label
(the MPLS label ordinarily used to identify the LSP, Virtual Private (the MPLS label ordinarily used to identify the LSP, Virtual Private
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. If 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 multipoint-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.
3. Delay Measurement Considerations 3. Delay Measurement Considerations
Most of the existing delay measurement methods are active methods 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,
interval between the injected packets may affect the accuracy of the and interval between the injected packets may affect the accuracy of
results. Due to ECMP (or link aggregation techniques) injected test the results. Due to ECMP (or link aggregation techniques), injected
packets may traverse different links from the ones used by the data test packets may traverse different links from the ones used by the
traffic. Thus there exists a requirement to measure the delay of the data traffic. Thus, measuring the delay of the real traffic is
real traffic. required.
For combined loss-delay measurements, both the loss and the delay For combined loss and delay measurements, both the loss and the delay
considerations apply. considerations apply.
4. 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
observations. In particular note that there may be a need to impose packet observations. In particular, note that there may be a need to
identity at several different layers of the MPLS label stack. impose identity at several different layers of the MPLS label stack.
This document considers following units of identifications: This document considers the identification of the following traffic
components:
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 a group of LSPs (e.g., all the 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: a 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. by some other element in the label stack. Such a fine-grained
Such fine-grained resolution may be possible by deep packet resolution may be possible by deep packet inspection. However, this
inspection. However, this may not always be possible, or it may be may not always be possible, or it may be desired to minimize
desired to minimize processing costs by doing this only on entry to processing costs by doing this only on entry to the network. Adding
the network. Adding a suitable identifier to the packet for a suitable identifier to the packet for reference by other network
reference by other network elements minumises the processing needed elements minimizes the processing needed by other network elements.
by other network elements. An example of such a fine grained case An example of such a fine-grained case might be traffic belonging to
might be traffic belonging to a certain service or from a specific a certain service or from a specific source, particularly if matters
source, particularly if matters related to service level agreement or related to service level agreement or application performance were
application performance were being investigated 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 6. 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
operating 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 an 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 specific to the application or use
and is out of scope of this document. case and are out of scope of this document.
5. 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-multipoint LSPs. The
The ingress LSR for a point to point LSP, such as those created using ingress LSR for a point-to-point LSP, such as those created using the
the Resource Reservation Protocol - Traffic Engineering (RSVP-TE) 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
of the top label in the stack, since at any provider-edge (PE) or inspection of the top label in the stack because, at any provider-
provider (P) router on the path this is unique to the ingress-egress edge (PE) or provider (P) router on the path, the top label is unique
pair at every hop at a given layer in the LSP hierarchy. Provided to the ingress-egress pair at every hop at a given layer in the LSP
that penultimate hop popping is disabled, the identity of the ingress hierarchy. Provided that Penultimate Hop Popping (PHP) is disabled,
LSR of a point to point LSP is available at the egress LSR and thus the identity of the ingress LSR of a point-to-point LSP is available
determining the identity of the ingress LSR must be regarded as a at the egress LSR; thus, determining the identity of the ingress LSR
solved problem. Note however that the identity of a flow cannot to must be regarded as a solved problem. Note, however, that the
be determined without further information being carried in the identity of a flow cannot to be determined without further
packet, or gleaned from some aspect of the packet payload. information being carried in the packet or gleaned from some aspect
of the packet payload.
In the case of a point to multi-point LSP, and in the absence of In the case of a point-to-multipoint LSP, and in the absence of PHP,
Penultimate Hop Popping (PHP) the identity of the ingress LSR may the identity of the ingress LSR may also be inferred from the top
also be inferred from the top label. However, it may not possible to label. However, it may not possible to adequately identify the flow
adequately identify the flow from the top label alone, and thus from the top label alone; thus, further information may need to be
further information may need to be carried in the packet, or gleaned carried in the packet or gleaned from some aspect of the packet
from some aspect of the packet payload. In designing any solution it payload. In designing any solution, it is desirable that a common
is desirable that a common flow identity solution be used for both flow identification solution be used for both point-to-point and
point to point and point to multi-point LSP types. Similarly it is point-to-multipoint LSP types. Similarly, it is desirable that a
desirable that a common method of LSP group identification be used. common method of LSP group identification be used. In the above
In the above cases, a context label [RFC5331] needs to be used to cases, a context label [RFC5331] needs to be used to provide the
provide the required identity information. This is widely supported required identity information. This is a widely supported MPLS
MPLS feature. feature.
A more interesting case is the case of a multi-point to point LSP. A more interesting case is the case of a multipoint-to-point LSP. In
In this case the same label is normally used by multiple ingress or this case, the same label is normally used by multiple ingress or
upstream LSRs and hence source identification is not possible by upstream LSRs; 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 4. 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 multipoint-to-multipoint 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; 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 4 by egress LSRs. The various identity types 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 multipoint-to-
point LSPs terminating on any common node. multipoint LSPs terminating on any common node.
6. 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 for an ingress LSR to seek 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.
7. 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 the 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 coexistence of LSRs that can
can, and cannot, identify the traffic components described in identify the traffic components described in Section 4 and those that
Section 4. In addition the identification of the traffic components cannot. In addition, the identification of the traffic components
described in Section 4 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-multipoint or a multipoint-to-
point LSP support the identification type in use so that a single multipoint LSP support the identification type in use so that a
packet can be correctly processed by all egress devices. The single 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.
8. Dataplane 8. Data Plane
There is a huge installed base of MPLS equipment, typically this type There is a huge installed base of MPLS equipment; typically, this
of equipment remains in service for an extended period of time, and type of equipment remains in service for an extended period of time,
in many cases hardware constraints mean that it is not possible to and in many cases, hardware constraints mean that it is not possible
upgrade its dataplane functionality. Changes to the MPLS data plane to upgrade its data-plane functionality. Changes to the MPLS data
are therefore expensive to implement, add complexity to the network, plane are therefore expensive to implement, add complexity to the
and may significantly impact the deployability of a solution that network, and may significantly impact the deployability of a solution
requires such changes. For these reasons, MPLS users have set a very that requires such changes. For these reasons, MPLS users have set a
high bar to changes to the MPLS data plane, and only a very small very high bar to changes to the MPLS data plane, and only a very
number have been adopted. Hence, it is important that the method of small number have been adopted. Hence, it is important that the
identification must minimize changes to the MPLS data plane. Ideally method of identification must minimize changes to the MPLS data
method(s) of identification that require no changes to the MPLS data plane. Ideally, method(s) of identification that require no changes
plane should be given preferential consideration. If a method of to the MPLS data plane should be given preferential consideration.
identification makes a change to the data plane is chosen it will If a method of identification that makes a change to the data plane
need to have a significant advantage over any method that makes no is chosen, it will need to have a significant advantage over any
change, and the advantage of the approach will need to be carefully method that makes no change, and the advantage of the approach will
evaluated and documented. If a change is necessary to the MPLS data need to be carefully evaluated and documented. If a change to the
plane proves necessary, it should be (a) be as small a change as MPLS data plane proves necessary, it should be (a) as small a change
possible and (b) be a general purpose method so as to maximize its as possible and (b) a general-purpose method, so as to maximize its
use for future applications. It is imperative that, as far as can be use for future applications. It is imperative that, as far as can be
foreseen, any necessary change made to the MPLS data plane does not foreseen, any necessary change made to the MPLS data plane does not
impose any foreseeable future limitation on the MPLS data plane. impose any foreseeable future limitation on the MPLS data plane.
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 in which 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 Pseudowire (PW) or similar multiplexing construct may be carried over
identification may be required at both layers. Of particular concern an LSP, and identification may be required at both layers. Of
is the implementation of low cost edge LSRs that for cost reasons particular concern is the implementation of low-cost edge LSRs that,
have a significant limit on the number of Label Stack Elements (LSEs) for cost reasons, have a significant limit on the number of Label
that they can impose or dispose. Therefore, any method of identity Stack Entries (LSEs) that they can impose or dispose. Therefore, any
must not consume an excessive number of unique labels, and must not method of identity must not consume an excessive number of unique
result in an excessive increase in the size of the label stack. labels and must not result in an excessive increase in the size of
the label stack.
The MPLS data plane design provides two types of special purpose The design of the MPLS data plane provides two types of special-
labels: the original 16 reserved labels and the much larger set of purpose labels: the original 16 reserved labels and the much larger
special purpose labels defined in [RFC7274]. The original reserved set of special-purpose labels defined in [RFC7274]. The original
labels need one LSE, and the newer [RFC7274] special purpose labels reserved labels need one LSE, and the newer special-purpose labels
need two LSEs. Given the tiny number of original reserved labels, it [RFC7274] need two LSEs. Given the tiny number of original reserved
is core to the MPLS design philosophy that this scarce resource is labels, it is core to the MPLS design philosophy that this scarce
only used when it is absolutely necessary. Using a single LSE resource is only used when it is absolutely necessary. Using a
reserved or special purpose label to encode flow identity thus special-purpose label to encode flow identity requires two label
requires two stack entries, one for the reserved label and one for stack entries, one for the reserved label and one for the flow
the flow identity. The larger set of [RFC7274] labels requires two identity. Use of extended special-purpose labels [RFC7274] requires
labels stack entries for the special purpose label itself and hence a a total of three label stack entries to encode the flow identity.
total of three label stack entries to encode the flow identity. The larger set of [RFC7274] labels requires two label stack entries
for the special-purpose label itself; hence, a total of three label
stack entries is needed to encode the flow identity.
The use of special purpose labels (SPL) [RFC7274] as part of a method The use of special-purpose labels [RFC7274] as part of a method to
to encode the identity information therefore has a number of encode the identity information therefore has a number of undesirable
undesirable implications for the data plane and hence whilst a implications for the data plane. Thus, while a solution may use
solution may use SPL(s), methods that do not require SPLs need to be special-purpose labels, methods that do not require special-purpose
carefully considered. labels need to be carefully considered.
9. Control Plane 9. Control Plane
Any flow identity design should both seek to minimise the complexity Any flow identity design should both seek to minimize the complexity
of the control plane and should minimise the amount of label co- of the control plane and minimize the amount of label coordination
ordination needed amongst LSRs. needed amongst LSRs.
10. 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.
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 Recent IETF concerns on pervasive monitoring [RFC7258] have resulted
implementing the flow identification feature. The choice of using in a preference for a solution that does not degrade the privacy of
MPLS technology for this OAM solution has a privacy advantage as the user traffic below that of an MPLS network not implementing the flow
choice of the label identifying a flow is limited to the scope of the identification feature. The choice of using MPLS technology for this
MPLS domain and does not have any dependency on the user data's OAM solution has a privacy advantage, as the choice of the label
identification. This minimizes the observability of the flow identifying a flow is limited to the scope of the MPLS domain and
characteristics. does not have any dependency on the identification of the user data.
This minimizes the observability of the flow characteristics.
11. Security Considerations 11. Security Considerations
Any solution to the flow identification needs must not degrade the Any flow identification solution must not degrade the security of the
security of the MPLS network below that of an equivalent network not MPLS network below that of an equivalent network not deploying the
deploying the specified identity solution. specified identity solution. In order to preserve present
In order to preserve present assumptions about MPLS privacy assumptions about MPLS privacy properties, propagation of
properties, propagation of identification information outside the identification information outside the MPLS network imposing it must
MPLS network imposing it must be disabled by default. Any solution be disabled by default. Any solution should provide for the
should provide for the restriction of the identity information to restriction of the identity information to those components of the
those components of the network that need to know it. It is thus network that need to know it. It is thus desirable to limit the
desirable to limit the knowledge of the identify of an endpoint to knowledge of the identify of an endpoint to only those LSRs that need
only those LSRs that need to participate in traffic flow. The choice to participate in traffic flow. The choice of using MPLS technology
of using MPLS technology for this OAM solution, with MPLS for this OAM solution, with MPLS encapsulation of user traffic,
encapsulation of user traffic, provides for a key advantage over provides for a key advantage over other data-plane solutions, as it
other data plane solutions, as it provides for a controlled access provides for a controlled access and trusted domain within a service
and trusted domain within a Service Provider's network. 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 "Security Framework for MPLS and
GMPLS Networks [RFC5920]. GMPLS Networks" [RFC5920].
12. IANA Considerations 12. IANA Considerations
This document has no IANA considerations. (At the discretion of the This document has no IANA considerations.
RFC Editor this section may be removed before publication).
13. Acknowledgments
The authors thank Nobo Akiya, Nagendra Kumar Nainar, George Swallow
and Deborah Brungard for their comments.
14. Informative References 13. Informative References
[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 39 skipping to change at page 11, line 5
and Retiring Special-Purpose MPLS Labels", RFC 7274, and Retiring Special-Purpose MPLS Labels", RFC 7274,
DOI 10.17487/RFC7274, June 2014, DOI 10.17487/RFC7274, June 2014,
<https://www.rfc-editor.org/info/rfc7274>. <https://www.rfc-editor.org/info/rfc7274>.
[RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli,
L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi,
"Alternate-Marking Method for Passive and Hybrid "Alternate-Marking Method for Passive and Hybrid
Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321,
January 2018, <https://www.rfc-editor.org/info/rfc8321>. January 2018, <https://www.rfc-editor.org/info/rfc8321>.
Acknowledgments
The authors thank Nobo Akiya, Nagendra Kumar Nainar, George Swallow,
and Deborah Brungard for their comments.
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, Inc.
Email: cpignata@cisco.com Email: cpignata@cisco.com
Mach Chen
Mach(Guoyi) Chen
Huawei Huawei
Email: mach.chen@huawei.com Email: mach.chen@huawei.com
Zhenbin Li Zhenbin Li
Huawei Huawei
Email: lizhenbin@huawei.com Email: lizhenbin@huawei.com
Gregory Mirsky Gregory Mirsky
 End of changes. 69 change blocks. 
238 lines changed or deleted 241 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/