Subject: [mpls] MPLS WG Last call on draft-ietf-mpls-loss-delay-01

From: Ross Callon <[email-masked]>
Date: Sun, 6 Feb 2011 22:33:04 -0500

Working Group,

This is to start a four week working group last call on
" Packet Loss and Delay Measurement for MPLS Networks"
(draft-ietf-mpls-loss-delay-01).

Please send comments to the [email-masked] mailing list.

Also, please note that the related document
" draft-ietf-mpls-tp-loss-delay-profile-02.txt" is being last called in
parallel on the mpls-tp email list ([email-masked]).

This working group last call ends on Monday March 7, 2011.

Ross, Loa, and George

MPLS WG co-chairs

---

From: ben mackcrane <[email-masked]>
Date: Mon, 14 Feb 2011 00:12:06 +0100

Hello,

I have reviewed draft-ietf-mpls-loss-delay-01 and have the following
comments/questions:

1) The final loss, throughput, or delay calculations may be performed either
by the querier or by another post-processing system (e.g., a network
management server).  For unidirectional measurements this can be
accomplished simply by sending the out-of-band response to the
post-processing system identified by the return address TLV.  For
bidirectional measurements the querier can forward the final measurement
message using the same out-of-band mechanism used by the responder to the
address of the desired post-processing system.   Some port-processing
systems may have the ability to store measurement data for an extended
measurement period and produce a variety of useful statistics from the
measurement data.  Use of an off-line post-processing system also allows the
measurement function at the querier to be completely stateless.  The option
to support off-line post-processing should be included (and should require
only a small amount of additional text to describe).

2) In section 1 the work “packet” should be deleted from the bullet “The LM
protocol supports both 32-bit and 64-bit packet counters.” since octet
counters are also supported.

3) In section 2.1 the received packet count is described as not including
the LM packet itself. Unless the LM messages are excluded from the counting
altogether, it may be easier to include the LM packet in the count as it
must be received (and likely would be counted) before it is recognized as
andLM packet and further processing occurs.  It may be easier to add one to
the count when the LM message is sent than to subtract one when the LM
message is received.  It could also be specified that the sending count does
not include the LM packet and the receiving count does and the correction
can be handled I the post-processing calculations (keeping the LM
query/response functions as simple as possible).

4) In 2.2 the phrase "measurement of the throughput sustained over the
channel during the interval" would be better without "sustained" which tends
to suggest a constant rate.

5) In 2.2 the statement "This metric can be called the delivered
throughput." should be expanded since the values recorded allow calculation
of both offered throughput and delivered throughput.

6) In 2.2 the phrase "As for loss measurement," should be deleted since this
section is about throughput measurement (and the particular sentence appears
to be as well).

7) It is noted that due to the TC of the measurement messages they may be
reordered with respect to other packets. It should be further noted
somewhere that, while this can affect individual measurements in the direct
measurement method, the packet loss rate (derivative of packet loss
measurement) can still be accurately determined over time.  Some places
where this might be noted are in 2.7.2, 2.7.3, and/or 2.7.6.

8) Presumably the editor's note in 2.7.5 is no longer needed.

9) In 3.1 there should be a notification value (0x5?) for the case that the
egress measurement resource is preempted or released by an administrator
(indicating the measurement session should end).

10) In 3.1 the case of "Unsupported Version" is indicated as an error.  It
may be better to make this a notification so that the querier can decide
whether or not the earlier version responder can nevertheless provide useful
data.  There may be cases in which the responder does not have to be
upgraded to make beneficial use of additional information (e.g. in TLVs)
sent by the querier and returned (without being understood) in the response
message.  If this is desirable, then 4.1.4 should indicate that optional
TLVs are copied in the response if they are not understood.

11) In 3.1 the control code 0x15 mentions "Destination Node Identifier" --
is this the Destination Address (TLV 129)?  If not, to what does it refer?

12) In 3.1 to what does the "channel identifier supplied in the query" refer
in the description of control code 0x16?

13) In 3.2 the description of the Flags field is a bit confused.  It refers
to similarity with 3.1 and the X flag (which is in the DFlags field, not in
the Flags field).

