--- 1/draft-ietf-mpls-flow-ident-05.txt 2017-12-14 11:13:28.211489889 -0800 +++ 2/draft-ietf-mpls-flow-ident-06.txt 2017-12-14 11:13:28.235490452 -0800 @@ -1,48 +1,48 @@ MPLS Working Group S. Bryant Internet-Draft Huawei Intended status: Informational C. Pignataro -Expires: January 28, 2018 Cisco Systems +Expires: June 17, 2018 Cisco Systems M. Chen Z. Li Huawei G. Mirsky ZTE Corp. - July 27, 2017 + December 14, 2017 MPLS Flow Identification Considerations - draft-ietf-mpls-flow-ident-05 + draft-ietf-mpls-flow-ident-06 Abstract - This memo discusses the aspects that must be considered when - developing a solution for MPLS flow identification. The key - application that needs this is in-band performance monitoring of user - data packets. + This document discusses the aspects that need to be be considered + when developing a solution for MPLS flow identification. The key + application that needs this is in-band performance monitoring of MPLS + flows when MPLS is used to encapsulate user data packets. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on January 28, 2018. + This Internet-Draft will expire on June 17, 2018. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -60,62 +60,62 @@ 4. Delay Measurement Considerations . . . . . . . . . . . . . . 4 5. Units of identification . . . . . . . . . . . . . . . . . . . 4 6. Types of LSP . . . . . . . . . . . . . . . . . . . . . . . . 6 7. Network Scope . . . . . . . . . . . . . . . . . . . . . . . . 7 8. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 7 9. Dataplane . . . . . . . . . . . . . . . . . . . . . . . . . . 7 10. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 9 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9 12. Security Considerations . . . . . . . . . . . . . . . . . . . 9 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 - 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 - 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 + 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 + 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 15.1. Normative References . . . . . . . . . . . . . . . . . . 10 15.2. Informative References . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 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 - application that needs this is in-band performance monitoring of user - data packets. + application that needs this is in-band performance monitoring of MPLS + flows when MPL is used for the encapsulation of user data packets. - There is a need to identify flows in MPLS networks for applications - such as packet loss and packet delay measurement. A method of loss - and delay measurement in MPLS networks was defined in [RFC6374]. - When used to measure packet loss [RFC6374] depends on the use of the - injected Operations, Administration, and Maintenance (OAM) packets to - designate the beginning and the end of the packet group over which - packet loss is being measured. Where the misordering of packets from - one group relative to the following group, or misordering of one of - the packets being counted relative to the [RFC6374] packet occurs, - then an error will occur in the packet loss measurement. + There is a need to identify flows in MPLS networks for various + applications such as determining packet loss and packet delay + measurement. A method of loss and delay measurement in MPLS networks + was defined in [RFC6374]. When used to measure packet loss [RFC6374] + depends on the use of injected Operations, Administration, and + Maintenance (OAM) packets to designate the beginning and the end of + the packet group over which packet loss is being measured. Where the + misordering of packets from one group relative to the following + group, or misordering of one of the packets being counted relative to + the [RFC6374] packet occurs, then an error will occur in the packet + loss measurement. - In addition, this packet performance measurement system needs to be - extended to deal with different granularities of flow and to address - a number of the multi-point cases in which two or more ingress Label - Switching Routers (LSRs) could send packets to one or more - destinations. + In addition, [RFC6374] did not support different granularities of + flow or address a number of multi-point cases in which two or more + ingress Label Switching Routers (LSRs) could send packets to one or + more destinations. - Improvements in link and transmission technologies mean that it may - be difficult to assess packet loss using active performance - measurement methods with synthetic traffic, due to the very low loss - rate in normal operation. That, together with more demanding service - level requirements, mean that network operators need to be able to + Improvements in link and transmission technologies have made it more + difficult to assess packet loss using active performance measurement + methods with synthetic traffic, due to the very low loss rate in + normal operation. That, together with more demanding service level + requirements, means that network operators now need to be able to measure the loss of the actual user data traffic by using passive performance measurement methods. Any technique deployed needs to be 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 is important that any flow identification technique be invisible to 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 multi-point to point and multi-point to multi-point network environments there needs to be a method whereby the sink can distinguish between packets from the various sources, that is to say, that a multi-point to multi-point measurement model needs to be developed. 2. Requirements Language @@ -147,27 +147,27 @@ time will be different for the various ECMP paths since: 1. The packets may traverse different sets of LSRs. 2. The packets may depart from different interfaces on different line cards on LSRs. 3. The packets may arrive at different interfaces on different line cards on LSRs. - A consideration in modifying the identity label (the MPLS label - ordinarily used to identify the LSP, Virtual Private Network, - Pseudowire etc) to indicate the batch is the impact that 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 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 + A consideration with this solution on modifying the identity label + (the MPLS label ordinarily used to identify the LSP, Virtual Private + Network, Pseudowire etc) to indicate the batch is the impact that + 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 + 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 entropy label [RFC6790] then changing the batch identifier will not 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 accounting errors introduced by ECMP needs to be supported. 4. Delay Measurement Considerations Most of the existing delay measurement methods are active measurement that depend on the extra injected test packet to evaluate the delay of a path. With the active measurement method, the rate, numbers and @@ -229,21 +229,21 @@ o In order to conserve resources such as labels, counters and/or compute cycles it may be desirable to identify an LSP group so 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 necessary when investigating a specific flow that has been aggregated into an LSP. The unit of identification and the method of determining which 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 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. The ingress LSR for a point to point LSP, such as those created using the Resource Reservation Protocol - Traffic Engineering (RSVP-TE) [RFC5420] Signaling protocol, or those that conform to the MPLS Transport Profile (MPLS-TP) [RFC5654] may be identified by inspection of the top label in the stack, since at any provider-edge (PE) or @@ -281,77 +281,75 @@ source identification is not possible by inspection of the top label by egress LSRs. The various types of identity described in Section 5 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- point LSPs terminating on any common node. 7. Network Scope The scope of identification can be constrained to the set of flows that are uniquely identifiable at an ingress LSR, or some aggregation - thereof. There is no question of an ingress LSR seeking assistance - from outside the MPLS protocol domain. + thereof. There is no need of an ingress LSR seeking assistance from + outside the MPLS protocol domain. In any solution that constrains itself to carrying the required identity in the MPLS label stack rather than in some different - associated data structure, constraints on the label stack size imply - that the scope of identity reside within that MPLS domain. For - similar reasons the identity scope of a component of an LSP should be - constrained to the scope of that LSP. + associated data structure, constraints on the choice of label and + label stack size imply that the scope of identity resides within that + MPLS domain. For similar reasons the identity scope of a component + of an LSP is constrained to the scope of that LSP. 8. Backwards Compatibility In any network it is unlikely that all LSRs will have the same capability to support the methods of identification discussed in this - memo. It is therefore an important constraint on any flow identity - solution that it is backwards compatible with deployed MPLS equipment - to the extent that deploying the new feature will not disable - anything that currently works on a legacy equipment. + document. It is therefore an important constraint on any flow + identity solution that it is backwards compatible with deployed MPLS + equipment to the extent that deploying the new feature will not + disable anything that currently works on a legacy equipment. 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 - broad the flow identification design MUST support the co-existence of - both LSRs that can, and cannot, identify the traffic components - described in Section 5. In addition the identification of the - traffic components described in Section 5 MUST be an optional feature - that is disabled 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-point LSP support the identification type in - use so that a single packet can be correctly processed by all egress - devices. The corollary of this last point is that either all egress - LSRs are enabled to support the required identity type, or none of - them are. + 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 + can, and cannot, identify the traffic components described in + Section 5. In addition the identification of the traffic components + described in Section 5 MUST be an optional feature that is disabled + 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- + point LSP support the identification type in use so that a single + packet can be correctly processed by all egress devices. The + corollary of this last point is that either all egress LSRs are + enabled to support the required identity type, or none of them are. 9. Dataplane There is a huge installed base of MPLS equipment, typically this type of equipment remains in service for an extended period of time, and in many cases hardware constraints mean that it is not possible to upgrade its dataplane functionality. Changes to the MPLS data plane are therefore expensive to implement, add complexity to the network, and may significantly impact the deployability of a solution that - requires such changes. For these reasons, the MPLS designers have - set a very 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 identification must minimize changes to the MPLS data - plane. Ideally method(s) of identification that require no changes - to the MPLS data plane should be given preferential consideration. - If a method of identification makes a change to the data plane is - chosen it will need to have a significant advantage over any method - that makes no change, and the advantage of the approach will need to - be carefully evaluated and documented. If a change is necessary to - the MPLS data plane proves necessary, it should be (a) be as small a - change as possible and (b) be a general purpose method so as to - maximize its 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 impose any foreseeable future limitation on the MPLS - data plane. + 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 + number have been adopted. Hence, it is important that the method of + identification must minimize changes to the MPLS data plane. Ideally + method(s) of identification that require no changes to the MPLS data + plane should be given preferential consideration. If a method of + identification makes a change to the data plane is chosen it will + need to have a significant advantage over any method that makes no + change, and the advantage of the approach will need to be carefully + evaluated and documented. If a change is necessary to the MPLS data + plane proves necessary, it should be (a) be as small a change as + possible and (b) be a general purpose method so as to maximize its + 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 + impose any foreseeable future limitation on the MPLS data plane. Stack size is an issue with many MPLS implementations both as a result of hardware limitations, and due to the impact on networks and applications where a large number of small payloads need to be transported In particular one MPLS payload may be carried inside 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 identification may be required at both layers. Of particular concern is the implementation of low cost edge LSRs that for cost reasons have a significant limit on the number of Label Stack Elements (LSEs) @@ -384,100 +382,113 @@ of the control plane and should minimise the amount of label co- ordination needed amongst LSRs. 11. Privacy Considerations The inclusion of originating and/or flow information in a packet provides more identity information and hence potentially degrades the privacy of the communication. Recent IETF concerns on pervasive 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 - implementing the flow identification feature. The minimizing the - scope of the identity indication can be useful in minimizing the - observability of the flow characteristics. + implementing the flow identification feature. The choice of using + 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 + 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 Any solution to the flow identification needs must not degrade the security of the MPLS network below that of an equivalent network not deploying the specified identity solution. Propagation of identification information outside the MPLS network imposing it must be disabled by default. Any solution should provide for the restriction of the identity information to those components of 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 - 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 - after publication) + This document has no IANA considerations. (At the discression of the + RFC Editor this section may be removed before publication). 14. Acknowledgements - The authors thank Nobo Akiya (nobo@cisco.com), Nagendra Kumar Nainar - (naikumar@cisco.com) and George Swallow (swallow@cisco.com) for their - comments. + The authors thank Nobo Akiya, Nagendra Kumar Nainar, George Swallow + and Deborah Brungard for their comments. 15. 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, - . + DOI 10.17487/RFC2119, March 1997, . 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-06 (work - in progress), July 2017. + performance monitoring", draft-ietf-ippm-alt-mark-14 (work + in progress), December 2017. [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream Label Assignment and Context-Specific Label Space", RFC 5331, DOI 10.17487/RFC5331, August 2008, - . + . [RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and A. Ayyangarps, "Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)", RFC 5420, DOI 10.17487/RFC5420, - February 2009, . + February 2009, . [RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., Sprecher, N., and S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, DOI 10.17487/RFC5654, - September 2009, . + September 2009, . + + [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS + Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, + . [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay Measurement for MPLS Networks", RFC 6374, - DOI 10.17487/RFC6374, September 2011, - . + DOI 10.17487/RFC6374, September 2011, . [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and L. Yong, "The Use of Entropy Labels in MPLS Forwarding", RFC 6790, DOI 10.17487/RFC6790, November 2012, - . + . [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May - 2014, . + 2014, . [RFC7274] Kompella, K., Andersson, L., and A. Farrel, "Allocating and Retiring Special-Purpose MPLS Labels", RFC 7274, - DOI 10.17487/RFC7274, June 2014, - . + DOI 10.17487/RFC7274, June 2014, . Authors' Addresses Stewart Bryant Huawei Email: stewart.bryant@gmail.com Carlos Pignataro Cisco Systems