Subject: [Pce] Fwd: PCE BOF minutes - IETF-60 - San Diego

From: Jean Philippe Vasseur <[email-masked]>
Date: Thu, 02 Sep 2004 18:51:28 -0400

Hi,

Please forward any correction/addition you may want to make on the minutes.

JP.

>Date: Thu, 02 Sep 2004 10:30:40 -0400
>To: [email-masked]
>From: Jean Philippe Vasseur <[email-masked]>
>Subject: PCE BOF minutes - IETF-60 - San Diego
>Cc: [email-masked], [email-masked], bill Fenner <[email-masked]>
>
>Minutes of the Path Computation Element BOF (pce)  IETF-60  San Diego
>#############################################################
>
>Chairs: JP Vasseur, Adrian Farrel
>ADs: Alex Zinin, Bill Fenner
>
>*thanks to Dave Ward and Don Fedyk for their help taking notes*
>
>1) Agenda bashing, Admin and objectives - Adrian
>**********************************************************
>
>2) Overview of PCE-based path computation - JP
>*********************************************************
>What is the BoF about ? What do we mean by PCE ?
>PCE is an entity capable of compositing a path. Mainly we mean MPLS TE for 
>now but could expand to other (IP paths).
>If you are computing a path for a loose hop you are a PCE. PCE examples: 
>Router, LSR, Server.
>PCE is just an entity capable of doing some computation
>Does not require centralized path computation. PCE can do distributed 
>computation.
>One View: Each router is a PCE for it neighbors.
>Could have a PCE where global optimization is required
>Could be completely stateless or stateful
>PCE approach is not necessarily the only approach but one approach
>PCE suits a number of problem spaces.
>Highlighting that PCE can be centralized or distributed model and need both
>
>3) Requirements for PCE-based path computation (30 minutes) Raymond 
>(Infonet), Kenji (KDDI), Jean-Louis (France Telecom), Seisho (NTT), Jerry 
>(ATT), Javier (Telefonica), Venkata (MCI)
>
>Raymond Zhang, Infonet
>Case customer wants a guaranteed path that is delay sensitive. Problem is 
>there is high interconnect multi domain. Want to select paths with a high 
>degree of control.
>
>Kenji Kumaki, KDDI
>Multi AS inter SP, Shortest end to end, Re-optimization, Multi IGP areas, 
>Re-optimization. These are difficult problems to solve. Scalability issues 
>with Routing and Signaling.
>
>Jean Louis Le Roux, France Telecom
>Head end is sufficient for most., Complex routing conditions for P2 MP. 
>Multi constraint Backup Path.  Inter domain path computation. Diverse path 
>computation. Could benefit from path computation element. Dedicated tool, 
>Centralized, Collaborative Useful for backup.
>
>High level requirements: Reliable signaling protocol, Automatic discovery, 
>Scalability, Balance the computational load, Distribute PCE function, High 
>Availability, Robustness.
>
>Question Dimitri Papadimitriou: is list detailing the PCE to PCE signaling?
>JP: Yes
>Dimitri: So 1st bullet is client to server signaling relationship?
>JP: Yes good point load share requests but also need case where paths are 
>dependent on one another.
>
>Jerry Ash, AT&T
>Requirements:  Migrating to converged Network.
>IP MPLS and all TDM to VoIP. These are the architecture plans, not 
>committed and being implemented. PCE is part of the plan. Inter area, very 
>large network need a solution that scales. Intra and inter AS.  Need 
>shortest path across Network
>Need standards based solution
>
>Seisho  Yakukawa, NTT
>Requirements: P2MP, IP-TV, Video, CPU intensive, P2MP, Inter-domain, Need 
>wider community, PCE approach is good.
>
>Arthi:  PCE to PCE or LSR to PCE based on same protocols?
>Adrian: Yet to be decided. Good Point.
>Arthi :When we talk about signaling, is it query-reply or  MPLS TE signaling?
>JP: query-reply, no change to TE LSP signalling
>Igor: Two types of signaling: are they the same ?
>Adrian: This is what we are deciding. Please wait for this.
>Dimitri: The issue I see is there need for synchronization. There is a 
>need for coordination.
>Adrian: Yes that is what we are discussing
>?? You are going to have a discussion part a the end
>JP:Yes.
>Bijan Jabbari : Are you asking in the context of MPLS?
>JP: Yes.
>Bijan:  This is related to some specific application.
>JP:Yes
>
>Venkata Josyula, MCI
>Requirements: Multiple AS, Hierarchical AS and be able to build AS, Inter 
>area PCE..
>Inter AS: Need a simple solution. Not saying you can use BGP next hops.
>Do need TE Policy. Like the flexibility to coexist with other approaches.
>JP: Interesting question. PCE could be used for inter areas and BGP for 
>inter AS (AS path selection). This is an Interesting point.
>
>4) Functional requirements of a PCE-based path computation system  - JP
>***************************************************************************************
>Functional requirements:
>Multiple Models Picture:
>Centralized,
>Cooperative model PCE for one [or more] parts of the path.
>Distributed : Each node is a fully distributed PCE (example: Backup Tunnel 
>path comp).
>
>Discovery of the PCE in a network:
>Static Provisioning
>Dynamic discovery computing resource (load sharing between multiple PCEs)
>
>PCE may have routing adjacency with other nodes or may use some [other] 
>protocols)
>
>LSR-PCE Signaling: Interaction between the router and the PCE: RSVP, or 
>new protocol. Need to specify request and reply.
>
>Arthi: On slide are PCE red circles. Are these the only PCEs?
>JP: No of course not.
> From this figure each LSR is a PCE or does it talk to other PCEs?
>Adrian: If you have an Abstract node or a loose path you are using a PCE.
>Arthi: This picture is not necessary the only view. It is not mandatory.
>JP: It can be a server or a router itself.
>Bijan: It can be [LSR]{missed it} or higher level than that?
>??  It would be useful to have distinction between PCEs. Implement a LSR 
>as a distributed machinery with PCE and share the network with the data 
>network.
>JP: We can discuss this.
>?? Many, many approaches. Distributed path computation. Information is not 
>synchronized.  If you do it on several path computation elements.
>Adrian: Yes that is a problem. Clearly diverse path.  Clearly not produce 
>loops.
>?? Signaling protocol soft state?. RSVP-TE sounds like a funny approach. 
>Will there be others?
>Adrian: Yes 5 proposals already ...
>Alex. Clarification on slides please.
>Ina: Do you have model ? Does the PCE have to run routing or not? Type of 
>discovery mechanism are a direct result of the model.
>JP :Yes it is dependent.
>Ping Pan: Inter domain. Great one [requirement]. What is the best 
>algorithm? That is independent. How you communicate. COPS, RADIUS 
>DIAMETER. Cisco scripts overnight.
>JP: Not sure what you are trying to clarify.
>Ping: You are limited to data path signaling.
>Alex: Is it local to the box or cooperative [across boxes]?
>JP: Inter domain must be standardized to some extent to compute an 
>inter-domain shortest path and avoid loops. Intra not necessary.
>Ping: Preventing loop is one thing.
>Alex: Cut line hold to discussion.
>
>JP: Policy, Security, Confidentiality.
>
>Adrian: Not here to discuss drafts good bad or WG drafts. Just want to 
>expose the drafts. If you have questions please go to authors not to 
>microphone.
>
>????: Does the LSR have to be the PCE?
>JP: No, it can be another box.
>????: Can PCEs be out of band?
>JP: At end of meeting
>????: Can we use this to find diverse paths? Can we use this for 
>cooperative model? Are there loops formed?
>JP: Yes for diverse paths, no to loops, yes to cooperative
>Sue Hares: Does the PCE have to participate in routing?
>JP - It can
>
>5) Current status of drafts (20 minutes) - Several
>********************************************************
>Background and framework drafts 4
>Requirements draft 1
>PCE Discovery (see IDs in CCAMP, ISIS and OSPF WGs)
>PCE signaling 3 drafts
>Modified TE Flooding
>Applications 2 drafts
>
>Quick walk through the drafts -  Minor clarifications and comments
>
>JP: No time to discuss the draft in detail  by the way, not the objective 
>of this BOF.
>
>draft-leroux-pce-backup-comp-frwk-00.txt  Jean-Louis
>Nurit Sprecher: What is what the assumption for failure? A single failure?
>JL: Yes this is reasonable. All networks are done this way.
>Nurit: For multiple failures?
>JL: This is to present one model for example.
>
>draft-oki-pce-gmpls-req-00.txt, Eiji Oki
>Two kinds of requirements
>PCE requirement: GMPLS and MPLS
>Functionally separated from MPLS NODE
>Provider can choose appropriate implementation.
>Centralized and distributed.
>Multi region TE in GMPLS
>Interworking between MPLS and GMPLS.
>
>Hierarchical LSP setup.
>Trigger by higher level LSP setup. PCE helps GMPLS node to setup 
>hierarchical LSP.
>PCE Triggered LSP should be supported. Treat as single region network from 
>higher level. Standard Opaque TE information. Nodal requirement
>PCE two request modes: Mandatory mode, Normal request node can ask own 
>node or PCE.
>
>Solution drafts
>******************
>
>draft-oki-ccamp-gtep-00.txt, Eiji Oki
>Generalized TE protocol GTEP.
>Features:
>Support trigger hierarchical LSP setup
>Support TEDB synchronization
>Reliable transfer of larger data based on TCP
>GTEP running code
>
>draft-vasseur-mpls-computation-rsvp-05.txt, Alia Atlas:
>Extensions to RSVP-TE
>Extend RSVP-TE a bit between the head end and the PCE.
>Most of the stuff is there.
>Request and reply message.
>Some additional objects.
>Drafts consider a number of different scenarios.
>
>draft-choi-pce-e2e-centralized-restoration-srlg-00.txt, Jun Kyun
>Centralized control from optical network and GMPLS 50 Ms constraint.
>Logical Ring configuration  based on SRLG and PCE
>Compatible with ASON architecture SG-15
>Simplifies and reduces management.
>
>Bijan Jabbari: 50 msec requirement is driving control not feasible.
>Jun: Where is the location of the central controller. The requirement is 
>there.
>
>IDs related to P2MP
>LSR PCE signaling required could be part of a general PCE
>
>IDs under construction - JP
>  Requirements for signaling necessary
>  Quick overview of inter-domain QoS ID, Mohamed Boucadair
>6) Discussion points, WG formation, possible goals and milestones? Adrian, JP
>*********************************************************************************************
>JP: We need to discuss where can we do the work, what the scope is: MPLS 
>or IP as well?
>
>Adrian: Multiple components: Do we need a protocol at all ? Resolving how?
>Alex: Do we have a good understanding ?
>
>Bijan Jabbari: Note that there are requirements from research networks as 
>well as SPs for Path Computation and routing
>
>Alex: PCE computations?
>Bijan: Yes.
>????: LSR or something like that?
>Bijan: In optical network very complex. Loops are a problem and problems 
>are usually N-P complete. Complex. Requires a PCE.
>
>JP: Let's discuss whether we need new protocols?
>
>Zafar Ali: There is evidence for PCE needs/desires. Yes we should be 
>working on this in the IETF.
>
>Mark Hanley: Is spectrum too big? New routing architecture is evident and 
>watch how far you want to go.
>
>Alex: Lots of requirements however, from an architecture point of view 
>there is confusion. Are we separating out some non-forwarding pieces.
>
>Someone from Korea: Is scope limited to MPLS TE?
>
>JP: It includes GMPLS
>
>Arthi: Clear that SPs require this. Server SPs already have some 
>mechanisms. People may already have some form of this functionality.  How 
>are people are going to cooperate? Who will change? How much will existing 
>mechanism affect what we do?
>
>Adrian: You are saying even if this a good idea we are too late? We may be 
>too late - Service provider can say. If we come up with a different 
>protocol will this have impact? Do you have strong opinion?
>
>Arthi: Yes should be done, but where? Don't know. Cannot standardize 
>computation algorithms. Don't think so. Differentiates on PCE from [vendor 
>to vendor]
>
>Mohamed Boucadair, France Telecom: the PCE control plane and forwarding 
>plane. If you have one element for this PCE it and element that manages 
>your inter domain resources. Inter-provider not arguing for this. What we 
>need the protocol in two different domains.
>
>Dimitri: Does it cover co-located PCE. Should the PCE talk to elements of 
>different vendors? What are changes expected to communicate LSR<->PCE? How 
>far do we change RSVP? Please add requirements doc. Must have 
>interoperability cleared up - don't get this. What about scalability 
>problems of PCE once all TEDB are combined.
>
>Zafar: Offline tools already present but, SP doesn't like them or not.
>
>Dima: We know there is a need. IETF should take it on. There should be a 
>new WG. There needs to be clarity on PCE being w/in the LSR or if the PCE 
>should be a router to participate.
>
>Francois LeFechaur: Clear requirements. We should do it.
>
>Bora A: How you communicate to the router. Only Standardized. Co-located 
>PCE on the router no different than what you do today. Comp SNMP TCL 
>scripts and we need another algorithm. I think RSVP-TE approach may be the 
>way to go.
>
>Igor: I agree [with Bora]. Protocol only. Formidable task. Standardizing 
>constraints is tough. I do believe we need to review the architecture. 
>SNMP like protocol is a better choice.
>
>Bjian: Need some form of centralization?
>Adrian: Support centralization but not mandated
>JP Yes. First slide.
>Bijan: Distributed as well? Need multiple computation algorithms in the 
>PCE. However that does not need to be standard.
>Alex: We have some experience documenting algorithms. Kireeti did document 
>an algorithm but this went [no where]. This could be done as Informational
>
>Bijan - Is there centralization or not? There has to be both distributed 
>and centralized.
>
>Ina: Several people requirements and tools. Clear sign yes. Need for new 
>working group. Should PCE be part of an LSR or and independent element?
>
>Bora: Only thing that can be standardize is the communication, not 
>algorithms. Ok creating another WG but, there isn't a lot of work here.
>
>Igor: Only can standardize the communication between LSR and PCE. We need 
>the work, the WG and the architecture. Perhaps we should have a 
>configuration server like ATM.
>
>Richard Rabbat: Clearly requirements, take this on. Scope don't 
>standardize algorithm. Where. Stay in CCAMP.
>
>JP: Note that in some cases such as collaborative path computation, you 
>need to standardize algorithm to guarantee optimality (shortest path) and 
>prevent looping problems.
>
>Alia: We need signalling, we need architecture, we need resolve this, it 
>should not be CCAMP as that WG is swamped
>
>Hani: We should take on [new] WG
>
>Bruce Davie: Let's not standardize the algorithms but make sure we specify 
>it enough to make sure we don't have loops. Kireeti says that we should 
>use BGP. It should be a WG and w/in the IETF.
>
>Dimitri: The distributed model is difficult. Access of LSR to PCE. Next 
>hop path resolution protocol. Important aspect should determine what are 
>the based computation assumptions. Don't want one PCE then another PCE etc.
>
>Ping Pan: What is a domain?
>Adrian: Have some input areas computation domain and protection 
>domains.  Broad computation visibility.
>
>Summary
>************
>Alex takes the mic:
>Clearly there is a need
>Clearly there is support for a solution
>Confusion on what needs to be specified: communication, etc
>Many requirements but quite diverse. Requirements good but so large.
>What need to be standardized ? How this will affect the existing work ?
>Tread very carefully and do architectural work so not to screw the internet
>Heard strong opinion that we shouldn't standardize algorithms
>
>Steps
>********
>Create mailing list - everyone will join
>Need framework/arch doc(s)
>Need to reduce requirements and present what will be covered
>If we have something more complete by the next meting we will need another 
>BOF.
_______________________________________________
Pce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pce

