draft-ietf-mpls-flow-ident-01.txt   draft-ietf-mpls-flow-ident-02.txt 
MPLS S. Bryant MPLS Working Group S. Bryant
Internet-Draft Independent Internet-Draft M. Chen
Intended status: Informational C. Pignataro Intended status: Informational Z. Li
Expires: December 12, 2016 Cisco Systems Expires: February 26, 2017 Huawei
M. Chen C. Pignataro
Z. Li Cisco Systems
Huawei
G. Mirsky G. Mirsky
Ericsson Ericsson
June 10, 2016 August 25, 2016
MPLS Flow Identification Considerations MPLS Flow Identification Considerations
draft-ietf-mpls-flow-ident-01 draft-ietf-mpls-flow-ident-02
Abstract Abstract
This memo discusses the desired capabilities for MPLS flow This memo discusses the desired capabilities for MPLS flow
identification. The key application that needs this is in-band identification. The key application that needs this is in-band
performance monitoring of user data packets. performance monitoring of 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
skipping to change at page 1, line 38 skipping to change at page 1, line 37
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 December 12, 2016. This Internet-Draft will expire on February 26, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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 3, line 29 skipping to change at page 3, line 29
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
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]. document are to be interpreted as described in RFC2119 [RFC2119].
3. Loss Measurement Considerations 3. Loss Measurement Considerations
Modern networks, if not oversubscribed, normally drop very few Modern networks, if not oversubscribed, normally drop very few
packets, thus packet loss measurement is highly sensitive to counter packets, thus packet loss measurement is highly sensitive to counter
errors. Without some form of coloring or batch marking such as that errors. 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.tempia-ippm-p3m] it may not be possible to achieve
the required accuracy in the loss measurement of customer data the required accuracy in the loss measurement of customer data
traffic. Thus where accuracy better than the data link loss traffic. Thus where accuracy better than the data link loss
performance of a modern optical network is required, it may be performance of a modern optical network is required, it may be
skipping to change at page 4, line 5 skipping to change at page 4, line 5
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:
a. The packets may traverse different sets of LSRs. 1. The packets may traverse different sets of LSRs.
b. 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
c. 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 in modifying the identity label (the MPLS label
ordinarily used to identify the LSP, Virtual Private Network, ordinarily used to identify the LSP, Virtual Private Network,
Pseudowire etc) to indicate the batch is the impact that this has on 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 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 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 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 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
skipping to change at page 10, line 38 skipping to change at page 10, line 38
2014, <http://www.rfc-editor.org/info/rfc7258>. 2014, <http://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,
<http://www.rfc-editor.org/info/rfc7274>. <http://www.rfc-editor.org/info/rfc7274>.
Authors' Addresses Authors' Addresses
Stewart Bryant Stewart Bryant
Independent Huawei
Email: stewart.bryant@gmail.com Email: stewart.bryant@gmail.com
Carlos Pignataro
Cisco Systems
Email: cpignata@cisco.com
Mach Chen Mach 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
Carlos Pignataro
Cisco Systems
Email: cpignata@cisco.com
Gregory Mirsky Gregory Mirsky
Ericsson Ericsson
Email: gregory.mirsky@ericsson.com Email: gregory.mirsky@eicsson.com
 End of changes. 13 change blocks. 
20 lines changed or deleted 19 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/