Subject: [Pce] Draft PCE WG Minutes - IETF-63

From: JP Vasseur <[email-masked]>
Date: Sat, 13 Aug 2005 10:20:32 -0400

(Please comment by August 27th)

----------------------------------
PCE Working Group meeting minutes
----------------------------------

IETF-63 - Paris, France - Tuesday, August 2, 2005.

(Thanks to Jaudelice and Deborah for having taken the minutes)

------------------
1. Agenda (Adrian)
------------------
1) Agenda/Admin (10mn)
2) Progress against milestones (5mn)
3) Drafts (55mn)
     - draft-ietf-pce-architecture-01.txt (Farrel - 10mn)
     - draft-ietf-pce-discovery-reqs-01.txt (Le Roux ‚Äì 10mn)
     - draft-ietf-pce-comm-protocol-gen-reqs-01.txt (Ash - 10mn)
     - draft-zhang-pce-comm-app-model-01.txt (Zhang - 5mn)
     - draft-vasseur-pce-pcep-01.txt (Vasseur - 10mn)
     - draft-choi-pce-metric-protocol-02.txt (Choi - 10mn)
4) Working Group next steps (20mn)

-----------------------------------
2. Progress against Milestones (JP)
-----------------------------------

1. Submit first draft of PCE architecture document: done
2. Submit first draft of PCE discovery requirements and protocol  
extensions documents
    (half-done: PCE discovery requirements ID is done)
3. Submit first draft of the PCE communication protocol requirements  
(done)
4. Definition of the objective metrics (to be done later - more  
progress required on other
IDs first)
5. PCE communication protocol specification (decision to be made by  
the WG soon)

-----------------------------------------------------------------
PCE Architecture ID: draft-ietf-pce-architecture-01.txt (Adrian)
-----------------------------------------------------------------

Adrian thanked everyone that contributed to help get this version out
Mainly editorial revisions resulting from Minneapolis meeting have  
been done (Clarifications, but nothing major)
More a framework, and an architecture overview and deployment scenarios.
Describes the architectural overview and building blocks
Many mailing list comments and private comments
Not any major substantial changes
Plan to add discussion of policy, will separate exchange of policy  
info in the PCE communication and the use of policy within the  
architecture

Question (?): present a functional view as well as component view?

Adrian: currently view point is third dimension

Arthi: policy – how will it be addressed in the document?

Adrian: the current doc will only have something high level – Lou  
will provide draft text

Igor: when I issue a path request, can I disallow paths requiring  
distributed computation,

Adrian: that’s something for the computation

Dimitri: is this the only document for policy or we will do something  
else ?

JP: we need requirements and solution detailed in a separate ID.

Lou: we had discussion, as Adrian said, we will have later a  
standalone document with more details after we have more discussion  
in the WG

Dimitri: in other WG, are discussing policy for interdomain, need  
that for this group

Adrian – agree

Plans: architecture is believed to be stable but needs discussions  
resulting from emails on the list.

------------------------------------------------------------------------ 
----------
Requirements for PCE Discovery: draft-ietf-pce-discovery-reqs-01.txt  
(Jean-Louis)
------------------------------------------------------------------------ 
----------

Set of requiretments for automatic pce discovery

comments and discussions on the list have been addressed in the new  
version -01
* multi-area example
* application scenario
* reorganized PCE info to be disclosed (mandatory versus optional)

It must be noted that this is optional in the pce discovery  
mechanism, not necessarily optional for pce architecture,
* extensibility section
* security requirements
* PCE capabilities definition is out of the scope (should be in a  
separate document)

Open issues:
- two stage discovery ? should limit to basic or include more  
detailed - all as part of this document
- security trust model- need to detail requirements
- need feedback on discovery of pce power and congestion status –  
should be part of this discovery mechanism or as part of a more  
detailed requirements phase?

Next steps:

* address open issues

Discussion

Dimitri: the question on one or two stage, for me it’s the question  
how many pces will we have – if only a small group, then number of  
sessions, with more detailed information, can be supported. Tradeoffs  
if small set, and all receive information, or if a lot of PCEs, may  
want only the subset that needs to know.

JP: could use a flooding based mechanism

Dimitri: but what is expected then on the use of this information ?

Arthi: It is premature to talk about solution. Do we have a sense of  
what direction we might be taking? On the section on scalability:  
number of pce pccs are factors but also should consider the load on a  
pce.
The details that you have might not be relevant to a PCE.

Dimitri: should say if the info is of interest to all the pces or not

Arthi: I’m less concerned with the PCE if the PCE is itself a PCC

Igor: Flooding is good, but it has problems: scalability and  
security. You still want to know the capabilities of pce so you may  
need to establish a session.