---

From: dimitri papadimitriou <[email-masked]>
Date: Sat, 04 Sep 2004 10:38:16 +0200

jp - see in-line:

Jean Philippe Vasseur wrote:
>> PCE is an entity capable of compositing a path. Mainly we mean MPLS TE 
>> for now but could expand to other (IP paths).
>> If you are computing a path for a loose hop you are a PCE. PCE 
>> examples: Router, LSR, Server.
>> 3) Requirements for PCE-based path computation (_30 minutes_) Raymond 
>> (Infonet), Kenji (KDDI), Jean-Louis (France Telecom), Seisho (NTT), 
>> Jerry (ATT), Javier (Telefonica), Venkata (MCI)
>>
>> Raymond Zhang, Infonet
>> Case customer wants a guaranteed path that is delay sensitive. Problem 
>> is there is high interconnect multi domain. Want to select paths with 
>> a high degree of control.
>>
>> Kenji Kumaki, KDDI
>> Multi AS inter SP, Shortest end to end, Re-optimization, Multi IGP 
>> areas, Re-optimization. These are difficult problems to solve. 
>> Scalability issues with Routing and Signaling.
>>
>> Head end is sufficient for most., Complex routing conditions for P2 
>> MP. Multi constraint Backup Path.  Inter domain path computation. 
>> Diverse path computation. Could benefit from path computation element. 
>> Dedicated tool, Centralized, Collaborative Useful for backup.
>>
>> High level requirements: Reliable signaling protocol, Automatic 
>> discovery, Scalability, Balance the computational load, Distribute PCE 
>> function, High Availability, Robustness.
>>
>> JP: Yes good point load share requests but also need case where paths 
>> are dependent on one another.
>>
>> Jerry Ash, AT&T
>> committed and being implemented. PCE is part of the plan. Inter area, 
>> very large network need a solution that scales. Intra and inter AS.  
>> Need shortest path across Network
>> Requirements: P2MP, IP-TV, Video, CPU intensive, P2MP, Inter-domain, 
>> Need wider community, PCE approach is good.
>>
>> Requirements: Multiple AS, Hierarchical AS and be able to build AS, 
>> Inter area PCE..
>> JP: Interesting question. PCE could be used for inter areas and BGP 
>> for inter AS (AS path selection). This is an Interesting point.
>>
>>     Distributed : Each node is a fully distributed PCE (example:
>>     Backup Tunnel path comp). 
>>
>>
>> PCE may have routing adjacency with other nodes or may use some 
>> [other] protocols)
>>
>> LSR-PCE Signaling: Interaction between the router and the PCE: RSVP, 
>> or new protocol. Need to specify request and reply. 
>>
>> ??  It would be useful to have distinction between PCEs. Implement a 
>> LSR as a distributed machinery with PCE and share the network with the 
>> data network.
>> JP: We can discuss this.
>> ?? Many, many approaches. Distributed path computation. Information is 
>> not synchronized.  If you do it on several path computation elements.
>> Adrian: Yes that is a problem. Clearly diverse path.  Clearly not 
>> produce loops.
>> ?? Signaling protocol soft state?. RSVP-TE sounds like a funny 
>> approach. Will there be others?
>> Ina: Do you have model ? Does the PCE have to run routing or not? Type 
>> of discovery mechanism are a direct result of the model.
>> JP :Yes it is dependent.
>> 5) Current status of drafts (_20 minutes_) - Several
>> JP: No time to discuss the draft in detail  by the way, not the 
>> objective of this BOF.
>>
>> PCE Triggered LSP should be supported. Treat as single region network 
>> from higher level. Standard Opaque TE information. Nodal requirement
>> Jun: Where is the location of the central controller. The requirement 
>> is there.
>>
>> IDs related to P2MP
>> JP: We need to discuss where can we do the work, what the scope is: 
>> MPLS or IP as well?
>>
>> Bijan Jabbari: Note that there are requirements from research networks 
>> as well as SPs for Path Computation and routing
>>
>> Alex: PCE computations?
>> Bijan: Yes.
>> Bijan: In optical network very complex. Loops are a problem and 
>> problems are usually N-P complete. Complex. Requires a PCE.
>>
>> JP: Let’s discuss whether we need new protocols?
>>
>> Mark Hanley: Is spectrum too big? New routing architecture is evident 
>> and watch how far you want to go.
>>
>> mechanisms. People may already have some form of this functionality.  
>> How are people are going to cooperate? Who will change? How much will 
>> existing mechanism affect what we do?
>>
>> Adrian: You are saying even if this a good idea we are too late? We 
>> may be too late - Service provider can say. If we come up with a 
>> different protocol will this have impact? Do you have strong opinion?
>>
>> computation algorithms. Don't think so. Differentiates on PCE from 
>> [vendor to vendor]
>>
>> Mohamed Boucadair, France Telecom: the PCE control plane and 
>> forwarding plane. If you have one element for this PCE it and element 
>> that manages your inter domain resources. Inter-provider not arguing 
>> for this. What we need the protocol in two different domains.
>>
>> Dimitri: Does it cover co-located PCE. Should the PCE talk to elements 
>> of different vendors? What are changes expected to communicate 
>> LSR<->PCE? How far do we change RSVP? Please add requirements doc. 
>> Must have interoperability cleared up - don't get this. What about 
>> scalability problems of PCE once all TEDB are combined.

