1 / 7

Authors: Matt Hartley ( mhartley@cisco ) - Presenter Zafar Ali (zali@cisco)

Extensions to RSVP-TE for Error Notification in GMPLS UNI draft-hartley-ccamp-rro-editing-01.txt. Authors: Matt Hartley ( mhartley@cisco.com ) - Presenter Zafar Ali (zali@cisco.com) Oscar Gonzalez de Dios (ogondio@tid.es) Cyril Margaria (cyril.margaria@gmail.com)

clem
Download Presentation

Authors: Matt Hartley ( mhartley@cisco ) - Presenter Zafar Ali (zali@cisco)

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. Extensions to RSVP-TE for Error Notification in GMPLS UNIdraft-hartley-ccamp-rro-editing-01.txt Authors: Matt Hartley (mhartley@cisco.com) - Presenter ZafarAli (zali@cisco.com) Oscar Gonzalez de Dios (ogondio@tid.es) Cyril Margaria (cyril.margaria@gmail.com) Xian Zhang (zhang.xian@huawei.com) Agenda: Problem recap/history Changes in v1 Use cases Next Steps 89th IETF, CCAMP WG, London, UK (March 2014)

  2. Problem recap/history • In overlay networks, server nodes may wish edit RROs to hide network details from clients • Idea originally introduced in draft-ietf-ccamp-rsvp-te-srlg-collect • Moved to separate draft as it’s more generally applicable to all RRO sub-objects. • First presented at IETF 88 (Vancouver)

  3. Changes in v01 • Xian added as an author • Hop-by-hop recording of RRO changes removed • Now just one record of changes for entire LSP • Recorded in new LSP-attributes sub-object (not RRO sub-object) • Address of editing node no longer recorded • Editing flags simplified • One editing flag was redundant and has been removed

  4. Use Cases • RRO reduction • RFC 3209 specifies that the RRO should be dropped completely if the message size exceeds the MTU • This draft allows for pruning or summarization so not all information need be lost. • Client/server overlay networks • Clients wish to discover path properties (SRLGs, latency, etc). • These may be : • Propagated to higher layers for routing decisions • Used to specify requirements on other paths • It’s useful for clients to know whether the information they’re using to make decisions is incomplete or not.

  5. Use cases 1. Are red and blue paths SRLG-diverse? Can packet-TE use them for FRR or path-protection? Core Network Egress Ingress CN2 CN1 CN3 EN1 EN2 CN5 CN4 EN4 EN3 2. I’d like to set up the green path so it’s SRLG-diverse from red 3. I need a path with lower latency than red

  6. Use Cases: Overlay networks • Policy considerations • The relationship between the client and server operators may be highly variable • The amount of information transferred from the server to the client may also vary • Details may be supplied, summarized, or removed entirely • The server operator may or may not wish to inform the client of the changes that have been made • The draft refrains from forcing policy on implementors or operators; they can make their own decisions.

  7. Next Steps • This is the second presentation of this draft • Comments and feedback would be appreciated • We would like to move the draft towards WG adoption Thank you

More Related