JP: we may now be discussing solutions on how to do basic  
capabilities and additional capabilities

Igor: we will need this discussion though

JP:  I don’t see this as pce discovery, this is a capabilities exchange

JL: Do you have an idea of a communication protocol

Igor: It should not be flooding.

JL: For general discovery we should use flooding.

JL: You must be able to control to which pcc you will be disclosing  
the information: all pccs in an area, etc.

Adrian: the draft though today does include some capabilities

Dimitri: can you provide requirements on more the dynamics needed for  
these capabilities

JP: A limited number of capabilities such as the congestion parameter  
is likely to be dynamic

Richard: propose discuss possible solutions over email exchange, even  
though it’s not to be included in the requirements, the discussion  
helps to understand

Arthi: agree should discuss to an extend some of the solutions

JP: thanks to quickly resolve the set of open issues. The draft  
should then be ready for Working Group LC.

------------------------------------------------
PCE Communication Protocol Generic Requirements
draft-ietf-pce-comm-protocol-gen-reqs-01.txt
(Jerry)
-----------------------------------------------

Generic requirements applicable to all PCEs

application-specific requirements to be addressed in separate  
requirements documents

A table with a summary is included.

Open Issues

* requirements for less constrained path requests/response
* requirements for responsiveness & session maintenance
* detailed requirements on throttling messages under overload
* specify ‘boundary’ numbers on scalability
* clearly state supported policy models & corresponding requirements/ 
implications
* avoid feature creep
* need to progress application-specific requirements
* PCE  protocol proposal needs to identify how generic & application- 
specific requirements are met

Discussion:

JP: Detailed scalability issues are related to implementation.

Adrian: we need a range as don’t want protocol to provide the limit

JP: on the less-constrained path computation topic, we don’t have a  
consensus yet, we should have a separate document

Arthi: we had a discussion in the pwe group that there may be  
requirements for pce

Adrian: by us splitting the document between generic and extended  
reqs (more application specific) we could handle this better

Arthi: also though may not be in scope

Adrian: yes we should say if it’s out of scope

Arthi: Some new requirements may come up for PCE, we need to have a  
plan on how to address that.

Adrian: The document is extensible.

Arthi: We might see other consumers of PCE

JP: Sure and the protocol should be designed to handle extensions so  
as to meet new requirements but we may need to recharter

---------------------------------------------
PCE Communication Protocol Application Model
draft-zhang-pce-comm-app-model-01.txt
(Zhang)
--------------------------------------------

* how to avoid contention with TE link fails
* how to load balance among PCEs
* how to update the PCEs about resource allocation

JP asked who has read the draft: good show of hands

Adrian: rather than saying this is the way forward, would prefer  
emphasis on what are the requirements

(coauthor of the draft ??): this draft addresses a way to ...

Adrian: yes, this draft has requirements on an implementation, would  
like first to see top level requirements and architecture

Igor: one of the requirements for the protocol is getting updates, etc,

Adrian: first need requirements

Igor: my view this is not a signaling protocol, not rsvp, we  
shouldn’t go thru the process of using a signaling protocol

JL: I have a major concern on scalability with the draft’s approach,  
one major bottleneck is on the PCE-PCE signaling, we should minimize  
the signaling, the objective is to have distribution to reduce this,  
whereas this draft re-introduces this overhead for synchronization.  
You are redefining the concept of cluster. Why not use the PCE engine?
One major bottleneck on the PCE architecture is the pcc-pce  
signalling. To ensure path computation, reduce the number of path  
computation requirements received by a pce.

Author: it does not consume much bandwidth.

JL: It is not a problem of bandwidth but communication overhead.

JP: I have similar concerns. Have you tried to evaluate what would be  
the overhead in term of extra signaling due to this mechanism? One  
way to roughly evaluate would be by using simulations.

Adrian: best for us to discuss over email to provide adequate time  
for the discussion.

-------------------------------------------------------------
Path Computation Element (PCE) communication Protocol (PCEP)
draft-vasseur-pce-pcep-01.txt
(JP)
--------------------------------------------------------------

PCC-PCE and between PCEs communication

There were two proposals in the past which were discontinued and a  
completely new protocol has been designed (PCEP) highly driven by the  
PCE WG requirement document. Chief objective was to make it  
extensible to cope with future requirements.

Major changes from 00 to 01:
* rewritten for clarity
* few sections removed
* new section on protocol model
* added security consideration
* very rough manageability consideration section added (to be fleshed  
out)
* two new objects defined

Unique communication protocol for PCC-PCE and PCE-PCE.

Summary – pcep meets most of the requirements.

Open issues (need inputs from the working group)