to complete the last item the question is also related to "PCE-PCE"
communication: does it require any information exchange a-priori or
would it only imply exchanges upon incoming request from LSR ?

>> Dima: We know there is a need. IETF should take it on. There should be 
>> a new WG. There needs to be clarity on PCE being w/in the LSR or if 
>> the PCE should be a router to participate.
>>
>> Bora A: How you communicate to the router. Only Standardized. 
>> Co-located PCE on the router no different than what you do today. Comp 
>> SNMP TCL scripts and we need another algorithm. I think RSVP-TE 
>> approach may be the way to go.
>>
>> Igor: I agree [with Bora]. Protocol only. Formidable task. 
>> Standardizing constraints is tough. I do believe we need to review the 
>> architecture. SNMP like protocol is a better choice.
>>
>> Bijan: Distributed as well? Need multiple computation algorithms in 
>> the PCE. However that does not need to be standard.
>> Alex: We have some experience documenting algorithms. Kireeti did 
>> document an algorithm but this went [no where]. This could be done as 
>> Informational
>>
>> Bijan - Is there centralization or not? There has to be both 
>> distributed and centralized.
>>
>> Ina: Several people requirements and tools. Clear sign yes. Need for 
>> new working group. Should PCE be part of an LSR or and independent 
>> element?
>>
>> Igor: Only can standardize the communication between LSR and PCE. We 
>> need the work, the WG and the architecture. Perhaps we should have a 
>> JP: Note that in some cases such as collaborative path computation, 
>> you need to standardize algorithm to guarantee optimality (shortest 
>> path) and prevent looping problems.
>>
>> Alia: We need signalling, we need architecture, we need resolve this, 
>> it should not be CCAMP as that WG is swamped
>>
>> Bruce Davie: Let's not standardize the algorithms but make sure we 
>> specify it enough to make sure we don't have loops. Kireeti says that 
>> we should use BGP. It should be a WG and w/in the IETF.
>>
>> Dimitri: The distributed model is difficult. Access of LSR to PCE. 
>> Next hop path resolution protocol. Important aspect should determine 
>> what are the based computation assumptions. Don't want one PCE then 
>> another PCE etc. 

