80 likes | 89 Views
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.
E N D
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
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
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
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
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
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
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
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