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 |