80 likes | 95 Views
Explore the essential aspects of PCE discovery in networks, including security, capacity, and congestion status. Addressing concerns raised and proposing potential solutions for effective network operations.
E N D
Requirements for PCE Discoverydraft-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
Background • draft-leroux-pce-discovery-reqs-00 presented in Minneapolis • Some concerns expressed regarding capability discovery • addressed in v01 • 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
Changes since Minneapolis 1/2 • A new co-author • Added Multi-Area example in the problem statement • Added an application scenario • Reorganized text on the PCE information to be disclosed • Mandatory information • Optional information
Changes since Minneapolis 2/2 • Added extensibility section • Added security requirements • Removed PCE selection section => Out of the scope of PCE discovery • A section requiring WG feedback on discovery of PCE power and congestion status • Text added/removed, for the sake of clarity
PCE Information 1/2 • Two levels of information to be disclosed: • Mandatory information • Optional information • 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
PCE Information 2/2 • 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 • 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 • 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) • Dynamic discovery of PCE capabilities MUST NOT generate an excessive amount of information and SHOULD be limited to a small set of generic capabilities
Open issues • 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… • Security trust model (as per Eric suggestion) • We need to detail the security requirements and define one or more trust models… • Feedback required on discovery of PCE power and congestion status (section 6.5) • This could be part of the detailed discovery stage…
Next Steps • We need to address open issues • New version to be posted by the end of September • Should be ready for WG LC • It is time to start working on solutions…