draft-ietf-mpls-flow-ident-04.txt   draft-ietf-mpls-flow-ident-05.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: August 28, 2017 Cisco Systems Expires: January 28, 2018 Cisco Systems
M. Chen M. Chen
Z. Li Z. Li
Huawei Huawei
G. Mirsky G. Mirsky
ZTE Corp. ZTE Corp.
February 24, 2017 July 27, 2017
MPLS Flow Identification Considerations MPLS Flow Identification Considerations
draft-ietf-mpls-flow-ident-04 draft-ietf-mpls-flow-ident-05
Abstract Abstract
This memo discusses the aspects that must be considered when This memo discusses the aspects that must 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 user
data packets. data packets.
Status of This Memo Status of This Memo
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 August 28, 2017. This Internet-Draft will expire on January 28, 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 27 skipping to change at page 2, line 27
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 . . . . . . . . . . . . . . . . . . . . . . 9
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
15.1. Normative References . . . . . . . . . . . . . . . . . . 9 15.1. Normative References . . . . . . . . . . . . . . . . . . 10
15.2. Informative References . . . . . . . . . . . . . . . . . 10 15.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
This memo discusses the aspects that must be considered when This memo discusses the aspects that must 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 user
data packets. 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 applications
such as packet loss and packet delay measurement. A method of loss such as packet loss and packet delay measurement. A method of loss
skipping to change at page 3, line 39 skipping to change at page 3, line 39
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [RFC2119]. document are to be interpreted as described in RFC2119 [RFC2119].
3. Loss Measurement Considerations 3. Loss Measurement Considerations
Modern networks, if not oversubscribed, potentially drop relatively Modern networks, if not oversubscribed, potentially drop relatively
few packets, thus packet loss measurement is highly sensitive to the few packets, thus packet loss measurement is highly sensitive to the
common demarcation of the exact set of packets to be measured for common demarcation of the exact set of packets to be measured for
loss. Without some form of coloring or batch marking such as that loss. Without some form of coloring or batch marking such as that
proposed in [I-D.tempia-ippm-p3m] it may not be possible to achieve proposed in [I-D.ietf-ippm-alt-mark] it may not be possible to
the required accuracy in the loss measurement of customer data achieve the required accuracy in the loss measurement of customer
traffic. Thus where accurate measurement of packet loss is required, data traffic. Thus where accurate measurement of packet loss is
it may be economically advantageous, or even a technical requirement, required, it may be economically advantageous, or even a technical
to include some form of marking in the packets to assign each packet requirement, to include some form of marking in the packets to assign
to a particular counter for loss measurement purposes. each packet to a particular counter for loss measurement purposes.
Where this level of accuracy is required and the traffic between a Where this level of accuracy is required and the traffic between a
source-destination pair is subject to Equal-Cost Multipath (ECMP) a source-destination pair is subject to Equal-Cost Multipath (ECMP) a
demarcation mechanism is needed to group the packets into batches. demarcation mechanism is needed to group the packets into batches.
Once a batch is correlated at both ingress and egress, the packet Once a batch is correlated at both ingress and egress, the packet
accounting mechanism is then able to operate on the batch of packets accounting mechanism is then able to operate on the batch of packets
which can be accounted for at both the packet ingress and the packet which can be accounted for at both the packet ingress and the packet
egress. Errors in the accounting are particularly acute in Label egress. Errors in the accounting are particularly acute in Label
Switched Paths (LSPs) subjected to ECMP because the network transit Switched Paths (LSPs) subjected to ECMP because the network transit
time will be different for the various ECMP paths since: time will be different for the various ECMP paths since:
skipping to change at page 9, line 36 skipping to change at page 9, line 36
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.
13. IANA Considerations 13. IANA Considerations
This memo has no IANA considerations. This memo has no IANA requests.
(At the discression of the RFC Editor this section may be removed
after publication)
14. Acknowledgements 14. Acknowledgements
The authors thank Nobo Akiya (nobo@cisco.com), Nagendra Kumar Nainar The authors thank Nobo Akiya (nobo@cisco.com), Nagendra Kumar Nainar
(naikumar@cisco.com) and George Swallow (swallow@cisco.com) for their (naikumar@cisco.com) and George Swallow (swallow@cisco.com) 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,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
15.2. Informative References 15.2. Informative References
[I-D.tempia-ippm-p3m] [I-D.ietf-ippm-alt-mark]
Capello, A., Cociglio, M., Fioccola, G., Castaldelli, L., Fioccola, G., Capello, A., Cociglio, M., Castaldelli, L.,
and A. Bonda, "A packet based method for passive Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi,
performance monitoring", draft-tempia-ippm-p3m-03 (work in "Alternate Marking method for passive and hybrid
progress), March 2016. performance monitoring", draft-ietf-ippm-alt-mark-06 (work
in progress), July 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>. <http://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,
 End of changes. 10 change blocks. 
19 lines changed or deleted 22 lines changed or added

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