Subject: [Pce] RE: Pce Digest, Vol 7, Issue 11

From: "Hani El-Sakkout \(hsakkout\)" <[email-masked]>
Date: Fri, 18 Mar 2005 19:58:51 +0100

Hi,

Thank you for a set of clear and pretty comprehensive minutes.

I raised a question on whether PCE's will be allowed to exchange
arbitrary information (in an arbitrary format). 

The answer at the time was yes.

I can see a similar question listed as a question on PCE information
exchange, but I don't believe it captured this question and answer
precisely.

Best regards,

Hani El-Sakkout

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]
Sent: Friday, March 18, 2005 12:07 PM
To: [email-masked]
Subject: Pce Digest, Vol 7, Issue 11

Send Pce mailing list submissions to
	[email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
	https://www1.ietf.org/mailman/listinfo/pce
or, via email, send a message with subject or body 'help' to
	[email-masked]

You can reach the person managing the list at
	[email-masked]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Pce digest..."

Today's Topics:

   1. PCE WG meeting: draft minutes (JP Vasseur)

----------------------------------------------------------------------

Message: 1
Date: Fri, 18 Mar 2005 11:04:17 -0500
From: JP Vasseur <[email-masked]>
Subject: [Pce] PCE WG meeting: draft minutes
To: [email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain; charset="windows-1252"

Hi,

Please find below the draft minutes of the PCE WG meeting. Let us know  
if you have comments:

A special thank to Jaudelice and Zafar for having taken the minutes.

PCE WG meeting minutes - IETF-62 - Minneapolis
---------------------------------------------------------------

CHAIR REPORT
----------------------

Work group established, WG should concentrate
on first milestones: G/MPLS TE and Simple configurations (Inter-area  
TE) first

Milestones have very aggressive timeline

Applications for PCE: Encouraged to continue to work on applications
for PCE (though out of scope for the moment). Not to expect to become
WG document, but encouraged to work on future applications.

Work in progress to be presented today:

- Draft on PCE architecture
- Draft on PCE discovery requirements and protocol extensions
- Draft on PCE communication

Immediate next work:

Draft on PCE communication protocol specification
Draft on PCE discovery protocol
Draft on objective metrics

End of chair report
-------------------

Question from audience on objective metrics: Metrics to evaluate PCE.

JP gave a few examples of metrics of interest:
E.g., How fast you can respond to topology changes, etc.

First presentation: draft-ash-pce-architecture-01.txt, Jerry Ash
------------------------------------------------------------------------

----

Drafts discusses terminology, assumptions, motivation, architectural
considerations, security & confidentiality and evaluation metrics.

Issued raised on the list - already responded (text added to several
sections with respect to every comment)

added to 6.4: PCE should advertise capabilities
added to 6.6: Path computation request include if near-disjoint paths
acceptable
added to 6.7: TED information can include info from sources other than  
IGP
added to 6.8: elaborate on advantages of stateful PCE & pitfalls of  
using
stateful PCE in a distributed PCE environment
added to 7: Further metrics proposed to evaluate PCE solutions

next steps: propose draft as PCE WG draft

Questions raised:
------------------
Question: Concern raised on how feasible is the considered approach
(stateful PCE).

An element performing optimal computational might take infinite time to

do
so.  Concern about delegating the distributed control plane  
responsibility
to PCE.

Question on possibility of unsolicited requests
PCC-to PCE request/PCE-PCC reply or also unsolicited requests possible?

PCE-PCE communication: communicating paths exchange only or other is it
possible to communicate other info as well?

Are there specific requirements on response time of PCE? (for global
optimization)

JP: will be part of the evaluation metrics.

Kireeti: need to be careful with pce, not trying global optimal solution
stateful x stateless: can't keep all info on lsps (costly)

message sent to ITU-T about PCE working group. What is in the ITU-T?
Audience member said that G7715 on ITU-T has similar function.

Dimtri asked a question on stateful vs. stateless PCE in the document;  
how feasible is stateful PCE? Is it reasonable to assume stateful PCE?

Jerry: yes for some applications.

Dimitri: Is this can be assumed manageable? Given control to PCE that  
is otherwise done by a distributed control plan.

JP added: It's applicable for some applications requiring global  
optimization.

Kireeti: (Global Optimality) is NOT a good target. Stateful PCE  
provides lot of complexity, while nice- not feasible.

Dimitri: Re; global optimization, what is responsible?

JP: Evaluation Metric is to be used for this purpose.

Igore: Similar comments for stateful vs. stateless.

Adrian: ITU-T also requires similar functionality. Liaison Statement to

ITU-T is completed. We think SG-15 would be a god start.

J. Sadder: Yes, there is similar work pursued at ITU-T.

JP Pooled the audience for the Architecture document.

JP: Majority in favor it as a WG document. We will confirm at the  
mailing list.

Second presentation: draft-leroux-pce-discovery-reqs.txt, Jean-Louis
------------------------------------------------------------------------

------------
PCE Discovery requirements

The draft addresses PCE discovery within and across domain(s).

Remaining issues:

Address comments received in the next version

* Need to improve security particularly for Inter-AS PCE discovery
* Discovery of dynamic parameters such as the PCE CPU state
* PCE aliveness detection

Consensus for a WG doc?

Questions raised:
---------------------

Kiretti: Discovery of PCEs: better rely on PCE-PCE communication?

comment2: If there is a need, routing is a better place than signalling.

JP reminded that the document is just identifying requirements but not
solutions.

Confusion on slide showing ABR acting as PCEs (PCEs seem not needed).  
How
did the 60 seconds rule was defined? Need to include how that was  
decided.

Dimitri: Are we not already overloading the PCEs? Need to define the  
right
level of abstraction... It is an open question. Needs further  
discussion. Correct the overload problem before hand.

Concern: Enumeration of the set of minimum requirements. Right now it
shows an enumerations of possible solutions. Need to focus on minimal
requirements.

JP: Reminder that the draft is in its first version.

Kireeti: Re: flooding dynamic state of the PCE, if PCE discovery  
includes CPU load factor, it will complicate the PCC system.

Dimitri: you haven't design the system and are worried about the  
overloaded system. General problem of the overload should be solved at  
the root (architecture).

Tony Li: As far as process is concerned, start off with a good  
requirement document, enumerate minimum set of requirements. What you  
got right now is iteration from the solution space. Focus on minimum  
requirement and what is the basic problem we are trying to solve.

Adrian: This was only first revision of the document.

Igor: We need to advertise backup PCE, why backup PCE and not  
load-balanced.

JL: The SP thinks that having a dedicated backup could also be useful.  
But this is optional.

JP: Few sensitive topics like advertisement of dynamic capability needs

more discussion on the mailing list.

Richard Rabbot: Not all ABR are PCE in your Figure.

JL: It is just an example case used for illustration purpose only.

Richard Rabbot: How did you come up with 60 second requirement?

JL: There are number of SP on the ID and we think 60 sec is a good  
target. Will provide more details on this.

Dimitri: Does these requirements covers inter-AS case?

JL: Yes.

Dimitri: If today a router may be overloaded and we don't do anything  
specific, should we worry about PCE overloaded cases? We need to make  
sure that right level of details are provided in the document. The  
basic stuff like, how to find reachable addresses is not there in the  
document. We don't have basic stuff in the document.

JL: No reachability stuff is detailed in the document. There is mention

of domain ID-es: area-ID & AS number.

JP: This is not a flushed out version. Thanks to DT for their effort in

putting this together. Requires more discussion in the mailing list  
before asking to adopt this ID as a WG document.

Third presentation: draft-ash-pce-comm-protocol-reqs-00, Jerry Ash
------------------------------------------------------------------------

----------
PCE/PCE Communication requirements (PCC-PCE & PCE-PCE)

Various issues raised on the list: for example extensive discussions  
about re-use of RSVP object encodings

Questions raised:
----------------------

Arthi: Is there a requirement of unsolicited PCE to PCC communication.

Zafar: Yes, there are cases where unsolicited PCE to PCC communication  
is required.

Many: Is it suitabe to list candidates on this documents?

JP: candidates are out of the scope of this protocol. Document is a  
very first cut.

Kireeti: Stateless x stateful. There are needs and there are benefits.

Comment: Contradiction, scalability reqirements.

Dimitri: on QOS/ CAC in the slides, do you also expect PCE to make  
decision that is related to the forwarding plan?

Jerry: The intension was to mention requirement to include some QOS  
parameters in the PCC-PCE messages.

JP: clarified that the intention was to include possibility of QoS
considerations in path computation.

JP/ Jerry: I.e., Path Computation Constraints related parameters.

Kireeti: On GR of PCE: When it comes to GR, there is a huge difference  
between stateful and stateless PCE. Recommend to put it in an  
applicability statement.

JP: Yes, complexity analysis is meant for this purpose.

Adrian/ JP: Estimates some work to flush-out details. It's a huge list  
of requirements. We want to handle simple problem first. Candidate  
protocols are not considered or within scope.

Zafar: Relationship with other WG-es.
Adrian: Initial thought is to get such input from CCAMP. E.g., GMPLS  
usage of PCE, inter-domain stuff is example of cases where input from  
CCAMP is needed.

Dimitri: on Head-less optical nodes.
GMPLS requirements from CCAMP.

Conclusion: Needs more discussion on the list. This document will be the
basis of the work.

Other discussions:
-----------------
CCAMP was to provide areas where PCE would be useful. There is already a
draft on the GMPLS use of PCE.

JP mentioned that many of the drafts were posted recently and did not  
have
a slot in this meeting mostly because the focus was on the main  
documents
and to flash out the requirements

JP/ Adrian: Many of the drafts were put in and right now we are  
flushing out first milestone. Other applications will be addressed  
later. Charter at present does not include candidate (solutions).  
Questions like what layer PCE should work on? Should PCC-PCE be based  
on a reliable transport? TCP is reliable, is it a candidate? are among  
the question charter addresses.

Discussion on statement on the requirement of reliability.

Dimitri: The biggest question is if we can use RSVP for PCC-PCE  
communication.

Zafar: It's funny that when we talk about IGP-es, people settle with  
what we have today, and when it comes to signaling we tent to have such

a large diversion. In my opinion signaling is a very small piece of the

overall architecture and we should make use of what we have today.

Dimitri: But RSVP is design for label exchange and not PCC-PCE  
communication. What about transport.

Zafar: Let's be clear on what we mean here. We are talking about use of

RSVP for encoding. At the transport level we can still rely on TCP.

Kireeti: Not for RSVP as PCC-PCE protocol. It's not defined for this  
purpose.

Zafar: We know that PCC is going to signal using RSVP-TE, why not  
provide information encoded in RSVP format to minimize useless copying  
of the data (from one format to the other).
Kireeti: Not all objects are defined for RSVP today.

Zafar: The new objects can be defined. There are also other  
applications for the use of the objects require by PCE.

Kireeti: Well, this is convoluted; we don't have support for all so  
let's extend RSVP, which is not designed for this purpose.

Mathew: PCC-PCE is a client server protocol. We've a lot of other  
client server based protocols. I recommend taking a look at such  
protocols.

Concern/Comment on RSVP usage and PCC-PCE communication

JP: Mention discussion of the design team on using RSVP encoding without
using RSVP itself

JP: Opinions about future candidates are welcome and the final  
coomunication will of course be the result of the WG consensus

* Comment/confusion on PCC being a node/client
* Comment agreeing with Dimitri
* Constraint that you can communicate using RSVP today. Agreeing with
Dimitri that we should first specify the needs/requirements.
* Comment on not excluding options that are not available today

Conclusion: To Continue on the mailing list

Dimitri: Question on the discovery of the PCE (possibility of
proxification mechanism for PCE discovery).

JP and Adrian.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 12563 bytes
Desc: not available
Url :
http://www1.ietf.org/pipermail/pce/attachments/20050318/5b0388a8/attachm
ent-0001.bin

------------------------------

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

End of Pce Digest, Vol 7, Issue 11
**********************************

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