Subject: [Pce] Proposed response liaison to ITU-T Study Group 15

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 17 May 2005 10:25:32 +0100

All, 

We owe a response to the liaison received in April from the ITU-T SG15. 

I propose the following. Please send your comments ASAP. 

Thanks,
Adrian
===
To:  Hing-Kam Lam, Rapporteur Q14/15
      Malcolm Betts, Rapporteur Q12/15
      Jerry Shrimpton, Rapporteur Q6/15
From: Adrian Farrel and JP Vasseur, co-chairs IETF PCE working group
Cc: Alex Zinin and JP Vasseur, IETF Routing Area Directors
Subject: Response Liaison Statement on the PCE Working group
For: Action
Deadline: July 30th 2005 

The IETF's PCE Working Group would like to thank Questions 6, 12 and 14 of 
ITU-T Study Group 15 for their response liaison on the PCE working group. We 
welcome the prospect of cooperation between our organisations on this 
subject. 

We note your reference to Recommendation G.8080 and observe that there is, 
indeed, mention of the 'Route Table Query interface' that is used to allow a 
Signaling Controller to resolve an 'unresolved portion of the route.' 

Nevertheless, our reading of G.8080 is that the 'Route Table Query 
interface' exists between the Signaling Controller and the Routing 
Controller. If this is the case, it does not match the architectural model 
that we are proposing within the PCE working group. That is, we are making a 
distinction between the distribution and maintenance of TE routing 
information by the Routing Controller, and the computation of paths as 
performed by the Path Computation Element. Thus, in the PCE architecture, 
there may be a physical separation between the Routing Controller 
responsible for the routing-plane management of a transport entity, and the 
PCE responsible for satisfying Path Computation Requests issued by the 
Signaling Controller responsible for the signaling-plane management of the 
transport entity. This means that we are implying a functional separation 
between the items listed at the head of section 7.3.2 of G.8080 where such a 
separation is not possible within the ASON architecture as currently stated. 
If we have misunderstood the architecture as stated in G.8080 we would 
appreciate clarification from you. 

In any case, we would welcome your review and comments on our architecture 
draft which can be found at 
http://www.ietf.org/internet-drafts/draft-ietf-pce-architecture-00.txt 

Question 6 asked a specific question about the objective metrics referred to 
in the PCE charter... 

> Q.6/15 (Characteristics of optical systems for terrestrial transport
> networks) noted that your charter contains the following item:
> "- Definition of objective metrics to evaluate various criteria such as
> the measurement of path quality, response time, robustness and scalability
> of path computation models." 
> 
> Could you please clarify the meaning of "path quality" in the above
> definition? If this includes optical monitoring aspects, please be aware
> that ITU-T Q.6/15 has developed a Recommendation, G.697, Optical
> monitoring for DWDM systems which may be of interest to the PCE working
> group. This Recommendation is currently in force.

Path quality in this context is intended to describe what is sometimes 
termed the 'optimality' of the path ('route' in G.8080 terminology). 
Measures of path quality reflect the ability of a PCE model to deliver a 
path that satisfies the constraints specified by the requesting client. One 
such quality might be 'shortest path', and it should be clear that once 
Routing Areas or Layered Networks are in use, different computation models 
will have different abilities to compute shortest paths. 

Thus, there is no intention to measure the active quality of the 'path' 
within the data plane: This is out side the scope of the PCE working group. 
Note that there is also no intention to measure the effectiveness of the 
algorithms in use, but rather the likely ability of a particular interaction 
between PCEs to produce an adequate path. 

Your liaison goes on to ask a further question about the intentions of the 
PCE working group with respect to optical path quality. 

> In addition, we would appreciate a better understanding of whether the PCE
> working group will study mechanisms by which optical path quality can be
> calculated or only mechanisms for communicating the results of such
> calculations.

We assume that here, too, you are refering the quality parameters of an 
established optical trail, and not to the quality of the computed path as 
expressed above. The PCE working group is limited to the architectural 
models for computation of paths ('routes') through networks, and will not 
examine the measurement of optical characteristics. 

Note, however, that path computation as applied to GMPLS systems falls 
within the scope of the PCE working group. It is likely that future GMPLS 
control planes will require to compute paths bearing in mind optical 
constraints such as (but not limited to) wavelength continuity, dispersion 
characteristics, etc. In these cases, it will possibly be necessary for some 
optical characteristic information to be gathered from the data plane, and 
distributed within the routing plane. Nevertheless, these two functions will 
remain outside the scope of the PCE working group. 

Anyone interested in discussing the work of the PCE working group further is 
invited to join the PCE mailing list. Details can be found at 
http://www.ietf.org/html.charters/pce-charter.html 

Best regards,
Adrian Farrel and JP Vasseur 

_______________________________________________
Pce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pce

---

From: "Brungard, Deborah A, ALABS" <[email-masked]>
Date: Tue, 17 May 2005 10:15:39 -0500

Looks good Adrian. Just a minor suggestion of wording in the third
paragraph, "is not possible within the ASON architecture" -> "is not
recognized within the..".

