1 / 6

PCEP Extensions in Support of Transporting Traffic Engineering Data

PCEP Extensions in Support of Transporting Traffic Engineering Data. draft-lee-pce-transporting-te-data-00.txt. Young Lee, Huawei Greg Bernstein, Grotto Networking Haomian Zheng , Huawei Dhruv Dhody, Huawei. Architectural Context.

lucio
Download Presentation

PCEP Extensions in Support of Transporting Traffic Engineering Data

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. PCEP Extensions in Support of Transporting Traffic Engineering Data draft-lee-pce-transporting-te-data-00.txt Young Lee, Huawei Greg Bernstein, Grotto Networking HaomianZheng, Huawei Dhruv Dhody, Huawei 90th IETF, Toronto, July 2014

  2. Architectural Context • [RFC4655] Section 4.3 describes the potential load of the TED on a network node and proposes an architecture where the TED is maintained by the PCE rather than the network nodes. • draft-ietf-pce-questions Section 3 touches upon this issue: “It has also been proposed that the PCE Communication Protocol (PCEP) [RFC5440] could be extended to serve as an information collection protocol to supply information from network devices to a PCE. The logic is that the network devices may already speak PCEP and so the protocol could easily be used to report details about the resources and state in the network, including the LSP state discussed in Sections 14 and 15.” 90th IETF, Toronto, July 2014

  3. Why this draft? • Networks that do not support IGP-TE or BGP-LS but want to implement PCE as a centralized control. • Applications that require accurate and timely TE data that current convergence time associated with flooding is not justified. • Reduction of node OH processing of flooding mechanisms (esp. optical transport networks where there are large amounts of traffic data and constraints due to OTN/WSON/Flexi-grid, etc.) • Note that BGP-LS is not widely supported in optical transport networks today). 90th IETF, Toronto, July 2014

  4. Options for nodes to share local TED info with PCEs • Nodes send local info directly to all PCEs, • Nodes send local info to a intermediary (publish/subscribe), • Nodes send info to at least one PCE and have the PCEs share TED information. 90th IETF, Toronto, July 2014

  5. Potential Areas for Standardization • Information packaging for use in TED creation, maintenance and exchange (most likely similar to IGP based approach) • Incremental Update of more time sensitive data (Per Igor) • Basic PCE TED creation and maintenance procedures when not IGP driven • NE to PCE communication of TED information --- interface and protocol • Evaluate if we need IM/DM for this (per Ramon) • NEs discovering PCE for TED creation and maintenance purposes • PCE to PCE TED synchronization and update 90th IETF, Toronto, July 2014

  6. Summary & Next Steps • A reasonable level of interest expressed in this work in the mailing list. • What do you think? 90th IETF, Toronto, July 2014

More Related