* Objective functions needs to be defined (next revision)
* Protocol recovery: requires more detailed requirements
* Policy: requires more discussion

Discussion

Bijan Jabbari: What was the reason for TCP?

JP: reliability and flow control. TCP was a very good candidate for  
that.

Bijan: Question of scalability of TCP.

JP (vendor hat): We do not see any scalability issue with TCP.  
Current TCP implementations can support a very high number of TCP  
sessions.

Question (?). You are creating a new protocol. Did you do an analisys  
on existing protocols and reaons for not using them?

Adrian: yes we did , but here formal requirement for the WG to take  
reqs to other groups to ask if have anything, so this draft  
progressing depends on answer.

Lou: Many protocols have been worked on. Instead of reinventing the  
weel, why not use one already existing. What we are doing here in  
path computation is a new application, but session application (keep  
alive, discovery) have been resolved before and it would be great to  
concentrate on what is related to pce.

Adrian: great if we can learn lessons

Lou: and reuse

Adrian: agree

Dimitri: agree as Lou said

Lou: session management, keep alives, etc have been done already

JP: the question is, is there anything specifics to PCE that we need  
a new protocol

Dimitri: With a new solution we will have to pass all the stages the  
others have passed to achieve a robust solution.

JP: That's why we have the question here.

Adrian: yes, this protocol in this draft has not been selected

Bijan: If this is IP only, was DNS discussed?

Adrian: this is IP only

Bijan: have we looked at DNS ?

Adrian: bring it to the list to suggest

Lou: Comment on need to go back and use an existing mechanism  
whenever you can.

JP: yes, whenever you can.

Loa: if we have TCP, then we have a basis, to do more, we need  
justification,
JP: agree

Jerry: can you include what is met and not met on requirements into  
the draft ?

JP: ok, will do.

Jerry: if we do not have a list of requirements, how can we proceed?

Yakov: Comment on the need for protocol specific keep-alive: we need  
a PCE specific keep-alive protocol since TCP will not take care of it.

JP: fully agree.

Lou: You need keep-alive (TCP-based solutions already have keep- 
alives). Find out what's the requirement, then lift the existing  
solution.

Lou: my comment is to look at experience – e.g. if need keepalives,  
it’s a mistake to look at this again without considering previous  
work, and do all the requirements all over again, should look at  
existing protocols, transaction semantics

Adrian: yes, persistency should be addressed in the requirements

Sue: keepalives in a protocol is needed in addition to tcp, need to  
pay careful attention to the state machine interaction between the  
two – pcc-pce. Need to ensure handle failure scenarios, noticed  
missing here some of what protocol has to solve, should feed back  
into requirements

JP: Sometimes you do not want a permanent session, and sometimes you  
do. Do we need two modes?

Adrian: question should be asked to the requirements team.

JL: we should be more flexible and support both request and permanent  
as it will depend on the request, and number of pces to maintain, may  
have a full mesh and may not want to maintain a permanent

JP: this is what we heard – may only need on request, other times  
will need permanent, so may want both modes, and negotiate upon  
session establishment.

Adrian: when doing the solutions and have a question, should take  
back to the requirements folks

JP: Less-constrained path computation aspects will be removed from  
this draft and be worked out in a separate ID.

------------------------------------------------
Path Computation Element Metric Protocol (PCEMP)
draft-choi-pce-metric-protocol-02.txt
(Dipnarayan Guha)
------------------------------------------------

PCE metric protocol (PCEMP): generic routing and path computation  
protocol targeted towards inter-domain pce peers.

Reviewed slides

JP: we encourage you to provide simulation results to the mailing  
list it will help

No discussion

------------------------------
working group next steps (JP)
------------------------------

- new revision of the PCE architecture ID to be published soon (WG  
last call soon after this ietf)
- new revision of the generic pce communication requirement ID (WG  
last call soon after this ietf)
- submit a new ID for pce discovery protocol extensions (minor  
protocol work only)

Start application-specific requirements IDs for PCE based computation

*Inter-area: Jean-Louis
*Inter-As: Raymond, Nabil

JP: note that such ID must be PCE-specific (take into account RFC4105  
and inter-as requirements ID produced by the TE WG).

Adrian: WG to decide on which pce communication protocol solution to  
pursue
- two proposals presented
- selection of one solution as a basis now does not imply rejecting  
good points of other solution nor accepting bad points of selected  
solutions.
If pick one, that does not prevent us from taking the best of other  
one also, and also other ietf protocols. email will be sent to the  
application ADs to ask their input.

- New ID on the less contrained path problem comprising the  
requirement + solution

- Need to verify the solution model for inter-domain pce with CCAMP,  
MPLS working groups

