1. Requirements for PCE Discovery draft-ietf-pce-discovery-reqs-01.txt Jean-Louis Le Roux (France Telecom) Paul Mabey (Qwest) Eiji Oki (NTT) Richard Rabbat (Fujitsu) Ting Wo Chung (Bell Canada) Raymond Zhang (BT Infonet) IETF 63, Paris 07/02/2005

2. Background l draft-leroux-pce-discovery-reqs-00 presented in Minneapolis l Some concerns expressed regarding capability discovery è addressed in v01 l Comments received during WG doc adoption vote (Eric, Igor, Dimitri…) è Some of them are addressed in WG v01: Security requirements, è More discussion required on two-stage discovery and trust models è Open issues regarding discovery of PCE capacity and PCE congestion status

3. Changes since Minneapolis1/2 l A new co-author l Added Multi-Area example in the problem statement l Added an application scenario l Reorganized text on the PCE information to be disclosed è Mandatory information è Optional information

4. Changes since Minneapolis2/2 l Added extensibility section l Added security requirements l Removed PCE selection section => Out of the scope of PCE discovery l A section requiring WG feedback on discovery of PCE power and congestion status l Text added/removed, for the sake of clarity

5. PCE Information1/2 l Two levels of information to be disclosed: è Mandatory information è Optional information l Mandatory Information : Support = MUST è PCE location : IPv4 or V6 loopback è Path Computation Scope (intra/inter area/AS…) è Set of domain(s) under responsibility of a PCE (list of domain IDs) è Set of domain(s) toward which a PCE can compute paths

6. PCE Information2/2 l Optional Information : Support = MAY è PCE capabilities –Path computation related (e.g. supported objective functions, supported constraints) –General capabilities (support for request prioritization, encryption…) è Alternate PCE for recovery purpose l It means optional in the context of the PCE discovery itself è This does not mean optional in the context of the PCE architecture è It could also be obtained by the PCC-PCE communication protocol l Description of PCE capabilities is out of the scope of this ID è Should be described in a separate ID (as it applies both to PCE discovery and PCC-PCE communication) l Dynamic discovery of PCE capabilities MUST NOT generate an excessive amount of information and SHOULD be limited to a small set of generic capabilities

7. Open issues l Two-stage discovery (as per Igor suggestion)?? è Shall we consider capabilities discovery as entirely part of the PCE discovery (support = MUST) and define a two-stage discovery approach? –General discovery stage: PCE location, scopes, domains… –Detailed discovery stage: PCE capabilities… è The two stages could be ensured by same or distinct mechanisms… l Security trust model (as per Eric suggestion) è We need to detail the security requirements and define one or more trust models… l Feedback required on discovery of PCE power and congestion status (section 6.5) è This could be part of the detailed discovery stage…

8. Next Steps l We need to address open issues l New version to be posted by the end of September l Should be ready for WG LC l It is time to start working on solutions…