1 / 8

JP Vasseur, Anna Charny – Cisco Systems

IETF-55 – Atlanta Distinguish a link from a node failure using RSVP Hellos extensions draft-vasseur-mpls-linknode-failure-00.txt. JP Vasseur, Anna Charny – Cisco Systems. draft-vasseur-mpls-linknode-failure-00.txt IETF-55 Atlanta.

tlage
Download Presentation

JP Vasseur, Anna Charny – Cisco Systems

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. IETF-55 – AtlantaDistinguish a link from a node failure using RSVP Hellos extensions draft-vasseur-mpls-linknode-failure-00.txt JP Vasseur, Anna Charny – Cisco Systems draft-vasseur-mpls-linknode-failure-00.txt IETF-55 Atlanta

  2. Why does this draft fit in MPLS WG ? From the MPLS WG charter: … 6. Specify MPLS-specific recovery mechanisms to allow one label-switched path to be used as backup for a set of other label-switched paths, including cases which permit local repair. What constitutes the necessary set of MPLS-specific recovery mechanism should be ascertained through cooperation with the CCAMP and TE working groups. This draft proposes a mechanism to make the distinction between a link and a node failure using RSVP hello extensions defined in RFC3209.  This does not propose any protocol extensions draft-vasseur-mpls-linknode-failure-00.txt IETF-55 Atlanta

  3. Distinction between a link and a node failure • Two motivations: • For MPLS TE FRR When a link fails, always use NNHOP bypass tunnel is more conservative but might not be very optimal,  Being able to determine the failure type is useful. draft-vasseur-mpls-linknode-failure-00.txt IETF-55 Atlanta

  4. Distinction between a link and a node failure  In the context of bandwidth protection (see draft-vasseur-mpls-backup-computation-01.txt) to fully take advantage of independent failure assumption for bandwidth sharing, one needs to be able to differentiate a link from node failure.  For distributed model, this is mandatory  For the centralized model, it is desirable but not mandatory (being able to distinguish link from node failure result in better bandwidth utilization) draft-vasseur-mpls-linknode-failure-00.txt IETF-55 Atlanta

  5. R3 failure ? R2 failure ? Backup tunnels protecting independent resources are simultaneously used (multiple failure case)  bandwidth protection violation • Why distinction between a link and a node failure is mandatory in the distributed model ? • A bi-directional link failure where each end of the failed link may use its NNHOP backup tunnels. • This problem is solved with appropriate mechanisms differentiating a link from a node failure. R1 R2 R3 R4 R5 R6 R8 T1 and T2 have been independently computed as they protect independent resources (R2 and R3) R7 draft-vasseur-mpls-linknode-failure-00.txt IETF-55 Atlanta

  6. Differentiating a link from a node failure • The idea of draft-vasseur-mpls-linknode-failure-00.txt is to run/trigger an RSVP hellos session over a diversely routed path (e.g the NHOP Bypass tunnel) once the link/node failure over the directly connected link has failed. Mode 1 : no bandwidth violation in case of link failure, more optimal in case of link failure – longer traffic disruption in case of node failure  No response to RSVP hellos on the directed link or link failure detection Trigger FRR on NHOP bypass tunnel  RSVP hello adjacency R1 R2 R4  • No response to RSVP hellos on the bypass tunnel  Node failure, start using NNHOP bypass tunnels (for TE LSPs non terminating on NHOP) • Response to RSVP hellos on the bypass tunnel  Link failure, do nothing R3 R5 Fast Reroutable LSP RSVP hellos over the NHOP bypass may run in parallel or can be triggered draft-vasseur-mpls-linknode-failure-00.txt IETF-55 Atlanta

  7. Differentiating a link from a node failure Mode 2: less traffic disruption in case of node failure – risk of temporary bandwidth violation in case of link failure – potential less optimal path  No response to RSVP hellos on the directed link or link failure detection  Trigger FRR on NNHOP bypass tunnel  RSVP hello adjacency R1 R2 R4  • No response to RSVP hellos on the bypass tunnel  Node failure, do nothing • Response to RSVP hellos on the bypass tunnel  Link failure, switch back reroutable TE LSP to the NHOP bypass tunnel. R3 R5 Fast Reroutable LSP draft-vasseur-mpls-linknode-failure-00.txt IETF-55 Atlanta

  8. Conclusion • Propose to adopt this draft as a working group document with the objective to be a BCP draft-vasseur-mpls-linknode-failure-00.txt IETF-55 Atlanta

More Related