Skip to main content

Packet Loss and Delay Measurement for MPLS Networks
RFC 6374

Revision differences

Document history

Date Rev. By Action
2020-01-21
04 (System) Received changes through RFC Editor sync (added Verified Errata tag)
2016-11-30
04 (System) Closed request for Last Call review by TSVDIR with state 'Unknown'
2015-10-14
04 (System) Notify list changed from mpls-chairs@ietf.org, draft-ietf-mpls-loss-delay@ietf.org to (None)
2014-09-19
(System) Posted related IPR disclosure: Huawei Technologies Co.,Ltd's Statement about IPR related to RFC 6374
2012-08-22
04 (System) post-migration administrative database adjustment to the No Objection position for Sean Turner
2012-08-22
04 (System) post-migration administrative database adjustment to the Yes position for Dan Romascanu
2012-08-22
04 (System) post-migration administrative database adjustment to the No Objection position for Stephen Farrell
2012-08-22
04 (System) post-migration administrative database adjustment to the No Objection position for Wesley Eddy
2012-08-22
04 (System) post-migration administrative database adjustment to the Yes position for Adrian Farrel
2011-09-21
04 Amy Vezza State changed to RFC Published from RFC Ed Queue.
2011-09-18
04 (System) RFC published
2011-08-08
04 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2011-08-08
04 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2011-08-08
04 (System) IANA Action state changed to In Progress from Waiting on Authors
2011-08-05
04 (System) IANA Action state changed to Waiting on Authors from In Progress
2011-08-05
04 (System) IANA Action state changed to In Progress from Waiting on Authors
2011-08-04
04 (System) IANA Action state changed to Waiting on Authors from In Progress
2011-08-04
04 (System) IANA Action state changed to In Progress from Waiting on Authors
2011-08-04
04 Amy Vezza State changed to RFC Ed Queue from Approved-announcement sent.
2011-08-03
04 (System) IANA Action state changed to Waiting on Authors from In Progress
2011-08-03
04 (System) IANA Action state changed to In Progress
2011-08-03
04 Cindy Morgan IESG state changed to Approved-announcement sent
2011-08-03
04 Cindy Morgan IESG has approved the document
2011-08-03
04 Cindy Morgan Closed "Approve" ballot
2011-08-03
04 Cindy Morgan State changed to Approved-announcement to be sent from Waiting for AD Go-Ahead.
2011-08-03
04 Adrian Farrel [Ballot Position Update] Position for Adrian Farrel has been changed to Yes from Discuss
2011-08-01
04 (System) State changed to Waiting for AD Go-Ahead from In Last Call.
2011-07-20
04 Adrian Farrel Approval announcement text changed
2011-07-20
04 Adrian Farrel Approval announcement text regenerated
2011-07-20
04 Adrian Farrel Ballot writeup text changed
2011-07-20
04 Sean Turner [Ballot Position Update] Position for Sean Turner has been changed to No Objection from Discuss
2011-07-19
04 Wesley Eddy [Ballot comment]
my DISCUSS comments are cleared
2011-07-19
04 Wesley Eddy [Ballot Position Update] Position for Wesley Eddy has been changed to No Objection from Discuss
2011-07-19
04 Dan Romascanu [Ballot Position Update] Position for Dan Romascanu has been changed to Yes from Discuss
2011-07-19
04 Stephen Farrell
[Ballot comment]
(1) Section 2 as a whole is very wordy. While its fine to spell things
out for clarity, this text perhaps demands too …
[Ballot comment]
(1) Section 2 as a whole is very wordy. While its fine to spell things
out for clarity, this text perhaps demands too little from the reader,
at the expense of clarity for the capable reader. (In other words, this
seems just too long:-) Feel free to entirely ignore this comment
though.

(2) The "(B1,...,Bk)" notation isn't clear in 2.6 - are we measuring
(A,B1) and (A,B2) etc. or are we measuring what happens on the path from
A to Bk via B1,B2...etc.? Since the section is about unidirectional LSPs
it may be easier to just deal with A and B here.

(3) (2.9.3) Saying that the detailed measurement behavaiour "MUST be
made clear to the user" seems wrong in two respects - a) a programmer
won't know what'll be clear to all future users of their code, and b)
there may be no (human) user that can see the direct mesurements, (the
humans might only see derived statistics I guess). I also don't quite
know how I'd test for that MUST. Maybe just loose the 2119 language
there?

(4) 2.9.5 assumes that intermediate nodes can reply to LM/DM messages,
but that hasn't yet been stated.

(5) Two timestamp formats are supported - would be good to include
examples of each at the point where that's first mentioned in detail.
2011-07-19
04 Stephen Farrell
[Ballot discuss]
This is just a discuss to check if the chat arising from Steve
Kent's secdir review [1] reached closure. The discussion seemed
to …
[Ballot discuss]
This is just a discuss to check if the chat arising from Steve
Kent's secdir review [1] reached closure. The discussion seemed
to tail off a bit and I'm not clear if it was done or not.

  [1] http://www.ietf.org/mail-archive/web/secdir/current/msg02727.html
2011-07-19
04 Stephen Farrell [Ballot Position Update] Position for Stephen Farrell has been changed to No Objection from Discuss
2011-07-19
04 Adrian Farrel [Ballot discuss]
This Discuss is just to hold the document while the third IETF last call completes. (Last call made necessary to resolve IPR issues)
2011-07-19
04 (System) New version available: draft-ietf-mpls-loss-delay-04.txt
2011-07-18
04 Amy Vezza Last call sent
2011-07-18
04 Amy Vezza
State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG <iesg-secretary@ietf.org>
To: …
State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: <mpls@ietf.org>
Reply-To: ietf@ietf.org
Subject: Third Last Call: <draft-ietf-mpls-loss-delay-03.txt> (Packet Loss and Delay Measurement for MPLS Networks) to Proposed Standard