please complete with:

"concerning the "distributed PCE model" difficult to assess whether 
referring to:
- distributed access to a single PCE (multiple entry points)
- when accessed PCE requires exchanges with other PCEs to deliver the
   final result (computation for instance performed in sequence before
   delivering the final result) -> "kind of" next hop path resolution
   protocol
- computation itself can be distributed among several PCE (parallel)"
   so an important aspect should also determine what are the base
   computation assumptions ?."

>> If we have something more complete by the next meting we will need 
>> another BOF.
> 
> 
> ------------------------------------------------------------------------
>

---

From: Jean Philippe Vasseur <[email-masked]>
Date: Sat, 04 Sep 2004 14:11:30 -0400

Hi Dimitri,

At 10:38 AM 9/4/2004 +0200, dimitri papadimitriou wrote:
>>>is there is high interconnect multi domain. Want to select paths with a 
>>>high degree of control.
>>>
>>>Kenji Kumaki, KDDI
>>>Multi constraint Backup Path.  Inter domain path computation. Diverse 
>>>path computation. Could benefit from path computation element. Dedicated 
>>>tool, Centralized, Collaborative Useful for backup.
>>>
>>>Arthi: On slide are PCE red circles. Are these the only PCEs? JP: No of 
>>>course not.
>>>      Requirements for signaling necessary      Quick overview of 
>>> inter-domain QoS ID, Mohamed Boucadair
>>>Adrian: You are saying even if this a good idea we are too late? We may 
>>>be too late - Service provider can say. If we come up with a different 
>>>your inter domain resources. Inter-provider not arguing for this. What 
>>>we need the protocol in two different domains.
>>>
>>>LSR<->PCE? How far do we change RSVP? Please add requirements doc. Must 
>>>have interoperability cleared up - don't get this. What about 

comment will be added to the minutes.

>>>new WG. There needs to be clarity on PCE being w/in the LSR or if the 
>>>PCE should be a router to participate.
>>>
>>>scripts and we need another algorithm. I think RSVP-TE approach may be 
>>>the way to go.
>>>
>>>need to standardize algorithm to guarantee optimality (shortest path) 
>>>and prevent looping problems.
>>>
>>>specify it enough to make sure we don't have loops. Kireeti says that we 
>>>should use BGP. It should be a WG and w/in the IETF.
>>>

will also be added to the minutes.

As you will see, the architecture ID should clearly address that point.

As suggested by Alex, next step is to come up with a PCE architecture ID 
for which I would warmly encourage the members of this list to provide 
comments. A first cut of the ID is on its way and should be sent to the 
list in 2-3 weeks.

JP.