14) In 3.5.3, since it is likely that the minimum supported LM interval will
vary for different endpoints and that useful measurements are not
necessarily dependent on the interval chosen, it would be more useful for
the suggested process to be the following: The querier need not send a
Session Query Interval TLV in the initial LM query, the responder SHOULD
send a Session Query Interval in the initial responses (indicating the
minimum supported interval), the querier SHOULD send a Session Query
Interval TLV in subsequent LM queries indicating the interval chosen
(greater than or equal to the minimum supported by the responder).  On
seeing the TLV from the querier the responder may cease including the TLV,
and on seeing the TLV not included in the response the querier may cease
sending the TLV.  This has the advantage of quickly finding an agreeable
rate and always initiating a measurement without requiring the administrator
or querier to know the capabilities of the responder a priori.

15) In 4.1.1 it is noted that data from multiple intervals can be
accumulated to provide a total loss measure. It should also be noted that
this data can be used to calculate a loss rate.

16) In 4.1.2 the querier sets counter 1 to the count of packets sent before
the LM query message.  It could also indicate that this value may be set to
zero until the counting resources have been engaged (e.g., if waiting for a
favorable response from the responder before beginning the measurement
process).

17) 4.1.5 should state that it is also possible to forward the final LM
message (containing all counts) to another location for post-processing.

Regards,
Ben Mack-Crane

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ross
Callon
Sent: Monday, February 07, 2011 4:33 AM
To: [email-masked]
Subject: [mpls] MPLS WG Last call on draft-ietf-mpls-loss-delay-01

Working Group,

 

Ross, Loa, and George
 
MPLS WG co-chairs

---

From: [email-masked]
Date: Tue, 15 Feb 2011 11:15:37 +0800

Hi Authors,

I have a comment on loss measurement in this draft.

After receiving LM Query message, the responder would reply LM Response 
message which should take some counters. But I can't find text in this 
draft to describe how the counting function at the responder is switched 
on. IMHO one more bit/flag should be defined  in the LM Query message to 
activate or deactivate the counting function at the responder.
Did I miss something?

Best Regards,
Xiao Min

Ross Callon <[email-masked]> 
发件人:  [email-masked]
2011/02/07 11:33

收件人
"[email-masked]" <[email-masked]>
抄送

主题
[mpls] MPLS WG Last call on draft-ietf-mpls-loss-delay-01

Working Group,

 

Ross, Loa, and George
 
MPLS WG co-chairs
 
 _______________________________________________
mpls mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls

---

From: Dan Frost <[email-masked]>
Date: Tue, 15 Feb 2011 16:06:37 +0000

Hi Ben,

> I have reviewed draft-ietf-mpls-loss-delay-01 and have the following

Thanks a lot for your detailed review and comments!

> 1) The final loss, throughput, or delay calculations may be performed
> either by the querier or by another post-processing system (e.g., a
> network management server).  For unidirectional measurements this can
> be accomplished simply by sending the out-of-band response to the
> bidirectional measurements the querier can forward the final
> measurement message using the same out-of-band mechanism used by the
> responder to the address of the desired post-processing system.  Some
> port-processing systems may have the ability to store measurement data
> for an extended measurement period and produce a variety of useful
> statistics from the measurement data.  Use of an off-line
> post-processing system also allows the measurement function at the
> querier to be completely stateless.  The option to support off-line
> post-processing should be included (and should require only a small
> amount of additional text to describe).

Agree that this is a useful option and also that it shouldn't require
much in the way of new text.  We'll take this up.

> 2) In section 1 the work “packet” should be deleted from the bullet
> “The LM protocol supports both 32-bit and 64-bit packet counters.”
> since octet counters are also supported.

Sure.

> 3) In section 2.1 the received packet count is described as not
> including the LM packet itself. Unless the LM messages are excluded
> from the counting altogether, it may be easier to include the LM
> packet in the count as it must be received (and likely would be
> counted) before it is recognized as andLM packet and further
> processing occurs.  It may be easier to add one to the count when the
> LM message is sent than to subtract one when the LM message is
> received.  It could also be specified that the sending count does not
> include the LM packet and the receiving count does and the correction

The practical side of this is currently covered by Section 4.1.8 which
states that all G-ACh packets are excluded from the count by default.  A
key reason for this is the possibility of intermediate nodes injecting
traffic into the G-ACh.

> channel during the interval" would be better without "sustained" which
> tends to suggest a constant rate.

OK.

> throughput." should be expanded since the values recorded allow
> calculation of both offered throughput and delivered throughput.

OK.

> 6) In 2.2 the phrase "As for loss measurement," should be deleted
> since this section is about throughput measurement (and the particular
> sentence appears to be as well).