The IESG has received a request from the Multiprotocol Label Switching WG
(mpls) to consider the following document:
- 'Packet Loss and Delay Measurement for MPLS Networks'
<draft-ietf-mpls-loss-delay-03.txt> as a Proposed Standard

This is a third last call. The last call is only necessary because of a
further late-received IPR disclosure.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-08-01. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

Many service provider service level agreements (SLAs) depend on the
ability to measure and monitor performance metrics for packet loss
and one-way and two-way delay, as well as related metrics such as
delay variation and channel throughput. This measurement capability
also provides operators with greater visibility into the performance
characteristics of their networks, thereby facilitating planning,
troubleshooting, and evaluation. This document specifies protocol
mechanisms to enable the efficient and accurate measurement of these
performance metrics in MPLS networks.


The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-mpls-loss-delay/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-mpls-loss-delay/


The following IPR Declarations may be related to this I-D:

http://datatracker.ietf.org/ipr/1574/
http://datatracker.ietf.org/ipr/1584/
2011-07-18
04 Amy Vezza Last Call was requested
2011-07-18
04 Amy Vezza State changed to Last Call Requested from IESG Evaluation::Revised ID Needed.
2011-07-18
04 Amy Vezza Last Call text changed
2011-07-05
04 Cindy Morgan State changed to IESG Evaluation::Revised ID Needed from Waiting for AD Go-Ahead.
2011-07-01
04 (System) State changed to Waiting for AD Go-Ahead from In Last Call.
2011-06-30
04 Cindy Morgan Removed from agenda for telechat
2011-06-30
04 Adrian Farrel
[Ballot discuss]
This is an administrative Discuss - I intend to move to move to a YES ballot.

This document is in an administrative second …
[Ballot discuss]
This is an administrative Discuss - I intend to move to move to a YES ballot.

This document is in an administrative second IETF last call because of a late IPR disclosure. The IESG will hold its evaluation before this second last call completes. I will hold this Discuss until last call completes in case any issues are raised from the community.

There are also IANA issues that need to be addressed before approval
2011-06-30
04 Gonzalo Camarillo [Ballot Position Update] New position, No Objection, has been recorded
2011-06-30
04 Wesley Eddy
[Ballot discuss]
The computation of the throughput metric is only very loosely specified here.  Since the counters exchanged can represent either a number of packets …
[Ballot discuss]
The computation of the throughput metric is only very loosely specified here.  Since the counters exchanged can represent either a number of packets or a number of bytes, then the throughput can either be computed in packets/time or bytes/time depending on what units are used.
2011-06-30
04 Sean Turner
[Ballot discuss]
This is an updated discuss based on an exchange with an author.

#1) Which of the 5 formats defined in Section 3.1 MUST …
[Ballot discuss]
This is an updated discuss based on an exchange with an author.

#1) Which of the 5 formats defined in Section 3.1 MUST be supported for an implementation to be considered compliant to this document? 

#2) Section 3.4 contains the following:

The Type space is divided into Mandatory and Optional subspaces:

  Type Range    Semantics
  -------------- ---------
  0-127          Mandatory
  128-255        Optional

  Upon receipt of a query message including an unrecognized mandatory
  TLV object, the recipient MUST respond with an Unsupported Mandatory
  TLV Object error code.

and Section 8.4 contains the following:

  IANA is also requested to indicate that Types 0-127 are classified as
  Mandatory, and that Types 128-255 are classified as Optional.

Wouldn't it be more 2119-like if you used REQUIRED and OPTIONAL?  Isn't this kind of saying that the elements in the 0-127 range MUST be supported?

Also later in 3.4 it includes:

127            Experimental use

You're requiring implementations to support the experimental TLV?  I would think that would be OPTIONAL.

#3) Which of the four TLV objects in Section 3.5 MUST be supported for an implementation to be considered compliant to this document?  It says zero or more may be present but not which ones MUST be supported.  Are any of them a MUST?

#4) cleared
2011-06-30
(System) Posted related IPR disclosure: Cisco's Statement of IPR Related to draft-ietf-mpls-loss-delay-03
2011-06-29
04 Pete Resnick [Ballot Position Update] New position, No Objection, has been recorded
2011-06-29
04 David Harrington [Ballot Position Update] New position, No Objection, has been recorded
2011-06-29
04 Peter Saint-Andre [Ballot Position Update] New position, No Objection, has been recorded
2011-06-29
04 Ralph Droms [Ballot Position Update] New position, No Objection, has been recorded
2011-06-29
04 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded
2011-06-29
04 Robert Sparks [Ballot Position Update] New position, No Objection, has been recorded
2011-06-28
04 Ron Bonica
[Ballot comment]
Please add text to section 2.9.10 stating that in the following conditions, delay measurement will be useless:

- when the two router clocks …
[Ballot comment]
Please add text to section 2.9.10 stating that in the following conditions, delay measurement will be useless:

- when the two router clocks differ by a significant portion of the round trip time
- when probe processing contributes significantly to round trip time
2011-06-28
04 Ron Bonica [Ballot Position Update] New position, Yes, has been recorded
2011-06-28
04 Sean Turner
[Ballot comment]
#1) Section 3.1 and 3.2 contains the following:

  TLV Block            Optional block of Type-Length-Value fields

Should Optional …
[Ballot comment]
#1) Section 3.1 and 3.2 contains the following:

  TLV Block            Optional block of Type-Length-Value fields

Should Optional be OPTIONAL to indicate support requirement?

#2) Section 4.2.2 contains the following:

  When transmitting an LM Query over a channel, the Version field MUST
  be set to 0.

Shouldn't "over a channel" be removed?  Isn't version always set to 0?

#3) Section 4.2.2 contains the following:

  The Origin Timestamp field SHOULD be set to the time at which this
  message is transmitted,

