Subject: Re: [mpls-tp] draft-frost-mpls-tp-loss-delay

From: Dan Frost <[email-masked]>
Date: Fri, 25 Jun 2010 16:02:23 +0100

Hi Vishwas,

Thanks for your review.  We haven't forgotten you.  :)  Please see
below.

Vishwas Manral <[email-masked]> writes:
> Hi,
>
> 1. Section 1.1 - I noticed that the section states packet loss as a
> percentage of user traffic. This is good however in a lot of cases we
> can overload special CC packets (BFD in this case) to measure loss.
> That does not seem to be taken care of.

Section 1.1 of the document simply quotes the MPLS-TP OAM requirements
(RFC 5860).  Comments on this text should really be addressed to the
authors of that document.  However, it seems to us that this definition
of loss is correct, regardless of the mechanism used to measure that
loss (e.g. measurement of user packets directly or via alternative
mechanisms like OAM proxy based on CC messages).

> 2. I have an issue with the loss measurement. As the Loss Measurement
> done is based on packet counters and counters can be reset on an
> individual device. There should be a way to tell the peer to reset the
> counters. Also receive counters should not be reset, or there should
> be a 2-way handshake before reset.

The version of the draft to be posted shortly includes a 64-bit sequence
number in the LM message format which is set to 0 following a session or
counter reset.  We believe that this will provide sufficient information
for handling these cases.  At this point we don't see a need for reset
instructions or negotiation, although if you would like to propose text
on these topics that's always welcome.

> 3. As this is a query and respnse protocol, it should be clearified
> that queries can be retransmitted in case the query itself is lost.

There is no retransmission in these protocols as such.  In the proactive
case packets are transmitted at a specific rate irrespective of
responses received and lost messages are replaced by their successors.
In case of something like on-demand DM, it is up to the application to
transmit another query in the event no response comes back.  We can make
this clearer in the text.

> 4. Do the counters include the query/ response message being sent or
> not?

This is explicitly addressed by the the definitions of A_TxP[n], etc. in
Section 2.2.

> 5. It seems that we should have seperate counters for each CoS if it
> is supported in the network. Otherwise packets sent after the query
> could be received before the query message thus skewing the
> measurement. The reverse is also true.

There is text to address the relationship of LM/DM to QoS in the
forthcoming draft version.

> 6. It seems that:
>
>    For accurate loss measurement to occur, packets must
>    not be sent between the time the transmit count for an outbound LM
>    message is determined and the time the message is actually
>    transmitted.
>
> This does not seem to be a reasonable requirement and I do not see a
> reason why this may be the case. Is it because of CoS.

It depends on the level of measurement accuracy required.  Perfect loss
measurement requires that the measurement operation be synchronized with
the data plane.  If this does not hold, inaccuracy will result and it
may be significant, especially since the loss rates of typical links
supporting MPLS-TP are expected to be quite small.

> 7. In section 2.3 Delay Measurement it states that
>
>    Suppose a bidirectional connection such as an MPLS-TP pseudowire,
>    bidirectional LSP, or Section exists between the LSRs A and B. The
>    objective is to measure at A one or more of the following quantities
>    associated with the connection:
>
>    o  The one-way delay associated with the forward (A to B) direction
>       of the connection;
>
>    o  The one-way delay associated with the reverse (B to A) direction
>       of the connection;
>
>    o  The two-way delay (A to B to A) associated with the connection.
>
>    Of course, if the first two quantities are known then the third is
>    immediate, being just their sum.
>
> If the last statement is true we do not need two timestamps one for
> receive and one for transmit at B (so T2 and T3 are the same). Though
> I think the statement is incorrect and should be (A->B) + dt + (B->A).
> We have time formats measuring in nanoseconds.

We have clarified the different types of two-way delay in the
forthcoming draft version.

> 7. As the response can have only one value at one time. I do not see
> why the control code for return messages are not serialized.

The idea is to provide some grouping of the response codes according to
type (e.g. success vs. notification vs. error) but these details will be
revisited later.

- Dan and Stewart

> Thanks,
> Vishwas

---

From: Vishwas Manral <[email-masked]>
Date: Wed, 30 Jun 2010 17:19:17 -0700

Hi Dan,

> Thanks for your review.  We haven't forgotten you.  :)  Please see

I certainly had forgotten I had sent this mail across. Thanks for
remembering me, even though a wee bit late. :))

> on these topics that's always welcome.
Sure let me send the details to you over the weekend.

> forthcoming draft version.
I searched for CoS and QoS in the latest draft and did not find any.

> supporting MPLS-TP are expected to be quite small.
It sound unreasonable to stop the data packets while the measurement
is in progress.

> forthcoming draft version.
OK.

> type (e.g. success vs. notification vs. error) but these details will be
That sounds reasonable but unclear in the document.

Thanks,
Vishwas