1 / 8

IETF 63, Paris 07/02/2005

lionel-franklin
Download Presentation

IETF 63, Paris 07/02/2005

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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

  2. 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

  3. 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

  4. 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

  5. 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

  6. 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

  7. 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…

  8. 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…

More Related