hmmm so what other time would be put there?  The definition from earlier sections is:

  Origin Timestamp: Timestamp recording the transmit time of the query
  message.

#4) Section 4.3.1 contains the following:

  When transmitting a DM Query over a channel,

Shouldn't "over a channel" be removed?  Isn't version always set to 0?
2011-06-28
04 Sean Turner
[Ballot discuss]
#1) Which of the 5 formats defined in Section 3.1 MUST be supported for an implementation to be considered compliant to this document?  …
[Ballot discuss]
#1) Which of the 5 formats defined in Section 3.1 MUST be supported for an implementation to be considered compliant to this document? 

#2) Section 3.4 contains the following:

The Type space is divided into Mandatory and Optional subspaces:

  Type Range    Semantics
  -------------- ---------
  0-127          Mandatory
  128-255        Optional

  Upon receipt of a query message including an unrecognized mandatory
  TLV object, the recipient MUST respond with an Unsupported Mandatory
  TLV Object error code.

and Section 8.4 contains the following:

  IANA is also requested to indicate that Types 0-127 are classified as
  Mandatory, and that Types 128-255 are classified as Optional.

Wouldn't it be more 2119-like if you used REQUIRED and OPTIONAL?  Isn't this kind of saying that the elements in the 0-127 range MUST be supported?

Also later in 3.4 it includes:

127            Experimental use

You're requiring implementations to support the experimental TLV?  I would think that would be OPTIONAL.

#3) Which of the four TLV objects in Section 3.5 MUST be supported for an implementation to be considered compliant to this document?  It says zero or more may be present but not which ones MUST be supported.  Are any of them a MUST?

#4) Section 3.5.2 contains the following:

  The Return Address object MUST NOT appear in a response.

What happens if it does?  Maybe put another way, should there be a specific error for  this - or maybe just say which error should be returned (that way everybody does it the same way).
2011-06-28
04 Sean Turner [Ballot Position Update] New position, Discuss, has been recorded
2011-06-28
04 Dan Romascanu
[Ballot discuss]
This DISCUSS is in part based on the OPS-DIR review performed by Benoit Claise.

1. The document defines new protocols without making any …
[Ballot discuss]
This DISCUSS is in part based on the OPS-DIR review performed by Benoit Claise.

1. The document defines new protocols without making any reference to the IPPM OWAMP (RFC 4546) and TWAMP (RFC 5357) despite the bidirectional measurment described in section 2.1 being very similar to the latest, for example, If there are good reasons for which OWAMP and TWAMP are not suited in the MPLS environment I suggest that these need to be clearly explained.

2. The applicability statement in section 1.1 risks to create confusion with the IPPM work. I would rather drop it. 

  Although the procedures in this document are presented in the context
  of MPLS, they have no essential dependence on MPLS and generalize
  easily to other types of packet networks.  Such generalizations are,
  however, outside the scope of this document.

3. In Section 2.2:

  The foregoing discussion has assumed the counted objects are packets,
  but this need not be the case.  In particular, octets may be counted
  instead.  This will, of course, reduce the MaxLMInterval
  proportionately.

Proportionately to what? Probably with the ratio between 1 and the number of octets in the minimal packet size on the respective media. Either be exact, or use some other more suitable term (accordingly?).

4. What is the reason for not using the packet loss metrics definition from RFC 2680? (while the delay metrics are referenced from 2679 and 2681 repectively). If that definition is not suitable I suggest that this is discussed if not please add the reference.

5. I support Wesley's DISCUSS concerning the throuput metrics and discussion and I generally feel very unconfortable with the way it is dealt with in this document. Do we need reference to througput at all? after all the scope of the document focuses on loss and delay. If we do I would also suggest a serious rewrite starting from a proper definition of the metics or reference to existing definitions in other RFCs if appropriate.

6. The PDV definition in section 2.5 is rather vague. I suggest to refer to section 4 in RFC 5481 which makes a clear distinction between PDV and IPDV.

7. The document lacks proper manageability considerations:

  section 2.9.7
  This can be achieved in supporting
  implementations by, for example, configuring the querier, in the case
  of a bidirectional measurement session, to forward each response it
  receives to the post-processor via any convenient protocol.

  Post-processing devices may have the ability to store measurement
  data for an extended period and to generate a variety of useful
  statistics from them.

section 4.1
  Measurement sessions are initiated at the discretion of the network
  operator and are terminated either at the operator's request or as
  the result of an error condition.

There is no mention about how to remotely configure this protocol (example: MIB or YANG module), how to retrieve the results, what are the storage requirements for the results and methods and periodicity of retreival of the results. There is no mention about the security implications of activating two new protocols that generate traffic in the network and what are the admissible levels of traffic that can be generated.
2011-06-28
04 Dan Romascanu
[Ballot discuss]
This DISCUSS is in part based on the OPS-DIR review performed by Benoit Claise.

1. The document defines new protocols without making any …
[Ballot discuss]
This DISCUSS is in part based on the OPS-DIR review performed by Benoit Claise.

1. The document defines new protocols without making any reference to the IPPM OWAMP (RFC 4546) and TWAMP (RFC 5357) despite the bidirectional measurment described in section 2.1 being very similar to the latest, for example, If there are good reasons for which OWAMP and TWAMP are not suited in the MPLS environment I suggest that these need to be clearly explained.

2. The applicability statement in section 1.1 risks to create confusion with the IPPM work. I would rather drop it. 

  Although the procedures in this document are presented in the context
  of MPLS, they have no essential dependence on MPLS and generalize
  easily to other types of packet networks.  Such generalizations are,
  however, outside the scope of this document.

3. In Section 2.2:

  The foregoing discussion has assumed the counted objects are packets,
  but this need not be the case.  In particular, octets may be counted
  instead.  This will, of course, reduce the MaxLMInterval
  proportionately.