Ah, the intended meaning was "Just as with loss measurement..."  Will
rephrase.

> 7) It is noted that due to the TC of the measurement messages they may
> be reordered with respect to other packets. It should be further noted
> somewhere that, while this can affect individual measurements in the
> direct measurement method, the packet loss rate (derivative of packet
> loss measurement) can still be accurately determined over time.  Some
> places where this might be noted are in 2.7.2, 2.7.3, and/or 2.7.6.

Good point; thanks.

> 8) Presumably the editor's note in 2.7.5 is no longer needed.

Right.

> 9) In 3.1 there should be a notification value (0x5?) for the case
> that the egress measurement resource is preempted or released by an
> administrator (indicating the measurement session should end).

OK.

> 10) In 3.1 the case of "Unsupported Version" is indicated as an error.
> It may be better to make this a notification so that the querier can
> decide whether or not the earlier version responder can nevertheless
> provide useful data.  There may be cases in which the responder does
> not have to be upgraded to make beneficial use of additional
> information (e.g. in TLVs) sent by the querier and returned (without
> being understood) in the response message.  If this is desirable, then
> 4.1.4 should indicate that optional TLVs are copied in the response if
> they are not understood.

Regarding the version, it would seem to make the most sense for the
querier to adapt to a lower-version responder by retrying the
measurement operation with a lower version.

Regarding TLV-copying, this could be useful, but it would have to use
some other mechanism, as requiring that all unknown optional TLVs be
copied wouldn't make sense for any of the currently-defined optional
TLVs, for example!  If there's a need for a querier to attach opaque
data that just gets copied by the responder, defining a single TLV for
that purpose might be enough.

> 11) In 3.1 the control code 0x15 mentions "Destination Node
> Identifier" -- is this the Destination Address (TLV 129)?  If not, to
> what does it refer?
>
> 12) In 3.1 to what does the "channel identifier supplied in the query"
> refer in the description of control code 0x16?

These exist to support MPLS-TP-style identifiers
(draft-ietf-mpls-tp-identifiers), although TLVs for them haven't been
defined yet.

> 13) In 3.2 the description of the Flags field is a bit confused.  It
> refers to similarity with 3.1 and the X flag (which is in the DFlags
> field, not in the Flags field).

Oops!  It should say "As specified in Section 3.1.  The T flag in a DM
message is set to 1."  Will fix that, thanks.

> 14) In 3.5.3, since it is likely that the minimum supported LM
> interval will vary for different endpoints and that useful
> measurements are not necessarily dependent on the interval chosen, it
> would be more useful for the suggested process to be the following:
> The querier need not send a Session Query Interval TLV in the initial
> LM query, the responder SHOULD send a Session Query Interval in the
> initial responses (indicating the minimum supported interval), the
> querier SHOULD send a Session Query Interval TLV in subsequent LM
> queries indicating the interval chosen (greater than or equal to the
> minimum supported by the responder).  On seeing the TLV from the
> querier the responder may cease including the TLV, and on seeing the
> TLV not included in the response the querier may cease sending the
> TLV.  This has the advantage of quickly finding an agreeable rate and
> always initiating a measurement without requiring the administrator or
> querier to know the capabilities of the responder a priori.

This sounds reasonable; we'll consider the options here.

> accumulated to provide a total loss measure. It should also be noted
> that this data can be used to calculate a loss rate.

OK.

> 16) In 4.1.2 the querier sets counter 1 to the count of packets sent
> before the LM query message.  It could also indicate that this value
> may be set to zero until the counting resources have been engaged
> (e.g., if waiting for a favorable response from the responder before
> beginning the measurement process).

OK.

> 17) 4.1.5 should state that it is also possible to forward the final
> LM message (containing all counts) to another location for
> post-processing.

OK.

Thanks again!

-d

---

From: Dan Frost <[email-masked]>
Date: Wed, 16 Feb 2011 11:02:46 +0000

Hi Xiao Min,

On Tue, Feb 15, 2011 at 11:15:37AM +0800, [email-masked] wrote:
> After receiving LM Query message, the responder would reply LM
> Response message which should take some counters. But I can't find
> text in this draft to describe how the counting function at the
> responder is switched on. IMHO one more bit/flag should be defined  in
> the LM Query message to activate or deactivate the counting function
> at the responder.  Did I miss something?

