Subject: [CCAMP] I-D Action:draft-ietf-ccamp-lsp-dppm-09.txt

From: [email-masked]
Date: Sun, 27 Sep 2009 05:00:02 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title           : Label Switched Path (LSP) Dynamic Provisioning Performance Metrics in Generalized MPLS Networks
	Author(s)       : W. Sun, et al.
	Filename        : draft-ietf-ccamp-lsp-dppm-09.txt
	Pages           : 52
	Date            : 2009-09-27

Generalized Multi-Protocol Label Switching (GMPLS) is one of the most
promising candidate technologies for future data transmission
network.  GMPLS has been developed to control and operate different
kinds of network elements, such as conventional routers, switches,
Dense Wavelength Division Multiplexing (DWDM) systems, Add-Drop
Multiplexers (ADMs), photonic cross-connects (PXCs), optical cross-
connects (OXCs), etc.  The dynamic provisioning ability of these
physically diverse devices differs from each other drastically.  At
the same time, the need for dynamically provisioned connections is
increasing because optical networks are being deployed in metro
areas.  As different applications have varied requirements in the
provisioning performance of optical networks, it is imperative to
define standardized metrics and procedures such that the performance
of networks and application needs can be mapped to each other.

This document provides a series of performance metrics to evaluate
the dynamic LSP provisioning performance in GMPLS networks,
specifically the dynamic LSP setup/release performance.  These
metrics can be used to characterize the features of GMPLS networks in
LSP dynamic provisioning.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lsp-dppm-09.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Weiqiang Sun" <[email-masked]>
Date: Sun, 27 Sep 2009 20:16:32 +0800

Hi all,

Based on the LC comments and a final review by the authors, we have revised 
the LSP DPPM draft and the changes are summarized below.

1. ``The Maximum of Metric" added as 14.3
   The maximum of metric is the maximum of all the dT values in the
   sample.  In computing this, undefined values MUST NOT be included.
   Note that this means that measurements that exceed the upper bound
   are not reported in this statistic.  This is an important
   consideration when evaluating the maximum when the number of
   undefined measurements is non-zero.

2. A ``Metric Reporting" subsection is added to 4.8, 5.8, 6.8, 7.8, 8.8, 
9.8, 10.8, 11.8, 12.8, 13.7.
   In 4.8 and 6.8, the text is:
   The metric result (either a real or an undefined value) MUST be
   reported together with the selected uppper bound.  The route that the
   LSP tranverses MUST also be reported.

   In 5.8 and 7.8, the text is:
   The metric result (either a real or an undefined value) MUST be
   reported together with the selected uppper bound.  The route that the
   LSPs tranverse MUST also be reported.

   In 8.8, the text is:
   The metric result (either a real or an undefined value) MUST be
   reported together with the selected uppper bound and the procedure
   used (eg. either from the ingress node to the egress node, or from
   the egress node to the ingress node.  See Section 8.5 for more
   details).  The route that the LSP tranverses MUST also be reported.

   In 9.8, 10.8, 11.8 and 12.8, the text is:
   The metric results including both real and undefined values MUST be
   reported together with the total number of values.  The context under
   which the sample is obtained, including the selected parameters, the
   route traversed by the LSPs, and the testing case used MUST also be
   reported.

   In 13.7, the text is:
   The metric results including both real and undefined values MUST be
   reported together with the total number of values.  The context under
   which the sample is obtained, including the selected parameters, and
   the route traversed by the LSPs MUST also be reported.

3. One paragraph is added to 9.5, 10.5, 11.5, 12.5 and 13.5:
   It is important that in obtaining a sample all the LSPs MUST traverse
   the same route.  Ways to realize this is outside the scope of this
   document.  However, it is desirable that the method used have minimal
   impact on the signaling process and the method SHOULD be reported.

4. A bunch of non-technical changes.

Best regards,
Weiqiang

--------------------------------------------------
From: <[email-masked]>
Sent: Sunday, September 27, 2009 8:00 PM
To: <[email-masked]>
Cc: <[email-masked]>
Subject: [CCAMP] I-D Action:draft-ietf-ccamp-lsp-dppm-09.txt

> Title           : Label Switched Path (LSP) Dynamic Provisioning 
> Performance Metrics in Generalized MPLS Networks

> _______________________________________________
> CCAMP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp
>

---

From: Lou Berger <[email-masked]>
Date: Sun, 27 Sep 2009 09:32:45 -0400

>  impact on the signaling process and the method SHOULD be reported.

Weiqiang,
	A couple of question WRT the above paragraph:
- Wouldn't use of the same paths be useful in cases 5 and 7 too?
- Why not require the use of ERO (with RRO recording) to ensure the same
route rather than say it's out of scope?

Also, now that you have the Metric Reporting section, which I think is
great, you don't need to say what must be reported in the discussion
section.  For example the text in 4.6 that says "and the value MUST be
reported" is now redundant with 4.8, so should be dropped from 4.6.

Lou

---

From: "Weiqiang Sun" <[email-masked]>
Date: Sun, 27 Sep 2009 21:44:51 +0800

Hi Lou,

See below Please.

--------------------------------------------------
From: "Lou Berger" <[email-masked]>
Sent: Sunday, September 27, 2009 9:32 PM
To: "Weiqiang Sun" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: [CCAMP] I-D Action:draft-ietf-ccamp-lsp-dppm-09.txt

> - Wouldn't use of the same paths be useful in cases 5 and 7 too?
Yes, this should be added.

> route rather than say it's out of scope?
Yes the use of ERO may be good but not always necessary. For example, when 
linear topology is used (which is often used in fact), there is no need for 
including an ERO for the testing purpose.

> reported" is now redundant with 4.8, so should be dropped from 4.6.
OK.

---

From: Lou Berger <[email-masked]>
Date: Sun, 27 Sep 2009 09:50:56 -0400

Weiqiang,
	So why not say this + use ERO when needed?  Also, use of RRO is
required to report path, so should say this too.

Lou

On 9/27/2009 9:44 AM, Weiqiang Sun wrote:
> Yes the use of ERO may be good but not always necessary. For example,
> when linear topology is used (which is often used in fact), there is no
> need for including an ERO for the testing purpose.

---

From: "Weiqiang Sun" <[email-masked]>
Date: Sun, 27 Sep 2009 22:02:20 +0800

Lou, what about the text below?

   It is important that in obtaining a sample all the LSPs MUST traverse
   the same route. In case there may be multiple routes between the ingress
   node ID0 and egress node ID1, EROs can be used to ensure that all LSPs
   traverse the same route. In doing this, RROs may also be needed to record
   the route.

Thanks,
Weiqiang

Sent: Sunday, September 27, 2009 9:50 PM

---

From: Lou Berger <[email-masked]>
Date: Sun, 27 Sep 2009 10:33:56 -0400

Weiqiang,
	I think I wasn't clear that there are two points here:

On 9/27/2009 10:02 AM, Weiqiang Sun wrote:
>   traverse the same route. 

Shouldn't it be "MUST be used" rather than "can be used"?

> In doing this, RROs may also be needed to record
>   the route.
> 

My comment on RROs relate to the text in the document that says:
"The route that the LSP tranverses MUST also be reported."

To me this means that "an RRO MUST be included" when "the ingress node,
forms the Path message". (Methodologies sections.)

Lou