Proportionately to what? Probably with the ratio between 1 and the number of octets in the minimal packet size on the respective media. Either be exact, or use some other more suitable term (accordingly?).

6. What is the reason for not using the packet loss metrics definition from RFC 2680? (while the delay metrics are referenced from 2679 and 2681 repectively). If that definition is not suitable I suggest that this is discussed if not please add the reference.

5. I support Wesley's DISCUSS concerning the throuput metrics and discussion and I generally feel very unconfortable with the way it is dealt with in this document. Do we need reference to througput at all? after all the scope of the document focuses on loss and delay. If we do I would also suggest a serious rewrite starting from a proper definition of the metics or reference to existing definitions in other RFCs if appropriate.

6. The PDV definition in section 2.5 is rather vague. I suggest to refer to section 4 in RFC 5481 which makes a clear distinction between PDV and IPDV.

7. The document lacks proper manageability considerations:

  section 2.9.7
  This can be achieved in supporting
  implementations by, for example, configuring the querier, in the case
  of a bidirectional measurement session, to forward each response it
  receives to the post-processor via any convenient protocol.

  Post-processing devices may have the ability to store measurement
  data for an extended period and to generate a variety of useful
  statistics from them.

section 4.1
  Measurement sessions are initiated at the discretion of the network
  operator and are terminated either at the operator's request or as
  the result of an error condition.

There is no mention about how to remotely configure this protocol (example: MIB or YANG module), how to retrieve the results, what are the storage requirements for the results and methods and periodicity of retreival of the results. There is no mention about the security implications of activating two new protocols that generate traffic in the network and what are the admissible levels of traffic that can be generated.
2011-06-28
04 Dan Romascanu [Ballot Position Update] New position, Discuss, has been recorded
2011-06-25
04 Stephen Farrell
[Ballot comment]
(1) Section 2 as a whole is very wordy. While its fine to spell things
out for clarity, this text perhaps demands too …
[Ballot comment]
(1) Section 2 as a whole is very wordy. While its fine to spell things
out for clarity, this text perhaps demands too little from the reader,
at the expense of clarity for the capable reader. (In other words, this
seems just too long:-) Feel free to entirely ignore this comment
though.

(2) The "(B1,...,Bk)" notation isn't clear in 2.6 - are we measuring
(A,B1) and (A,B2) etc. or are we measuring what happens on the path from
A to Bk via B1,B2...etc.? Since the section is about unidirectional LSPs
it may be easier to just deal with A and B here.

(3) (2.9.3) Saying that the detailed measurement behavaiour "MUST be
made clear to the user" seems wrong in two respects - a) a programmer
won't know what'll be clear to all future users of their code, and b)
there may be no (human) user that can see the direct mesurements, (the
humans might only see derived statistics I guess). I also don't quite
know how I'd test for that MUST. Maybe just loose the 2119 language
there?

(4) 2.9.5 assumes that intermediate nodes can reply to LM/DM messages,
but that hasn't yet been stated.

(5) Two timestamp formats are supported - would be good to include
examples of each at the point where that's first mentioned in detail.
2011-06-25
04 Stephen Farrell
[Ballot discuss]
This is just a discuss to check if the chat arising from Steve
Kent's secdir review [1] reached closure. The discussion seemed
to …
[Ballot discuss]
This is just a discuss to check if the chat arising from Steve
Kent's secdir review [1] reached closure. The discussion seemed
to tail off a bit and I'm not clear if it was done or not.

  [1] http://www.ietf.org/mail-archive/web/secdir/current/msg02727.html
2011-06-25
04 Stephen Farrell [Ballot Position Update] New position, Discuss, has been recorded
2011-06-23
04 Adrian Farrel
[Ballot discuss]
This is an administrative Discuss - I intend to move to move to a YES ballot.

This document is in an administrative second …
[Ballot discuss]
This is an administrative Discuss - I intend to move to move to a YES ballot.

This document is in an administrative second IETF last call because of a late IPR disclosure. The IESG will hold its evaluation before this second last call completes. I will hold this Discuss until last call completes in case any issues are raised from the community.
2011-06-23
04 Adrian Farrel [Ballot Position Update] Position for Adrian Farrel has been changed to Discuss from Yes
2011-06-23
04 Adrian Farrel Telechat date has been changed to 2011-06-30 from 2011-07-14
2011-06-22
04 Wesley Eddy
[Ballot discuss]
The computation of the throughput metric is only very loosely specified here.  Without more explicit instructions, it may not be computed the same …
[Ballot discuss]
The computation of the throughput metric is only very loosely specified here.  Without more explicit instructions, it may not be computed the same by multiple implementations.  It should be more clear about whether packet pairs, trains, or other means are used and what the timing requirements between samples are.

It seems like if the changes needed to clearly specify the throughput metric are too significant at this stage, the section 2.3 text should simply say that the LM may be used as a building block for computing a to-be-specified throughput metric, and left out of scope for this document.
2011-06-22
04 Wesley Eddy [Ballot Position Update] New position, Discuss, has been recorded
2011-06-17
04 Samuel Weiler Request for Telechat review by SECDIR Completed. Reviewer: Stephen Kent.
2011-06-17
04 Samuel Weiler Request for Telechat review by SECDIR is assigned to Stephen Kent
2011-06-17
04 Samuel Weiler Request for Telechat review by SECDIR is assigned to Stephen Kent
2011-06-17
04 Samuel Weiler Assignment of request for Last Call review by SECDIR to Tero Kivinen was rejected
2011-06-17
04 Stewart Bryant [Ballot Position Update] New position, Recuse, has been recorded
2011-06-17
04 Amy Vezza
State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG <iesg-secretary@ietf.org>
To: …
State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: <mpls@ietf.org>
Reply-To: ietf@ietf.org
Subject: Second Last Call: <draft-ietf-mpls-loss-delay-03.txt> (Packet Loss and Delay Measurement for MPLS Networks) to Proposed Standard