Adrian – other application specific requirements IDs (interlayer,  
p2mp) should continue their work, just realize other work needs to be  
done first:
     inter-layer: Eiji, Kenji
     P2MP: Seisho (currently out of scope of PCE WG charter)

Thanks.

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 13 Aug 2005 15:48:23 +0100

Thanks JP and scribes...

Question (?). You are creating a new protocol. Did you do an analisys  
on existing protocols and reaons for not using them?
---> I believe this was Richard Rabbat

(Oh, and that is "analysis"  and "reasons" :-)

Cheers,
Adrian

---

From: [email-masked]
Date: Sat, 13 Aug 2005 11:27:05 -0400 (EDT)

Hi,

I have a couple of corrections.

1. Architecture document

I made a comment that I disagree with the current definition of the
distributed path computation.

In the document:
centralized path computation = computation performed by a single PCE
distributed path computation = computation performed by multiple PCEs

In my opinion:
centralized path computation = path computation that returns all requested
paths in the *explicit* form in the first response, so that no more
requests will be needed neither from the original requestor nor from any
other PCCs for the service in question

distributed path computation is when the original path computation request
is responded with at least one non-explicit path, so that more path
computations will be issued from the original or some other PCCs.

In other words from the original requestor point of view (which is
ultimate user of the PCE service) it does not matter how many PCEs will be
involved to satisfy its request, what is important is how many additional
path computations is needed (0 -centralised
path computation, >0 - distributed path computation).

2. WRT proposed PCEP solutions I made a comment that neither of them
satisfies the requirement of the extensibility. Introducing new
constraints, objection functions, diversity types, etc will be extreamely
painful. Hence a meta-language style protocol should be considered

Igor

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 14 Aug 2005 10:50:58 +0100

Hi,

Yes, we should record Igor's comments in the minutes as he made them.

However, I would like to tackle them here.

> other PCCs for the service in question

Hmmm. So in this model a single PCE would be responsible for returning the
complete path and no other PCE would be invoked. This is, of course, very
close to the existing definition of "centralized path computation" since
if there is only one PCE there is no option but to compute the entire path
on that PCE.

However, your definition would allow more than one PCE in the network, but
still have only one PCE consulted for any individual path. This mode of
operation is called "single PCE path computation" to contrast with
"multiple PCE path computation" in the draft.

> computations will be issued from the original or some other PCCs.

This, of course, is strikingly similar to the definition of distributed
path computation in the draft. That is, the path is computed by more than
one PCE.

However, your definition states that a path will be computed by multiple
PCE consultation, while the current definition of distributed path
computation states that multiple PCEs are servicing the requests in the
network. Your definition matches the definition of "multiple PCE path
computation" in the draft.

I see absolutely zero value in quibbling about the name given to a concept
when the concepts are identical and are all covered by the existing I-D.

> path computation, >0 - distributed path computation).

We agree that there may be some value in distinguishing the behavior from
the point of view of the requester. There are exactly three cases for the
requester:
1. The requester sends a single request to exactly one PCE and gets
    enough information to make use of the response.
2. The requester must send more than one request to exactly one
   PCE in order to get enough information to make use of the
   responses.
3. The requester must send requests to more than one PCE to
   get enough information to make use of the responses.
In none of these case is the requester, the PCC, aware of whether some
other LSR in the network will subsequently need to consult other PCEs.
Arhcitecturally, it should not be aware of this fact. From a protocol
perspective it must not be aware of this fact.

Adding a description of the behavior from the persepective of the PCC can
be done. However, it will not change the definitions of the terms that
describe the overall architecture. It will introduce new terms to describe
the behavior.

> painful. Hence a meta-language style protocol should be considered

You are correct that we should consider a meta-language style protocol
although unless someone brings a draft to the table we will not consider
one. That is, you cannot mandate that the working group must develop a
particular style of protocol - we can only consider what we have in front
of us in terms of proposals that people are prepared to develop and
implement.

I do not believe that you are correct to state that a TLV-based protocol
is extremely painful to extend. Our experience of very many such protocols
show that they are fairly simple to extend.

It is possible that you could supply a specific example of an extension
that you think is both likely to be required and which you consider would
be hard to encode in a TLV. To do this you would need to supply a detailed
description of the information that you want to encode - it would not be
enough to say "diversity types". Other people could then demonstrate that
such an extension could be encoded. I should point out, however, that a
TLV is capable of encoding a text string - this means that pretty much
anything can be encoded within a TLV.

Whatever, such a proof-by-example style of reasoning is unlikely to get us
very far. If a meta-language style protocol is to be considered, we need
to see it and know that it is being implemented.

