draft-ietf-mpls-flow-ident-05.txt   draft-ietf-mpls-flow-ident-06.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: January 28, 2018 Cisco Systems Expires: June 17, 2018 Cisco Systems
M. Chen M. Chen
Z. Li Z. Li
Huawei Huawei
G. Mirsky G. Mirsky
ZTE Corp. ZTE Corp.
July 27, 2017 December 14, 2017
MPLS Flow Identification Considerations MPLS Flow Identification Considerations
draft-ietf-mpls-flow-ident-05 draft-ietf-mpls-flow-ident-06
Abstract Abstract
This memo discusses the aspects that must be considered when This document discusses the aspects that need to be be considered
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 user application that needs this is in-band performance monitoring of MPLS
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 http://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 January 28, 2018. This Internet-Draft will expire on June 17, 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 25 skipping to change at page 2, line 25
4. Delay Measurement Considerations . . . . . . . . . . . . . . 4 4. Delay Measurement Considerations . . . . . . . . . . . . . . 4
5. Units of identification . . . . . . . . . . . . . . . . . . . 4 5. Units of identification . . . . . . . . . . . . . . . . . . . 4
6. Types of LSP . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Types of LSP . . . . . . . . . . . . . . . . . . . . . . . . 6
7. Network Scope . . . . . . . . . . . . . . . . . . . . . . . . 7 7. Network Scope . . . . . . . . . . . . . . . . . . . . . . . . 7
8. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 7 8. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 7
9. Dataplane . . . . . . . . . . . . . . . . . . . . . . . . . . 7 9. Dataplane . . . . . . . . . . . . . . . . . . . . . . . . . . 7
10. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 9 10. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 9
11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9
12. Security Considerations . . . . . . . . . . . . . . . . . . . 9 12. Security Considerations . . . . . . . . . . . . . . . . . . . 9
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
15.1. Normative References . . . . . . . . . . . . . . . . . . 10 15.1. Normative References . . . . . . . . . . . . . . . . . . 10
15.2. Informative References . . . . . . . . . . . . . . . . . 10 15.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
This memo discusses the aspects that must 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 user application that needs this is in-band performance monitoring of MPLS
data packets. flows when MPL is used for the encapsulation of user data packets.
There is a need to identify flows in MPLS networks for applications There is a need to identify flows in MPLS networks for various
such as packet loss and packet delay measurement. A method of loss applications such as determining packet loss and packet delay
and delay measurement in MPLS networks was defined in [RFC6374]. measurement. A method of loss and delay measurement in MPLS networks
When used to measure packet loss [RFC6374] depends on the use of the was defined in [RFC6374]. When used to measure packet loss [RFC6374]
injected Operations, Administration, and Maintenance (OAM) packets to depends on the use of injected Operations, Administration, and
designate the beginning and the end of the packet group over which Maintenance (OAM) packets to designate the beginning and the end of
packet loss is being measured. Where the misordering of packets from the packet group over which packet loss is being measured. Where the
one group relative to the following group, or misordering of one of misordering of packets from one group relative to the following
the packets being counted relative to the [RFC6374] packet occurs, group, or misordering of one of the packets being counted relative to
then an error will occur in the packet loss measurement. the [RFC6374] packet occurs, then an error will occur in the packet
loss measurement.
In addition, this packet performance measurement system needs to be In addition, [RFC6374] did not support different granularities of
extended to deal with different granularities of flow and to address flow or address a number of multi-point cases in which two or more
a number of the multi-point cases in which two or more ingress Label ingress Label Switching Routers (LSRs) could send packets to one or
Switching Routers (LSRs) could send packets to one or more more destinations.
destinations.
Improvements in link and transmission technologies mean that it may Improvements in link and transmission technologies have made it more
be difficult to assess packet loss using active performance difficult to assess packet loss using active performance measurement
measurement methods with synthetic traffic, due to the very low loss methods with synthetic traffic, due to the very low loss rate in
rate in normal operation. That, together with more demanding service normal operation. That, together with more demanding service level
level requirements, mean that network operators 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. Indeed it
is important that any flow identification technique be invisible to is important that any flow identification technique be invisible to
them and that no remnant of the identification of measurement process them and that no remnant of the identification of measurement process
leak into their network. leaked 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. Requirements Language
skipping to change at page 4, line 16 skipping to change at page 4, line 16
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.
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 in modifying the identity label (the MPLS label A consideration with this solution on modifying the identity label
ordinarily used to identify the LSP, Virtual Private Network, (the MPLS label ordinarily used to identify the LSP, Virtual Private
Pseudowire etc) to indicate the batch is the impact that this has on Network, Pseudowire etc) to indicate the batch is the impact that
the path chosen by the ECMP mechanism. When the member of the ECMP this has on the path chosen by the ECMP mechanism. When the member
path set is chosen by deep packet inspection a change of batch of the ECMP path set is chosen by deep packet inspection a change of
represented by a change of identity label will have no impact on the batch represented by a change of identity label will have no impact
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 4. Delay Measurement Considerations
Most of the existing delay measurement methods are active measurement Most of the existing delay measurement methods are active measurement
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
skipping to change at page 5, line 50 skipping to change at page 5, line 50
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 memo. and is out of scope of this document.
6. Types of LSP 6. 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
skipping to change at page 7, line 9 skipping to change at page 7, line 9
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 5
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 7. 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 question of an ingress LSR seeking assistance thereof. There is no need of an ingress LSR seeking assistance from
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 label stack size imply associated data structure, constraints on the choice of label and
that the scope of identity reside within that MPLS domain. For label stack size imply that the scope of identity resides within that
similar reasons the identity scope of a component of an LSP should be MPLS domain. For similar reasons the identity scope of a component
constrained to the scope of that LSP. of an LSP is constrained to the scope of that LSP.
8. Backwards Compatibility 8. 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
memo. It is therefore an important constraint on any flow identity document. It is therefore an important constraint on any flow
solution that it is backwards compatible with deployed MPLS equipment identity solution that it is backwards compatible with deployed MPLS
to the extent that deploying the new feature will not disable equipment to the extent that deploying the new feature will not
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
when the feature is not required for all LSRs or all LSPs. Thus in the feature is not required for all LSRs or all LSPs. Thus, the flow
broad the flow identification design MUST support the co-existence of identification design MUST support the co-existence of both LSRs that
both LSRs that can, and cannot, identify the traffic components can, and cannot, identify the traffic components described in
described in Section 5. In addition the identification of the Section 5. In addition the identification of the traffic components
traffic components described in Section 5 MUST be an optional feature described in Section 5 MUST be an optional feature that is disabled
that is disabled by default. As a design simplification, a solution by default. As a design simplification, a solution MAY require that
MAY require that all egress LSRs of a point to multi-point or a all egress LSRs of a point to multi-point or a multi- point to multi-
multi- point to multi-point LSP support the identification type in point LSP support the identification type in use so that a single
use so that a single packet can be correctly processed by all egress packet can be correctly processed by all egress devices. The
devices. The corollary of this last point is that either all egress corollary of this last point is that either all egress LSRs are
LSRs are enabled to support the required identity type, or none of enabled to support the required identity type, or none of them are.
them are.
9. Dataplane 9. 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, the MPLS designers have requires such changes. For these reasons, MPLS users have set a very
set a very high bar to changes to the MPLS data plane, and only a high bar to changes to the MPLS data plane, and only a very small
very small number have been adopted. Hence, it is important that the number have been adopted. Hence, it is important that the method of
method of identification must minimize changes to the MPLS data identification must minimize changes to the MPLS data plane. Ideally
plane. Ideally method(s) of identification that require no changes method(s) of identification that require no changes to the MPLS data
to the MPLS data plane should be given preferential consideration. plane should be given preferential consideration. If a method of
If a method of identification makes a change to the data plane is identification makes a change to the data plane is chosen it will
chosen it will need to have a significant advantage over any method need to have a significant advantage over any method that makes no
that makes no change, and the advantage of the approach will need to change, and the advantage of the approach will need to be carefully
be carefully evaluated and documented. If a change is necessary to evaluated and documented. If a change is necessary to the MPLS data
the MPLS data plane proves necessary, it should be (a) be as small a plane proves necessary, it should be (a) be as small a change as
change as possible and (b) be a general purpose method so as to possible and (b) be a general purpose method so as to maximize its
maximize its use for future applications. It is imperative that, as use for future applications. It is imperative that, as far as can be
far as can be foreseen, any necessary change made to the MPLS data foreseen, any necessary change made to the MPLS data plane does not
plane does not impose any foreseeable future limitation on the MPLS impose any foreseeable future limitation on the MPLS data plane.
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 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)
skipping to change at page 9, line 18 skipping to change at page 9, line 18
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 11. 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 minimizing the implementing the flow identification feature. The choice of using
scope of the identity indication can be useful in minimizing the MPLS technology for this OAM solution has a privacy advantage as the
observability of the flow characteristics. 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
identification. This minimizes the observability of the flow
characteristics.
12. Security Considerations 12. 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. Propagation of
identification information outside the MPLS network imposing it must identification information outside the MPLS network imposing it must
be disabled by default. Any solution should provide for the be disabled by default. Any solution should provide for the
restriction of the identity information to those components of the restriction of the identity information to those components of the
network that need to know it. It is thus desirable to limit the network that need to know it. It is thus desirable to limit the
knowledge of the identify of an endpoint to only those LSRs that need knowledge of the identify of an endpoint to only those LSRs that need
to participate in traffic flow. to participate in traffic flow. The choice of using MPLS technology
for this OAM solution, with MPLS encapsulation of user traffic,
provides for a key advantage over other data plane solutions, as it
provides for a controlled access and trusted domain within a Service
Provider's network.
13. IANA Considerations For a more comprehensive discussion of MPLS security and attack
mitigation techniques, please see the Security Framework for MPLS and
GMPLS Networks [RFC5920].
This memo has no IANA requests. 13. IANA Considerations
(At the discression of the RFC Editor this section may be removed This document has no IANA considerations. (At the discression of the
after publication) RFC Editor this section may be removed before publication).
14. Acknowledgements 14. Acknowledgements
The authors thank Nobo Akiya (nobo@cisco.com), Nagendra Kumar Nainar The authors thank Nobo Akiya, Nagendra Kumar Nainar, George Swallow
(naikumar@cisco.com) and George Swallow (swallow@cisco.com) for their and Deborah Brungard for their comments.
comments.
15. References 15. References
15.1. Normative References 15.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc2119>. editor.org/info/rfc2119>.
15.2. Informative References 15.2. Informative References
[I-D.ietf-ippm-alt-mark] [I-D.ietf-ippm-alt-mark]
Fioccola, G., Capello, A., Cociglio, M., Castaldelli, L., Fioccola, G., Capello, A., Cociglio, M., Castaldelli, L.,
Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 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", draft-ietf-ippm-alt-mark-06 (work performance monitoring", draft-ietf-ippm-alt-mark-14 (work
in progress), July 2017. 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,
<http://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,
February 2009, <http://www.rfc-editor.org/info/rfc5420>. February 2009, <https://www.rfc-editor.org/info/rfc5420>.
[RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., [RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed.,
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, <http://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
Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010,
<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, DOI 10.17487/RFC6374, September 2011, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc6374>. 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,
<http://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, <http://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, DOI 10.17487/RFC7274, June 2014, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc7274>. editor.org/info/rfc7274>.
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. 34 change blocks. 
105 lines changed or deleted 116 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/