The IESG has received a request from the Multiprotocol Label Switching WG
(mpls) to consider the following document:
- 'Packet Loss and Delay Measurement for MPLS Networks'
  <draft-ietf-mpls-loss-delay-03.txt> as a Proposed Standard

This is a second last call. The last call is only necessary because of a
late-received IPR disclosure.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-07-01. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  Many service provider service level agreements (SLAs) depend on the
  ability to measure and monitor performance metrics for packet loss
  and one-way and two-way delay, as well as related metrics such as
  delay variation and channel throughput.  This measurement capability
  also provides operators with greater visibility into the performance
  characteristics of their networks, thereby facilitating planning,
  troubleshooting, and evaluation.  This document specifies protocol
  mechanisms to enable the efficient and accurate measurement of these
  performance metrics in MPLS networks.





The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-mpls-loss-delay/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-mpls-loss-delay/


The following IPR Declarations may be related to this I-D:

  http://datatracker.ietf.org/ipr/1574/



2011-06-17
04 Amy Vezza Last Call was requested
2011-06-17
04 Amy Vezza State changed to Last Call Requested from IESG Evaluation.
2011-06-17
04 Amy Vezza Last Call text changed
2011-06-17
04 Amy Vezza Last Call text changed
2011-06-17
04 Adrian Farrel Telechat date has been changed to 2011-07-14 from 2011-06-23
2011-06-17
(System) Posted related IPR disclosure: Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-mpls-loss-delay-03
2011-06-15
04 Amanda Baber
IANA has a question about the IANA Actions in this document.

Upon approval of this document, IANA understands that there are four
actions which IANA …
IANA has a question about the IANA Actions in this document.

Upon approval of this document, IANA understands that there are four
actions which IANA must complete.

First in the Pseudowire Associated Channel Types registry in the
Pseudowire Name Spaces (PWE3) registry located at:

http://www.iana.org/assignments/pwe3-parameters/pwe3-parameters.xml#pwe3-parameters-10

five new Channel Types are to be registered as follows:

Value Description TLV Follows Reference
----- -------------------------------------- ----------- ------------
TBD MPLS Direct Packet Loss Measurement No [ RFC-to-be ]
(DLM)
TBD MPLS Inferred Packet Loss Measurement No [ RFC-to-be ]
(ILM)
TBD MPLS Packet Delay Measurement (DM) No [ RFC-to-be ]
TBD MPLS Direct Packet Loss and Delay No [ RFC-to-be ]
Measurement (DLM+DM)
TBD MPLS Inferred Packet Loss and Delay No [ RFC-to-be ]
Measurement (ILM+DM)

Second, IANA is to create a new registry called "Measurement Timestamp
Types." This registry will contain Type, Description, Size and Reference
entries. New registrations will be done through IETF Review. The range
of the Type field is 0-15.

IANA QUESTION --> Is this to be a standalone registry or part of an
existing registry?

The initial entries for this registry are:

Type Description Size in bits Reference
---- -------------------------------------- ------------ ------------
0 Null Timestamp 64 [ RFC-to-be ]
1 Sequence Number 64 [ RFC-to-be ]
2 Network Time Protocol version 4 64-bit 64 [ RFC-to-be ]
Timestamp
3 Truncated IEEE 1588v2 PTP Timestamp 64 [ RFC-to-be ]

Third, IANA will create a pair of new registries for "MPLS Loss/Delay
Measurement Control Codes." One of the registries will be for MPLS
Loss/Delay Measurement Control Query Codes and the other will be for
MPLS Loss/Delay Measurement Control Response Codes. In both cases, the
registry will be
maintained through IETF Review.

Initial registrations in the new MPLS Loss/Delay Measurement Control
Query Codes registry are as follows:

Query Codes

Code Description Reference
---- ------------------------------ ------------
0x0 In-band Response Requested [RFC-to-be]
0x1 Out-of-band Response Requested [RFC-to-be]
0x2 No Response Requested [RFC-to-be]

Initial registrations in the new MPLS Loss/Delay Measurement Control
Response Codes registry are as follows:

Response Codes

Code Description Reference
---- ----------------------------------- ------------
0x0 Reserved [ RFC-to-be ]
0x1 Success [ RFC-to-be ]
0x2 Data Format Invalid [ RFC-to-be ]
0x3 Initialization In Progress [ RFC-to-be ]
0x4 Data Reset Occurred [ RFC-to-be ]
0x5 Resource Temporarily Unavailable [ RFC-to-be ]
0x10 Unspecified Error [ RFC-to-be ]
0x11 Unsupported Version [ RFC-to-be ]
0x12 Unsupported Control Code [ RFC-to-be ]
0x13 Unsupported Data Format [ RFC-to-be ]
0x14 Authentication Failure [ RFC-to-be ]
0x15 Invalid Destination Node Identifier [ RFC-to-be ]
0x16 Connection Mismatch [ RFC-to-be ]
0x17 Unsupported Mandatory TLV Object [ RFC-to-be ]
0x18 Unsupported Query Interval [ RFC-to-be ]
0x19 Administrative Block [ RFC-to-be ]
0x1A Resource Unavailable [ RFC-to-be ]
0x1B Resource Released [ RFC-to-be ]
0x1C Invalid Message [ RFC-to-be ]
0x1D Protocol Error [ RFC-to-be ]

IANA will also note that the values 0x0 - 0xF in the Response Code
section are reserved for non-error response codes.

The range of the Code fields is 0 - 255.

Fourth, IANA will create a new "MPLS Loss/Delay Measurement TLV Objects"
registry. IANA will note that Types 0-127 are classified as Mandatory,
and that Types 128-255 are classified as Optional.

The range of the Type field is 0 - 255.