Cheers,
Adrian

---

From: dimitri papadimitriou <[email-masked]>
Date: Sun, 14 Aug 2005 13:47:40 +0200

hi jp - some clarifications here below

JP Vasseur wrote:

> 5. PCE communication protocol specification (decision to be made by  the 
> WG soon)
> 
> Mainly editorial revisions resulting from Minneapolis meeting have  been 
> done (Clarifications, but nothing major)
> Plan to add discussion of policy, will separate exchange of policy  info 
> in the PCE communication and the use of policy within the  architecture
> 
> Adrian: the current doc will only have something high level – Lou  will 
> provide draft text
> 
> Lou: we had discussion, as Adrian said, we will have later a  standalone 
> document with more details after we have more discussion  in the WG
> 
> Dimitri: in other WG, are discussing policy for interdomain, need  that 
> for this group

-> "Other WG have shown that the main pre-occupation for RSVP-TE as 
inter-domain signaling protocol is the policy at the domain boundaries 
therefore is it an essential element this WG must address"

> It must be noted that this is optional in the pce discovery  mechanism, 
> not necessarily optional for pce architecture,
> * extensibility section
> * security requirements
> - two stage discovery ? should limit to basic or include more  detailed 
> - all as part of this document
> Dimitri: the question on one or two stage, for me it’s the question  how 
> many pces will we have – if only a small group, then number of  

-> "Dimitri: the question on one or two stage, for me it’s the question 
  how many PCCs will subscribe to the initial PCE advertisement – if 
only a small group of PCCs at each point in time, then a certain number 
of sessions, with more detailed information, can be supported. Hence, 
there is a tradeoff, with a small set, a two stage approach with a 
dedicated for exchanging more detailed information can be used".

> number of pce pccs are factors but also should consider the load on a  pce.

replace PCEs by PCCs

> Igor: Flooding is good, but it has problems: scalability and  security. 
> You still want to know the capabilities of pce so you may  need to 
> establish a session.
> 
> JP: we may now be discussing solutions on how to do basic  capabilities 
> and additional capabilities
> 
> JL: You must be able to control to which pcc you will be disclosing  the 
> information: all pccs in an area, etc.
> 

-> "Dimitri: can you provide more detailed requirements on the dynamics 
needed for these capabilities"

> JP: thanks to quickly resolve the set of open issues. The draft  should 
> then be ready for Working Group LC.
> 
> Adrian: by us splitting the document between generic and extended  reqs 
> (more application specific) we could handle this better
> 
> JP: Sure and the protocol should be designed to handle extensions so  as 
> to meet new requirements but we may need to recharter
> 
> Igor: my view this is not a signaling protocol, not rsvp, we  shouldn’t 
> go thru the process of using a signaling protocol
> 
> whereas this draft re-introduces this overhead for synchronization.  You 
> are redefining the concept of cluster. Why not use the PCE engine?
> One major bottleneck on the PCE architecture is the pcc-pce  signalling. 
> To ensure path computation, reduce the number of path  computation 
> requirements received by a pce.
> 
> the overhead in term of extra signaling due to this mechanism? One  way 
> to roughly evaluate would be by using simulations.
> 
> Adrian: best for us to discuss over email to provide adequate time  for 
> the discussion.
> 
> PCE WG requirement document. Chief objective was to make it  extensible 
> to cope with future requirements.
> 
> * very rough manageability consideration section added (to be fleshed  out)
> JP: reliability and flow control. TCP was a very good candidate for  that.
> 
> JP (vendor hat): We do not see any scalability issue with TCP.  Current 
> TCP implementations can support a very high number of TCP  sessions.
> 
> reqs to other groups to ask if have anything, so this draft  progressing 
> depends on answer.
> 
> weel, why not use one already existing. What we are doing here in  path 
> computation is a new application, but session application (keep  alive, 
> discovery) have been resolved before and it would be great to  
> JP: the question is, is there anything specifics to PCE that we need  a 
> new protocol
> 

-> Add: "Therefore, protocol solutions already developed by other WGs 
should be considered and evaluated wrt requirements provided by this 
working group so as to concentrate on the PCE specifics"