As you know, the SG15 meeting is on-going. If you send it by the end of
this week (cc'd to the Rapporteurs), if it does not make the agenda, it
will at least get visibility at the meeting.

On the paragraph referring to future GMPLS control plane work, you may
want to include reference to initial work by the ipo group and the
completion of RFC4054 as this is of interest to Q6/15.

Regards,
Deborah

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Adrian Farrel
Sent: Tuesday, May 17, 2005 5:26 AM
To: [email-masked]
Cc: [email-masked]
Subject: [Pce] Proposed response liaison to ITU-T Study Group 15

All, 

Thanks,
Adrian
===

The IETF's PCE Working Group would like to thank Questions 6, 12 and 14
of 
ITU-T Study Group 15 for their response liaison on the PCE working
group. We 
welcome the prospect of cooperation between our organisations on this 
subject. 

We note your reference to Recommendation G.8080 and observe that there
is, 
indeed, mention of the 'Route Table Query interface' that is used to
allow a 
Signaling Controller to resolve an 'unresolved portion of the route.' 

Nevertheless, our reading of G.8080 is that the 'Route Table Query 
interface' exists between the Signaling Controller and the Routing 
Controller. If this is the case, it does not match the architectural
model 
that we are proposing within the PCE working group. That is, we are
making a 
distinction between the distribution and maintenance of TE routing 
information by the Routing Controller, and the computation of paths as 
performed by the Path Computation Element. Thus, in the PCE
architecture, 
there may be a physical separation between the Routing Controller 
responsible for the routing-plane management of a transport entity, and
the 
PCE responsible for satisfying Path Computation Requests issued by the 
Signaling Controller responsible for the signaling-plane management of
the 
transport entity. This means that we are implying a functional
separation 
between the items listed at the head of section 7.3.2 of G.8080 where
such a 
separation is not possible within the ASON architecture as currently
stated. 
If we have misunderstood the architecture as stated in G.8080 we would 
appreciate clarification from you. 

In any case, we would welcome your review and comments on our
architecture 
draft which can be found at 
http://www.ietf.org/internet-drafts/draft-ietf-pce-architecture-00.txt 

Question 6 asked a specific question about the objective metrics
referred to 
in the PCE charter... 

path that satisfies the constraints specified by the requesting client.
One 
such quality might be 'shortest path', and it should be clear that once 
Routing Areas or Layered Networks are in use, different computation
models 
will have different abilities to compute shortest paths. 

Thus, there is no intention to measure the active quality of the 'path' 
within the data plane: This is out side the scope of the PCE working
group. 
Note that there is also no intention to measure the effectiveness of the

algorithms in use, but rather the likely ability of a particular
interaction 
between PCEs to produce an adequate path. 

Your liaison goes on to ask a further question about the intentions of
the 
PCE working group with respect to optical path quality. 

We assume that here, too, you are refering the quality parameters of an 
established optical trail, and not to the quality of the computed path
as 
expressed above. The PCE working group is limited to the architectural 
models for computation of paths ('routes') through networks, and will
not 
examine the measurement of optical characteristics. 

Note, however, that path computation as applied to GMPLS systems falls 
within the scope of the PCE working group. It is likely that future
GMPLS 
control planes will require to compute paths bearing in mind optical 
constraints such as (but not limited to) wavelength continuity,
dispersion 
characteristics, etc. In these cases, it will possibly be necessary for
some 
optical characteristic information to be gathered from the data plane,
and 
distributed within the routing plane. Nevertheless, these two functions
will 
remain outside the scope of the PCE working group. 

Anyone interested in discussing the work of the PCE working group
further is 
invited to join the PCE mailing list. Details can be found at 
http://www.ietf.org/html.charters/pce-charter.html 

Best regards,

---

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Tue, 17 May 2005 11:45:54 -0500

Hi Adrian,

The liaison looks good.

Regarding:

> > "- Definition of objective metrics to evaluate various criteria such
> > as the measurement of path quality, response time, robustness and 
> > scalability of path computation models." 
> > 
> > definition? If this includes optical monitoring aspects, please be
> > aware that ITU-T Q.6/15 has developed a Recommendation, G.697,
> > Optical monitoring for DWDM systems which may be of interest to the
> > PCE working group. This Recommendation is currently in force.
 
> Path quality in this context is intended to describe what is 
> sometimes termed the 'optimality' of the path ('route' in G.8080
> terminology). Measures of path quality reflect the ability of a PCE
> model to deliver a path that satisfies the constraints specified by
> the requesting client. One such quality might be 'shortest path',
> and it should be clear that once Routing Areas or Layered Networks
> are in use, different computation models will have different
> abilities to compute shortest paths. 
> 
> Thus, there is no intention to measure the active quality of 
> the 'path' within the data plane: This is *outside* the scope of
> the PCE working group. 

Agreed.

> Note that there is also no intention to measure the effectiveness
> of the algorithms in use, but rather the likely ability of a 
> particular interaction between PCEs to produce an adequate path.

I'm not sure what this sentence means.  There is an intention to control
the effectiveness of the algorithms, as stated in Section 6.1.1 of
http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protocol-gen-req
s-00.txt:

"The path request message MUST support the ability to prefer/customize
various path computation objective functions, policies and optimization
criteria.  For example, a PCC may be aware of and would like to choose
from among various objective functions that a PCE may offer, and the PCE
communication protocol SHOULD allow this to be specified per path
computation request."

Perhaps the comment could be rephrased and/or clarified to express what
is done rather than what isn't done.

Thanks,
Jerry