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

Dan Frost <danfrost@cisco.com> Thu, 27 January 2011 12:22 UTC

Date: Thu, 27 Jan 2011 12:25:48 +0000
From: Dan Frost <danfrost@cisco.com>
To: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <20110127122548.GB27233@cisco.com>
References: <4D40C5DB.4000708@joelhalpern.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <4D40C5DB.4000708@joelhalpern.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: "mpls-tp@ietf.org" <mpls-tp@ietf.org>
Subject: Re: [mpls-tp] Requested review of draft-frost-mpls-tp-loss-delay-profile-00
Precedence: list

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

Re: [mpls-tp] Requested review of draft-frost-mpl… Dan Frost