The allocation policy for this registry will be IETF Review, except for
the ranges marked "Implementation-specific usage", for which the policy
is Private Use.

IANA QUESTION --> Which ranges below are to be marked "Implementation
Specific Usage?"

The initial registrations in this registry will be as follows:

Type Description Reference
---- --------------------------------- ------------
0 Padding - copy in response [ RFC-to-be ]
1 Return Address [ RFC-to-be ]
2 Session Query Interval [ RFC-to-be ]
3 Loopback Request [ RFC-to-be ]
127 Experimental use [ RFC-to-be ]
128 Padding - do not copy in response [ RFC-to-be ]
129 Destination Address [ RFC-to-be ]
130 Source Address [ RFC-to-be ]
255 Experimental use [ RFC-to-be ]

IANA understands that these are the only actions that are required to be
completed upon approval of this document.
2011-06-15
04 Adrian Farrel State changed to IESG Evaluation from Waiting for AD Go-Ahead.
2011-06-15
04 (System) State changed to Waiting for AD Go-Ahead from In Last Call.
2011-06-10
04 David Harrington Request for Last Call review by TSVDIR is assigned to Henk Uijterwaal
2011-06-10
04 David Harrington Request for Last Call review by TSVDIR is assigned to Henk Uijterwaal
2011-06-09
04 Adrian Farrel Placed on agenda for telechat - 2011-06-23
2011-06-01
04 Samuel Weiler Request for Last Call review by SECDIR is assigned to Tero Kivinen
2011-06-01
04 Samuel Weiler Request for Last Call review by SECDIR is assigned to Tero Kivinen
2011-06-01
04 Cindy Morgan
State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG <iesg-secretary@ietf.org>
To: …
State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: <mpls@ietf.org>
Reply-To: ietf@ietf.org
Subject: Last Call: <draft-ietf-mpls-loss-delay-03.txt> (Packet Loss and Delay Measurement for MPLS Networks) to Proposed Standard


The IESG has received a request from the Multiprotocol Label Switching WG
(mpls) to consider the following document:
- 'Packet Loss and Delay Measurement for MPLS Networks'
  <draft-ietf-mpls-loss-delay-03.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-06-15. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  Many service provider service level agreements (SLAs) depend on the
  ability to measure and monitor performance metrics for packet loss
  and one-way and two-way delay, as well as related metrics such as
  delay variation and channel throughput.  This measurement capability
  also provides operators with greater visibility into the performance
  characteristics of their networks, thereby facilitating planning,
  troubleshooting, and evaluation.  This document specifies protocol
  mechanisms to enable the efficient and accurate measurement of these
  performance metrics in MPLS networks.





The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-mpls-loss-delay/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-mpls-loss-delay/


No IPR declarations have been submitted directly on this I-D.


2011-06-01
04 Adrian Farrel [Ballot Position Update] New position, Yes, has been recorded for Adrian Farrel
2011-06-01
04 Adrian Farrel Ballot has been issued
2011-06-01
04 Adrian Farrel Created "Approve" ballot
2011-06-01
04 Adrian Farrel Last Call was requested
2011-06-01
04 Adrian Farrel State changed to Last Call Requested from AD Evaluation::AD Followup.
2011-06-01
04 Adrian Farrel Last Call text changed
2011-06-01
04 (System) Ballot writeup text was added
2011-06-01
04 (System) Last call text was added
2011-06-01
04 (System) Ballot approval text was added
2011-06-01
04 (System) Sub state has been changed to AD Follow up from New Id Needed
2011-06-01
03 (System) New version available: draft-ietf-mpls-loss-delay-03.txt
2011-05-31
04 Adrian Farrel Area acronym has been changed to rtg from gen
2011-05-26
04 Adrian Farrel
State changed to AD Evaluation::Revised ID Needed from AD Evaluation.<br>AD review

Hi,

Don't panic!

I have performed my AD review of daft-ietf-mpls-loss-delay. The
purpose of …
State changed to AD Evaluation::Revised ID Needed from AD Evaluation.<br>AD review

Hi,

Don't panic!

I have performed my AD review of daft-ietf-mpls-loss-delay. The
purpose of the review is to catch any nits or issues before the
document goes forward to IETF last call and IESG review. By getting
these issues out at this stage we can hope for a higher quality
review and a smoother passage through the process.

This is a good solid document: thanks!

I don't have any major technical issues with your draft. The intention
and solution are fine. However, I found a largish number of small
issues and questions. These are mainly concerns with clarity, although
I did have some more substantial concerns about the security section.

All of my comments are up for discussion, and you should not feel
rail-roaded into making changes. But I do think my comments need to be
addressed before this document goes to IETF last call.

I have moved the draft into "AD-review:Revised-ID-needed" state in
the datatracker, and I look forward to seeing the new revision which
I can put forward for IETF last call.

Thanks,
Adrian

---

Section 1

  o  The LM and DM protocols are applicable to the LSPs, pseudowires,
      and sections of networks based on the MPLS Transport Profile
      (MPLS-TP), because the MPLS-TP is based on a standard MPLS data
      plane.  The MPLS-TP is defined and described in [RFC5921], and
      MPLS-TP LSPs, pseudowires, and sections are discussed in detail in
      [RFC5960].

You should give an Informative forward reference to
draft-ietf-mpls-tp-loss-delay-profile.

---

Section 1

  o  The LM and DM protocols can be used for both continuous/proactive
      and selective/on-demand measurement.

s/for both/both for/

---

Section 2.3

This section on Throughput seems very thin.

In Section 2.4 you note:

  Measurement of the one-way delay quantities requires that the clocks
  of A and B be synchronized, whereas the two-way delay metrics can be
  measured directly even when this is not the case (provided A and B
  have stable clocks).

Doesn't the same logic apply to throughput measurement?

---

2.7.  Dyadic Measurement

