- 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:
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.)
Yes this has been one major point of controversy after the publication
of this id. As the authors, we have seriously considered the
possibilities of introducing such metrics and methodologies into this
document, but provided the big variety of interfaces that GMPLS will
control, it is difficult to integrate everything into one document.
Recently members of the author team are discussing the ways to address
this issue, in another document targeted for either CCAMP or BMWG. This
can be a technically reasonable approach, because unlike the signaling
delay, which changes as traffic load and network topology change, the
data plane metric as you put it, or more precisely the delay in between
the completion of the signaling process and the completion of the
cross-connection programming, is more persistent and not sensitive to
traffic load and network topology. This can be benchmarked in a lab
environment and the value is persistent for an implementation. Because
of this, I personally believe separating this out will not sacrifice the
integrity of the current id. Of course, we are always open for more
suggestions from GMPLS and benchmarking experts for other ways out.
Hope you and others will be happy with this reply.:)