1 / 10

RSVP-TE Path Diversity using Exclude Routes draft-ietf-ccamp-lsp-diversity- 03.txt

RSVP-TE Path Diversity using Exclude Routes draft-ietf-ccamp-lsp-diversity- 03.txt. Zafar Ali Cisco Systems George Swallow Cisco Systems Clarence Filsfils Cisco Systems Ori Gerstel SDN Solutions Ltd. Matt Hartley Cisco Systems Kenji Kumaki KDDI Corporation

jolene
Télécharger la présentation

RSVP-TE Path Diversity using Exclude Routes draft-ietf-ccamp-lsp-diversity- 03.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. RSVP-TE Path Diversity using Exclude Routesdraft-ietf-ccamp-lsp-diversity-03.txt ZafarAli Cisco Systems George Swallow Cisco Systems Clarence Filsfils Cisco Systems OriGerstelSDN Solutions Ltd. Matt Hartley Cisco Systems Kenji Kumaki KDDI Corporation RüdigerKunze Deutsche Telekom AG JulienMeuric France Telecom Orange 88th IETF, informal meeting on diversity drafts, London, UK (March 2014)

  2. Motivation • Find a simple means in which a client can express diversity needs as a service request to the server network • Request needs to be stable and persistent • Status of whether the request is fulfilled (or not) needs to be communicated to server

  3. Primary Use Case • IP or OTN as a client of Optical • All networks under a single administration • Server network may be multiple domains • Clients may be dual homed • Requested LSP • may need to be diverse of a Tunnel where one or both ends are neither the source or destination of the requested LSP

  4. Terminology • TUNNEL FEC (Tunnel id, Source, Destination, Extended Tunnel-id) • (TUNNEL) LSP FEC (Tunnel id, LSP ID, Source, Destination, Extended Tunnel-id) • May be useful but the LSP ID may change over time • Primarily interested in the TUNNEL FEC • Saw no point in ruling out LSP FEC

  5. Requirements • Tunnel Identifier • Understood by both Client and Server • Stable over long periods of time • Presentable in human comprehensible format • Referenceableeven if it is not yet signaled • Stable even when Tunnel is rerouted • Server network • No assumptions made on information distribution • e.g. IGP, PCE, NMS • No assumption on any protocols running between client and server other than GMPLS

  6. Server Network • Though no assumptions are made, guessing that many implementations would have information to determine path feasibility before signaling • Any and all information available should be used • Motivation here is purely pragmatic as to what we can expect to have in deployed networks and over the next few years • Crankback used as a last resort

  7. Rerouting ERO: {D, EXRS(GR_TUN_FEC),C} • Red LSP is rerouted using RFC4920 Text needs to be added to support this! • No impact on green LSP Setting a flag to allow impact has been requested (diverse paths exist, but existing needs to be moved) B I D G F C A E H J ERO: {E, EXRS(RED_TUN_FEC),C}

  8. Possible Road Forward • Chairs held a meeting Tuesday with authors and interested parties • Weds we had discussion with authors of draft-fedyk-ccamp-uni-extensions • Both drafts are signaling based approaches. • Tunnel FEC and Path Affinity Set (PAS) are similar constructs. • These could both be accommodated in a single TLV with sub-TLVs

  9. Next Steps • Will continue to work with authors of other drafts to find common ground • Will (hopefully) result in a merger of 2 or all 3 drafts

  10. Thank You

More Related