Subject: Re: [mpls-tp] Requested review of draft-frost-mpls-tp-loss-delay-profile-00

From: Dan Frost <[email-masked]>
Date: Thu, 27 Jan 2011 12:25:48 +0000

Hi Joel,

On Wed, Jan 26, 2011 at 08:09:47PM -0500, Joel M. Halpern wrote:
> At the chairs request, I have reviewed this document.  This document
> appears to be in good shape.  I have three minor comments that may be
> helpful.

Many thanks for your feedback!  Note that the current version of the
document is draft-ietf-mpls-tp-loss-delay-profile-01.

> 1) In the discussion of the delay measurement, the list of parameters
> whose negotiation is to be skipped does not match the list of default
> values.  Specifically, the parameter list does not include the T flag.

This is fixed in the current version.

> 2) There is something slightly confusing in the wording that is used
> in both the loss and delay sections about the setting of these
> parameters.  The wording is: A simple implementation may assume
> externally-determined configuration and need only support the
> functionality required by these defaults.
> 
> The reason I get confused is that "configured" is not the same as
> "forced to the defaults."  I believe that the intent is for something
> like: A simple implementation may assume that external configuration
> will ensure that both ends of the communication are using the default
> values for these parameters.

Your wording is clearer and we'll adopt it; thanks!

> 3) For the Loss measurements, should there be some explanation (a
> single sentence?) for why it is believed that 32 bit counters are
> appropriate when the protocol design allows for 64?  (Or is there
> something elsewhere in the MPLS-TP specs that says that MPLS-TP
> interfaces will always use 32 bit counters?  Or is the intention to
> mandate here such a hardware-oriented restriction?)

I would prefer to remove this parameter from the list, and propose to do
so.  The X flag mechanism is such that LM will work automatically
whether the endpoints have the same 32/64 capability or not, so there
doesn't seem to be a need to declare a default.

Cheers,

-d

> Yours, Joel