It is so nice to see words used. But do you think that your readership
will really understand? And is this precisely the right word, anyway?
After all, it appears that you mean a specific limitation of a dyad to
the pair of ends.

You write:
  Consequently this document does not attempt to
  specify a dyadic operational mode.
Delete "attempt to"

---

2.9.11

  There are two significant timestamp formats in common use: the
  timestamp format of the Internet standard Network Time Protocol
  (NTP), described in [RFC5905], and the timestamp format used in the
  IEEE 1588 Precision Time Protocol (PTP) [IEEE1588].

Please avoid the word "standard" as RFC 5905 is not an Internet
Standard. Suggest you delete "Internet standard" without any loss of
meaning.

Can you please add to this section some text such as...

  To ensure interop it is necessary that support of at least one
  format is mandatory. This specification requires the support of
  the PTP format as discussed in Section 3.4 and Appendix A.

---

Section 3

  The message formats for direct and inferred LM are identical, as are
  the formats for the DLM+DM and ILM+DM messages.

A little care needed? I think you mean:

  The message formats for direct and inferred LM are identical. The
  formats for the DLM+DM and ILM+DM messages are identical.

---

Section 3.1

  Did you consider simply burning a new ACH type rather than including
  a version number field? Just idle curiosity...

---

Section 3.1

Control Code : Responses

This list starts off saying that the fields in the response either "MUST
NOT be used" or "do not contain valid measurement data". And then this
advice peters out in a way that might be inferred to mean that the data
*is* valid on other response codes. I think the turning point was when
you crossed the 0xf boundary, so you might simply say that for all
return codes > 0xf the data is not valid.

---

Section 3.1


  Message Length: Set to the total length of this message in bytes.

For the avoidance of doubt, it is usual to say "...including the
Version, Flags, Control Code, and Message Length fields."

I know one AD that will want you to say that the two-octet integer is
presented in line format.

---

Section 3.1

It wasn't clear to me until I read 3.4 that the timestamp field is
uniformly 64 bits. Could you add a note?

The way you have shown 8-byte quantities in the figure is slightly
unusual.

---

Sections 3.2 and 3.3
Some of the field description issues from 3.1 apply.

---

Section 3.4

  Implementations SHOULD also be capable of
  reading timestamps written in NTPv4 64-bit format and reconciling
  them internally with PTP timestamps for measurement purposes.
  Support for other timestamp formats is OPTIONAL.

Why is this "SHOULD" not "MUST"? It seems to me that unless you say
"MUST" you cannot achieve interoperability.

---

3.5

I am worried by two aspects of the parameter ranges defined here.

  Type          Definition
  -------------- ---------------------------------
  Mandatory
[snip]
  4-119          Reserved
  120-127        Implementation-specific usage

  Optional
[snip]
  131-247        Reserved
  248-255        Implementation-specific usage

1. s/Reserved/Unallocated/

2. Why so many (any!) implementation-specific TLVs.

Any changes need to be reflected in the IANA section.

---

3.5.1

  More than one padding object MAY be present, in which case they
  SHOULD be contiguous.  Padding objects SHOULD occur at the end of
  the TLV Block.  The Value field of a padding object is arbitrary.

Not sure what the point these two "SHOULD" statements is. The fact that
they are only "SHOULD" means that a parser must be able to process
variations.

---

Section 6 ends with the throw-away line:
  Authentication
  procedures can also be used to ensure that only queries from
  authorized devices are processed.

I assume you are referring to Access Lists rather than authentication
because there is no discussion here, or in Section 7, of any such
authentication procedure....

See my next comment about Section 7

---

Section 7

  If reception or
  alteration of performance-related data by unauthorized devices is an
  operational concern, authentication and/or encryption procedures
  should be used to ensure message integrity and confidentiality.  Such
  procedures are outside the scope of this document, but have general
  applicability to OAM protocols in MPLS networks.

There is no way you will get this through a review by anyone with
security clue! I understand that what you are saying is that we need a
generic solution to security for OAM and then you can shelter under that
umbrella, but what you have done is identified an attack vector, defined
it as a potential problem, and then left the protocol unprotected!

Unfortunately, this could easily turn into a blocking issue as currently
expressed.

My advice is:

1. Expand upon the text you have in this section to include a discussion
  of how modification, injection, or snooping is only possible from an
  on-path node (you would need to explain why). Go on to say that, in
  general, all LSRs within a domain share a common trust relationship
  such that malign or compromised LSRs are not considered a significant
  risk. Explain that this means that the security concerns only
  become apparent in multi-domain environments where it is less likely
  that end-to-end OAM is run.

2. Include a reference to draft-ietf-mpls-tp-security-framework for
  "an overview of security issues concerning OAM messages"

3. Include a forward reference to an I-D that has been started to give
  a solution to the security concerns. I think you are in a bit of a hole
  and you may have to make the first version of this draft yourselves
  (before this I-D can go any further). Not a very comfortable situation.

Please note that I think this is the *least* we will get away with. If
I saw this coming up from a draft in another area and I was reviewing
it, I would probably push back quite hard to get the security details
properly worked out.
2011-05-23
04 Adrian Farrel Ballot writeup text changed
2011-05-23
04 Adrian Farrel Ballot writeup text changed
2011-05-23
04 Adrian Farrel State changed to AD Evaluation from Publication Requested.
2011-05-20
04 Amy Vezza
The MPLS WG requests that:

          Packet Loss and Delay Measurement for MPLS Networks
          draft-ietf-mpls-loss-delay-02

is …
The MPLS WG requests that:

          Packet Loss and Delay Measurement for MPLS Networks
          draft-ietf-mpls-loss-delay-02

is published as an Informational RFC on the standards track.

Note: We are at the same time requesting publication for:

  A Packet Loss and Delay Measurement Profile for MPLS-based
  Transport Networks
  draft-ietf-mpls-tp-loss-delay-profile-03