There should be no need for a separate activation flag or message.  The
last paragraph of Section 4.1.1 explains what the responder can do if it
is not yet ready to provide counter data.  It can simply not respond
until it is ready, or it can respond with an appropriate notification
code in the meantime (the appropriate code in this case would be
Notification - Initialization In Progress, described in Section 3.1).

Cheers,

-d

> Best Regards, Xiao Min

---

From: [email-masked]
Date: Thu, 17 Feb 2011 09:31:56 +0800

Hi Dan,

To my understanding, the texts you referred explain what the Querier and 
the Responder should do if the counting function at the Responder is not 
ready, but there is no text about how to switch on/off this counting 
function at the Responder. AFAIK counting at the Responder won't be 
switched on automatically after power up, and some operation is needed to 
make counting begin. I think this point is also necessary to be explicitly 
defined.

Best Regards,
Xiao Min

Dan Frost <[email-masked]> 
2011/02/16 19:02

收件人
[email-masked]
抄送
[email-masked]
主题
Re: [mpls] MPLS WG Last call on draft-ietf-mpls-loss-delay-01

Hi Xiao Min,

Cheers,

-d

---

From: Dan Frost <[email-masked]>
Date: Fri, 18 Feb 2011 12:14:39 +0000

Hi Xiao Min,

On Thu, Feb 17, 2011 at 09:31:56AM +0800, [email-masked] wrote:
> Hi Dan,
> 
> To my understanding, the texts you referred explain what the Querier
> and the Responder should do if the counting function at the Responder
> is not ready, but there is no text about how to switch on/off this
> counting function at the Responder. AFAIK counting at the Responder
> won't be switched on automatically after power up, and some operation
> is needed to make counting begin. I think this point is also necessary
> to be explicitly defined.

To put it another way, the initial query message is itself the signal to
the responder to take whatever initialization actions are required for
it to begin generating useful responses.  Such actions may include
"switching on the counting function" or anything else, and are
implementation-dependent.

-d

---

From: [email-masked]
Date: Mon, 21 Feb 2011 09:23:46 +0800

Dan,

I agree with you that the initial LM query message may be treated as 
counting 
activation message, but that requires the responder to differentiate the 
first 
LM query and other LM queries, and it's still not sure how to switch off 
the 
counting function at the responder when the LM function finished.

BRs,
Xiao Min

2011/02/18 20:14

收件人
[email-masked]
抄送
[email-masked]
主题

Hi Xiao Min,

-d

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 21 Feb 2011 14:23:50 +0000

Responder can switch off the counting if not receiving the LM message for certain time.

Linda Dunbar

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Sunday, February 20, 2011 7:24 PM
To: Dan Frost
Cc: [email-masked]
Subject: Re: [mpls] MPLS WG Last call on draft-ietf-mpls-loss-delay-01

Dan,

I agree with you that the initial LM query message may be treated as counting
activation message, but that requires the responder to differentiate the first
LM query and other LM queries, and it's still not sure how to switch off the
counting function at the responder when the LM function finished.

BRs,
Xiao Min

2011/02/18 20:14

收件人

[email-masked]

抄送

[email-masked]

主题

Hi Xiao Min,

-d

---

From: [email-masked]
Date: Tue, 22 Feb 2011 09:01:30 +0800

It sounds acceptable but IMHO not the preferred resolution on this issue.
I think it's better to have explicit notice from the Querier to the 
Responder 
about the counting activation/deactivation and acknowledgement from the 
Responder 
to the Querier is also needed.
Anyway, the corresponding text deserves to be added to this draft.

BRs,
Xiao Min

Linda Dunbar <[email-masked]> 
2011/02/21 22:23

收件人
"[email-masked]" <[email-masked]>, Dan Frost 
<[email-masked]>
抄送
"[email-masked]" <[email-masked]>
主题
RE: [mpls] MPLS WG Last call on draft-ietf-mpls-loss-delay-01

Responder can switch off the counting if not receiving the LM message for 
certain time. 
 
Linda Dunbar
 
From: [email-masked] [mailto:[email-masked]] On Behalf Of 
[email-masked]
Sent: Sunday, February 20, 2011 7:24 PM
To: Dan Frost
Cc: [email-masked]
Subject: Re: [mpls] MPLS WG Last call on draft-ietf-mpls-loss-delay-01

Dan, 

BRs, 
Xiao Min 

收件人
[email-masked] 
抄送
[email-masked] 
主题

Hi Xiao Min,

-d