> Lou: Comment on need to go back and use an existing mechanism  whenever 
> you can.
> 
> Jerry: can you include what is met and not met on requirements into  the 
> draft ?
> 
> JP: ok, will do.
> 
> Yakov: Comment on the need for protocol specific keep-alive: we need  a 
> PCE specific keep-alive protocol since TCP will not take care of it.
> 
> JP: fully agree.
> 
> alives). Find out what's the requirement, then lift the existing  solution.
> 
> it’s a mistake to look at this again without considering previous  work, 
> and do all the requirements all over again, should look at  existing 
> protocols, transaction semantics
> 
> Sue: keepalives in a protocol is needed in addition to tcp, need to  pay 
> careful attention to the state machine interaction between the  two – 
> pcc-pce. Need to ensure handle failure scenarios, noticed  missing here 
> some of what protocol has to solve, should feed back  into requirements
> 
> JP: this is what we heard – may only need on request, other times  will 
> need permanent, so may want both modes, and negotiate upon  session 
> establishment.
> 
> Adrian: when doing the solutions and have a question, should take  back 
> to the requirements folks
> 
> JP: Less-constrained path computation aspects will be removed from  this 
> draft and be worked out in a separate ID.
> 
> JP: we encourage you to provide simulation results to the mailing  list 
> it will help
> 
> No discussion
> 
> - new revision of the PCE architecture ID to be published soon (WG  last 
> call soon after this ietf)
> - new revision of the generic pce communication requirement ID (WG  last 
> call soon after this ietf)
> - submit a new ID for pce discovery protocol extensions (minor  protocol 
> work only)
> 
> If pick one, that does not prevent us from taking the best of other  one 
> also, and also other ietf protocols. email will be sent to the  
> - New ID on the less contrained path problem comprising the  requirement 
> + solution
> 
> Adrian – other application specific requirements IDs (interlayer,  p2mp) 
> should continue their work, just realize other work needs to be  done 
> first:
>     inter-layer: Eiji, Kenji
> .

---

From: JP Vasseur <[email-masked]>
Date: Sun, 14 Aug 2005 11:17:08 -0400

Thanks. Minutes will be updated accordingly.

JP.

On Aug 14, 2005, at 7:47 AM, dimitri papadimitriou wrote:

>> 3. Submit first draft of the PCE communication protocol  
>> requirements  (done)
>> 5. PCE communication protocol specification (decision to be made  
>> by  the WG soon)
>> Mainly editorial revisions resulting from Minneapolis meeting  
>> have  been done (Clarifications, but nothing major)
>> Plan to add discussion of policy, will separate exchange of  
>> policy  info in the PCE communication and the use of policy within  
>> the  architecture
>> Dimitri: is this the only document for policy or we will do  
>> something  else ?
>> standalone document with more details after we have more  
>> discussion  in the WG
> inter-domain signaling protocol is the policy at the domain  
> boundaries therefore is it an essential element this WG must address"
>
>
>> Adrian – agree
>> Plans: architecture is believed to be stable but needs  
>> discussions  resulting from emails on the list.
>> --------------------------------------------------------------------- 
>> --- ----------
>> Requirements for PCE Discovery: draft-ietf-pce-discovery- 
>> reqs-01.txt  (Jean-Louis)
>> --------------------------------------------------------------------- 
>> --- ----------
>> comments and discussions on the list have been addressed in the  
>> new  version -01
>> * multi-area example
>> * application scenario
>> Dimitri: the question on one or two stage, for me it’s the  
>> question  how many pces will we have – if only a small group, then  
>> number of  sessions, with more detailed information, can be  
>> supported. Tradeoffs  if small set, and all receive information,  
>> or if a lot of PCEs, may  want only the subset that needs to know.
>>
>
> -> "Dimitri: the question on one or two stage, for me it’s the  
> question  how many PCCs will subscribe to the initial PCE  
> advertisement – if only a small group of PCCs at each point in  
> time, then a certain number of sessions, with more detailed  
> information, can be supported. Hence, there is a tradeoff, with a  
> small set, a two stage approach with a dedicated for exchanging  
> more detailed information can be used".
>
>
>> Arthi: It is premature to talk about solution. Do we have a sense  
>> of  what direction we might be taking? On the section on  
>> scalability:  number of pce pccs are factors but also should  
>> consider the load on a  pce.
>> security. You still want to know the capabilities of pce so you  
>> may  need to establish a session.
>> JL: You must be able to control to which pcc you will be  
>> disclosing  the information: all pccs in an area, etc.
>> Dimitri: can you provide requirements on more the dynamics needed  
>> for  these capabilities
>>
>
> -> "Dimitri: can you provide more detailed requirements on the  
> dynamics needed for these capabilities"
>
>
>> JP: A limited number of capabilities such as the congestion  
>> parameter  is likely to be dynamic
>> Richard: propose discuss possible solutions over email exchange,  
>> even  though it’s not to be included in the requirements, the  
>> discussion  helps to understand
>> * clearly state supported policy models & corresponding  
>> requirements/ implications
>> * avoid feature creep
>> * PCE  protocol proposal needs to identify how generic &  
>> application- specific requirements are met
>> Discussion:
>> JP: on the less-constrained path computation topic, we don’t have  
>> a  consensus yet, we should have a separate document
>> Arthi: Some new requirements may come up for PCE, we need to have  
>> a  plan on how to address that.
>> JP: Sure and the protocol should be designed to handle extensions  
>> so  as to meet new requirements but we may need to recharter
>> Adrian: yes, this draft has requirements on an implementation,  
>> would  like first to see top level requirements and architecture
>> JL: I have a major concern on scalability with the draft’s  
>> approach,  one major bottleneck is on the PCE-PCE signaling, we  
>> should minimize  the signaling, the objective is to have  
>> distribution to reduce this,  whereas this draft re-introduces  
>> this overhead for synchronization.  You are redefining the concept  
>> of cluster. Why not use the PCE engine?
>> JP: I have similar concerns. Have you tried to evaluate what would  
>> be  the overhead in term of extra signaling due to this mechanism?  
>> One  way to roughly evaluate would be by using simulations.
>> Adrian: best for us to discuss over email to provide adequate  
>> time  for the discussion.
>> There were two proposals in the past which were discontinued and  
>> a  completely new protocol has been designed (PCEP) highly driven  
>> by the  PCE WG requirement document. Chief objective was to make  
>> it  extensible to cope with future requirements.
>> Question (?). You are creating a new protocol. Did you do an  
>> analisys  on existing protocols and reaons for not using them?
>> Adrian: yes we did , but here formal requirement for the WG to  
>> take  reqs to other groups to ask if have anything, so this draft   
>> Lou: Many protocols have been worked on. Instead of reinventing  
>> the  weel, why not use one already existing. What we are doing  
>> here in  path computation is a new application, but session  
>> application (keep  alive, discovery) have been resolved before and  
>> it would be great to  concentrate on what is related to pce.
>> JP: the question is, is there anything specifics to PCE that we  
>> need  a new protocol
>> Dimitri: With a new solution we will have to pass all the stages  
>> the  others have passed to achieve a robust solution.
>>
>
> -> Add: "Therefore, protocol solutions already developed by other  
> WGs should be considered and evaluated wrt requirements provided by  
> this working group so as to concentrate on the PCE specifics"
>
>
>> Jerry: can you include what is met and not met on requirements  
>> into  the draft ?
>> JP: ok, will do.
>> Yakov: Comment on the need for protocol specific keep-alive: we  
>> need  a PCE specific keep-alive protocol since TCP will not take  
>> care of it.
>> JP: fully agree.
>> Lou: my comment is to look at experience – e.g. if need  
>> keepalives,  it’s a mistake to look at this again without  
>> considering previous  work, and do all the requirements all over  
>> again, should look at  existing protocols, transaction semantics
>> Sue: keepalives in a protocol is needed in addition to tcp, need  
>> to  pay careful attention to the state machine interaction between  
>> the  two – pcc-pce. Need to ensure handle failure scenarios,  
>> noticed  missing here some of what protocol has to solve, should  
>> feed back  into requirements
>> JP: Sometimes you do not want a permanent session, and sometimes  
>> you  do. Do we need two modes?
>> JL: we should be more flexible and support both request and  
>> permanent  as it will depend on the request, and number of pces to  
>> maintain, may  have a full mesh and may not want to maintain a  
>> permanent
>> JP: Less-constrained path computation aspects will be removed  
>> from  this draft and be worked out in a separate ID.
>> - new revision of the PCE architecture ID to be published soon  
>> (WG  last call soon after this ietf)
>> - new revision of the generic pce communication requirement ID  
>> (WG  last call soon after this ietf)
>> JP: note that such ID must be PCE-specific (take into account  
>> RFC4105  and inter-as requirements ID produced by the TE WG).
>> Adrian: WG to decide on which pce communication protocol solution  
>> to  pursue
>> - selection of one solution as a basis now does not imply  
>> rejecting  good points of other solution nor accepting bad points  
>> of selected  solutions.
>> If pick one, that does not prevent us from taking the best of  
>> other  one also, and also other ietf protocols. email will be sent  
>> to the  application ADs to ask their input.
>> - Need to verify the solution model for inter-domain pce with  
>> CCAMP,  MPLS working groups
>> p2mp) should continue their work, just realize other work needs to  
>> be  done first:
>>     inter-layer: Eiji, Kenji

---

From: dimitri papadimitriou <[email-masked]>
Date: Sun, 14 Aug 2005 22:30:21 +0200

hi adrian -

i don't think there is a need to introduce new terminology to address 
this comment, which is sensible imho, just a need to revisit the notion 
of centralized/distributed vs single/multiple PCE computation

