1 / 5

draft-ccamp-lsp-diversity-01.txt

CCAMP - IETF 86 – Orlando March 2013. draft-ccamp-lsp-diversity-01.txt. Zafar Ali Clarence Filsfils Ori Gerstel Matt Hartley Kenji Kumaki Rüdiger Kunze Julien Meuric George Swallow. Cisco Systems Cisco Systems Cisco Systems Cisco Systems KDDI Corporation Deutsche Telekom AG

brit
Télécharger la présentation

draft-ccamp-lsp-diversity-01.txt

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. CCAMP- IETF 86 – Orlando March 2013 draft-ccamp-lsp-diversity-01.txt Zafar Ali Clarence Filsfils OriGerstel Matt Hartley Kenji Kumaki RüdigerKunze JulienMeuric George Swallow Cisco Systems Cisco Systems Cisco Systems Cisco Systems KDDI Corporation Deutsche Telekom AG France Telecom Orange Cisco Systems

  2. Overall Problem Space • Between areas, ASes, across UNIs and NNIs, visibility of TE Database information is limited • The aim is to allow path diversity across such boundaries, while respecting that not information can or will be shared • This draft pertains especially to boundaries where policy limits information flow • E.g. at a UNI where the operator limits visibility into the network NNI TE Tail UNI-C TE Head UNI-N NNI ASBR ASBR UNI-N UNI-C ASBR ASBR UNI-N UNI-C

  3. Route Diversity using Exclude Routes • Accepted as a WG document • V-01 is a fairly major rewrite, not to change functionality, but to enhance readability • Changed the name of the subobjectfrom LSP to PATH • Subobject may represent • The path of a particular LSP or • The path of a tunnel • Consistently call the ends source and destination (eliminated use of ingress / egress)

  4. Clarified changes to the Path excluded • If loose “L” bit is not set, processing node MUST send a Error* message notifying the source; the Path_State_Removed Flag is NOT set • If loose “L” bit is set, processing node SHOULD send a Error* message notifying the source; the Path_State_Removed Flag is NOT set • * If the processing node is able to find a path that meets all the original constraints, then the error is “Better Path Exists”, otherwise it sends “Route Blockedby Exclude Route” or “Failed to Respect Exclude Route”

  5. Next Steps • Consider draft nearly ready for last call • (Chairs) How many have read v-01? • Solicit comments on list • Address any comments; final edit pass • Ask for last call before Berlin

More Related