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

From: Vishwas Manral <[email-masked]>
Date: Sun, 11 Apr 2010 18:11:02 -0700

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.

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.

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.

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

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.

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.

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.

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.

Thanks,
Vishwas