you can ask why ... well the below tries to clarify

by definition (section 3) "distributed computation model" refers to a 
domain or network that may include multiple PCEs, and where computation 
of paths is shared among the PCEs."

since so far there is no specific issue - if one take your viewpoint - 
until reaching the corrolary:

"From these definitions, a centralized computation model inherently
  uses single PCE path computation. However, a distributed
  computation model could use either single PCE path computation or
  multiple PCE path computations. There would be no such thing as a
  centralized model which uses multiple PCEs."

we fall into the situation if the first alternative is used what really 
distinguishes the distributed single PCE computation from a centralized 
computation (so these definitions allow to described a centralized 
computation model to as "distributed") and on the other side, if you 
have an AS with a single PCE and its backup (which is also a specific 
case of sharing) it must be referred to as "distributed" because the 
notion of centralized model implies single PCE per domain ?

therefore, some re-phrasing of the definitions may help here to wipe out 
some confusion

thanks,
- dimitri.

Adrian Farrel wrote:

>>centralized path computation = path computation that returns all
> 
> requested
> 
>>distributed path computation is when the original path computation
> 
> request
> 
>>ultimate user of the PCE service) it does not matter how many PCEs will
> 
> be
> 
>>involved to satisfy its request, what is important is how many
> 
> additional
> 
>>constraints, objection functions, diversity types, etc will be
> 
> extreamely
>

---

From: "Igor Bryskin" <[email-masked]>
Date: Mon, 15 Aug 2005 09:58:59 -0400

Adrian,

Thanks for taking my comments into consideration. See my responses in-line.

Cheers,
Igor

----- Original Message ----- 
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>; "JP Vasseur" <[email-masked]>
Cc: <[email-masked]>
Sent: Sunday, August 14, 2005 5:50 AM
Subject: Re: [Pce] Draft PCE WG Minutes - IETF-63

> complete path and no other PCE would be invoked.

IB>> Nope, a PCE can involve as many other PCEs as it wants. The important
thing
is that it responses with all paths in explicit form, and this would be the
centralized path
computation as far as original PCC is concerned

 This is, of course, very
> "multiple PCE path computation" in the draft.

IB>> My point is/was that whether path computation is centralized or
distributed is orthogonal to how many PCEs are involved.
A domain can contain a single PCE and a path computation could be
distributed: multiple LSRs along the path request path computations
from the same PCE. Likewise, a path computation can be performed by a
cooperation of multiple PCEs, and the computation will still be centralized
as long as the first response to the original PCC contains *all* paths in
the *explicit* form (so that no other path computations will be requested

> path computation in the draft. That is, the path is computed by more than

IB>> No, see my comment above.

>     enough information to make use of the response.

IB>> this is a case of the centralized path computation as long as all paths
are returned in the explicit form

>    PCE in order to get enough information to make use of the

IB>> this is a case of distributed path computation

>    get enough information to make use of the responses.
IB>> this is a case of distributed path computation.

IB>> You also forget one more very important case: a requestor sends a
single request to a PCE and receives at least one path in
non-explicit form. When the path(s) are signaled at least one more requestor
will request a PCE (the same or different one) to perform
more path computation(s) to detailize the non-explicit path(s). This is also
a case of the distributed path computation despite each of the requestors
might issue a single request.

> other LSR in the network will subsequently need to consult other PCEs.

IB>> Disagree. If the responded paths are in the explicit form, no other
LSRs will issue additional path computations.
The explicit paths are conceptually the best possible paths. In fact, as a
PCC I'd like to have an option to mandate the computed paths to be explicit.

> of us in terms of proposals that people are prepared to develop and

IB>> Agree. However, there is one important observation I wanted to make:
originally PCE was an intrinsic part of an LSR's control plane. That is, the
routing, signaling and PCE subsystems where interconnected within the LSR's
control plane via APIs. Hence a PCE used to have an unlimited flexibility to
introduce
new constraints, optimizations and diversity - all that was needed is a
simple recompilation of the control plane software. The PCE architecture has
decoupled
the PCE from the signaling sub-system and made LSR an PCE separate logical
(and possibly physical) entities.
Therefore, whenever somebody comes up with extensions to a PCE, there should
be a way to advertise the
new capabilities and for the PCC to take advantage of them without
introducing new TLVs. TLV-style protocol is for signaling and routing, not
for the client-server protocol such as PCEP. I am afraid the effort to
develop PCEP as a TLV-style protocol might prove to be too rigid to be
useful.
I'd like my point of view to be recorded in the minutes correctly. I'd also
like to hear who would like to join me in designing a meta-style PCEP (for
instance, based on COPS).

Cheers,
Igor