ietf 63 paris 07 02 2005 n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
IETF 63, Paris 07/02/2005 PowerPoint Presentation
Download Presentation
IETF 63, Paris 07/02/2005

Loading in 2 Seconds...

play fullscreen
1 / 8

IETF 63, Paris 07/02/2005 - PowerPoint PPT Presentation


  • 62 Views
  • Uploaded on

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'IETF 63, Paris 07/02/2005' - lionel-franklin


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
ietf 63 paris 07 02 2005

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