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

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



Opps, missed a fairly important one in copying over my notes:

- As the draft is listed as a "Standards Track" document it needs to
  include some formal conformance language.  For a minimal example, see
  RFC2681's usage of RFC2119 language.  I think your choices are either
  make this document Informational or add the conformance language.

Thanks,
Lou

On 4/30/2009 5:29 PM, Lou Berger wrote:
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.