These two draft started out as a single draft, but the working
group decided to split them into two separate draft. One generic
MPLS draft and one specific for MPLS based transport Networks.

It is not strictly necessary, but recommended, to progress these
two draft in parallel.

> (1.a) Who is the Document Shepherd for this document? Has the
>      Document Shepherd personally reviewed this version of the
>      document and, in particular, does he or she believe this
>      version is ready for forwarding to the IESG for publication?

Loa Andersson is the Document Shepherd.
He has reviewed the document and believes it is ready to be
forwarded to the IESG for publication.

> (1.b) Has the document had adequate review both from key WG members
>      and from key non-WG members? Does the Document Shepherd have
>      any concerns about the depth or breadth of the reviews that
>      have been performed?

The document has been reviewed in thr mpls working groups


The shephered is convinced that this is sufficient review for this
framework document.


> (1.c) Does the Document Shepherd have concerns that the document
>      needs more review from a particular or broader perspective,
>      e.g., security, operational complexity, someone familiar with
>      AAA, internationalization or XML?

No.

> (1.d) Does the Document Shepherd have any specific concerns or
>      issues with this document that the Responsible Area Director
>      and/or the IESG should be aware of? For example, perhaps he
>      or she is uncomfortable with certain parts of the document, or
>      has concerns whether there really is a need for it. In any
>      event, if the WG has discussed those issues and has indicated
>      that it still wishes to advance the document, detail those
>      concerns here. Has an IPR disclosure related to this document
>      been filed? If so, please include a reference to the
>      disclosure and summarize the WG discussion and conclusion on
>      this issue.

No such concerns. There is no IPR claim for this draft.



> (1.e) How solid is the WG consensus behind this document? Does it
>      represent the strong concurrence of a few individuals, with
>      others being silent, or does the WG as a whole understand and
>      agree with it?

There is a good consensus around this draft.



> (1.f) Has anyone threatened an appeal or otherwise indicated extreme
>      discontent? If so, please summarise the areas of conflict in
>      separate email messages to the Responsible Area Director. (It
>      should be in a separate email because this questionnaire is
>      entered into the ID Tracker.)

No threats or extreme discontent.

> (1.g) Has the Document Shepherd personally verified that the
>      document satisfies all ID nits? (See the Internet-Drafts Checklist
>      and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
>      not enough; this check needs to be thorough. Has the document
>      met all formal review criteria it needs to, such as the MIB
>      Doctor, media type and URI type reviews?

The nits tool does give some warnings, these can be address as we
resolve comments during the AD, IESG and IETF review process.


> (1.h) Has the document split its references into normative and
>      informative? Are there normative references to documents that
>      are not ready for advancement or are otherwise in an unclear
>      state? If such normative references exist, what is the
>      strategy for their completion? Are there normative references
>      that are downward references, as described in [RFC3967]? If
>      so, list these downward references to support the Area
>      Director in the Last Call procedure for them [RFC3967].

References are correctly split.

There is a normative reference to an IEEE document.


> (1.i) Has the Document Shepherd verified that the document IANA
>      consideration section exists and is consistent with the body
>      of the document? If the document specifies protocol
>      extensions, are reservations requested in appropriate IANA
>      registries? Are the IANA registries clearly identified? If
>      the document creates a new registry, does it define the
>      proposed initial contents of the registry and an allocation
>      procedure for future registrations? Does it suggest a
>      reasonable name for the new registry? See [RFC5226]. If the
>      document describes an Expert Review process has Shepherd
>      conferred with the Responsible Area Director so that the IESG
>      can appoint the needed Expert during the IESG Evaluation?

There are a well-written IANA section in this document with the following
requests of IANA:

o  Allocation of Channel Types in the PW Associated Channel Type
    registry

o  Creation of a Measurement Timestamp Type registry

o  Creation of an MPLS Loss/Delay Measurement Control Code registry

o  Creation of an MPLS Loss/Delay Measurement Type-Length-Value (TLV)
    Object registry


> (1.j) Has the Document Shepherd verified that sections of the
>      document that are written in a formal language, such as XML
>      code, BNF rules, MIB definitions, etc., validate correctly in
>      an automated checker?

No such formal language.

> (1.k) The IESG approval announcement includes a Document
>      Announcement Write-Up. Please provide such a Document
>      Announcement Write-Up? Recent examples can be found in the
>      "Action" announcements for approved documents. The approval
>      announcement contains the following sections:

Technical Summary

  The ability to mesure and monitor one and two-way packet loss and delay
  performance metrics is the basis needed by service providers to deliver
  SLAs.
  These metrics are also that realted to delay variation and channel
  throughput.  This measurement capability
  also providesgreater visibility for operators into the performance
  characteristics of their networks, thereby facilitating planning,
  troubleshooting, and evaluation.  This document specifies protocol
  mechanisms to enable the efficient and accurate measurement of these
  performance metrics in MPLS networks.

  This document specifies two closely-related protocols, one for packet
  loss measurement (LM) and one for packet delay measurement (DM).


Working Group Summary

  This document is a MPLS working group document, and stricly not a part
  of the MPLS-TP project, however the companion functionality for MPLS
  based Transport Networks is based on this document. The working goroup
  have reviewed the document with this in mind.

Document Quality

The document is well reviewed in the MPLS working group
2011-05-20
04 Amy Vezza Draft added in state Publication Requested
2011-05-20
04 Amy Vezza [Note]: 'Loa Andersson (loa@pi.nu) is the Document Shepherd.' added
2011-04-20
02 (System) New version available: draft-ietf-mpls-loss-delay-02.txt
2011-02-04
01 (System) New version available: draft-ietf-mpls-loss-delay-01.txt
2010-12-23
00 (System) New version available: draft-ietf-mpls-loss-delay-00.txt