[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Working group last call: draft-ietf-ccamp-lsp-dppm-05

Authors,

I have some LC comments. I'll really only have general points:

- As always, please cleanup any idnits identified issues.

- In general it seems to me that for the performance metrics to be
  complete and fully useful a metric that quantifies data path
  availability relative to connection request and establishment is
  required.  In section 15 you do say:

   o  This document assumes that the correct procedures for installing
      the data plane are followed as described in [RFC3209], [RFC3471],
      and [RFC3473].  That is, by the time the egress receives and
      processes a Path message, it is safe for the egress to transmit
      data on the reverse path, and by the time the ingress receives and
      processes a Resv message it is safe for the ingress to transmit
      data on the forward path.  See [switch-programming] for detailed
     explanations. This document does not include any verification that
      the implementations of the control plane software are conformant,
      although such tests could be constructed with the use of suitable
      signal generation test equipment.  Note that, in implementing the
      tests described in this document a tester should be sure to
      measure the time taken for the control plane messages including
      the processing of those messages by the nodes under test.

  But I really don't think this is sufficient, and feel that data path
  metric parameters and related methodologies needs to be added to
  each of metrics/test cases.  If you'd like to indicate that
  these are OPTIONAL metric parameters, that is fine with me.
  But, IMO, the document is incomplete without them.  I have
  heard from others that they agree with this point too.  (I can
  try to get them to speak up publicly if this turns out to be
  necessary.)

- In the tests you treat all failures as an "undefined" result.  It
  seems to me that it would be more useful to identify and track
  (i.e., count) specific types of errors rather than just define
  all errors as "undefined" metrics.

- The document should be run through a spell checker, there are
  a number of spelling errors.

Lou

On 4/17/2009 12:25 PM, Lou Berger wrote:


This email begins a two week working group last call on
draft-ietf-ccamp-lsp-dppm-05.txt

http://tools.ietf.org/html/draft-ietf-ccamp-lsp-dppm-05

Please send your comments to the list or the authors before the last
call closes on May 1, 2009.