ipfrr with
play

IPFRR WITH tle pt FAST NOTIFICATION Andrs CSSZR, tle Gbor - PowerPoint PPT Presentation

Sep 02, 2023 •201 likes •520 views

IPFRR WITH tle pt FAST NOTIFICATION Andrs CSSZR, tle Gbor ENYEDI, pt Sriganesh KINI itle Outline pt ws Conceptual idea l 1 pt Details -5 pt Preparation phase Fail-over operation Packet contents

  1. IPFRR WITH tle pt FAST NOTIFICATION András CSÁSZÁR, tle Gábor ENYEDI, pt Sriganesh KINI

  2. itle Outline pt ws › Conceptual idea l 1 pt › Details -5 pt – Preparation phase – Fail-over operation – Packet contents ˆˇ – Bypassing legacy nodes s or IPFRR with Fast Notification | draft-csaszar-ipfrr-fn | IETF 80, Prague | 2011-03-28 | Page 2 rea

  3. itle IPFRR – A Fresh Perspective pt ws D › LFA is not perfect because not all l 1 pt failures can be repaired purely locally -5 Without pt › IGP can repair all failures but it is slow A any info in S: loop › Can we combine them and get ˆˇ S Default the best of both worlds? shortest path › YES, WE CAN s or IPFRR with Fast Notification | draft-csaszar-ipfrr-fn | IETF 80, Prague | 2011-03-28 | Page 3 rea

  4. IPFRR with Fast Notification itle pt Basic idea ws LFA local repair IPFRR-FN IGP global repair l 1 pt -5 pt CP CP CP Pre-configure Pre-configure advertise send up to CP backup entries backup entries further Local or Local or ˆˇ download local local advertise Local external external new reconfig. reconfig. further trigger trigger trigger entries LC LC LC › Have failure information propagate the area quickly: on the fast path, without control plane involvement › Distant nodes can switch to pre-calculated alternative next-hops (if needed) › Preparing for remote failures also investigated in “ Remote LFAPs ” – draft-hokelek-rlfap-01 – Needs a proper notification procedure s or IPFRR with Fast Notification | draft-csaszar-ipfrr-fn | IETF 80, Prague | 2011-03-28 | Page 4 rea

  5. Network Simulator ns-2 did Fast Notification 13 itle years ago! pt ws › Remember “rtProto LS” in ns-2? l 1 pt – it’s a simplified link state routing protocol -5 pt › ns-2 does NOT simulate message processing time! › See what happens when re-routing: – Failure notification instantly sent out ˆˇ – Re-configuration in no time – User packets follow notifications instantly › Our goal is to come as close to this as possible – By doing processing in the forwarding plane – No control plane involvement during fail-over s or IPFRR with Fast Notification | draft-csaszar-ipfrr-fn | IETF 80, Prague | 2011-03-28 | Page 5 rea

  6. IPFRR based on Fast Notification: itle Main components pt ws Preparation for the failure Fail-over mechanism l 1 pt › Quick local failure detection BFD, -5 in the linecard L2 trigger, pt LoS, etc. › Originate notification from › Pre-calculate and pre-install Fast Notification within the linecard routes to distribute ˆˇ service immediately notifications (draft-lu-fn-transport) › Distribute notification › Process notification in the › Pre-calculate and pre-install linecard – perform fail-over failure specific alternative This draft without consulting the control routes plane s or IPFRR with Fast Notification | draft-csaszar-ipfrr-fn | IETF 80, Prague | 2011-03-28 | Page 6 rea

  7. itle Preparation Phase pt ws › Let the IGP pre-calculate its response to protected failures l 1 pt – If the failure of a protected resource resulted in FIB change, pre- -5 install this change to the forwarding plane pt The IPFRR detour is › Area scope: prepare only for intra-area identical to the “ final ” path failures after re-convergence! › Backup calculation/storage limited by: ˆˇ – Only need to prepare for failures on the SPT from the current node – Only need to install a backup route for a failure if failure specific alternate next-hop is different from primary NH ~ New NH/ ~ Destinations adjacency needing update Failure ID i New Value a New Value b New Value c … Pointer 1 Pointer 2 Pointer 3 Pointer 4 Pointer 5 Pointer 6 Failure ID j New Value c New Value a New Value d … … Pointer 2 Pointer 5 Pointer 6 Pointer 1 Pointer 7 Pointer 8 s or IPFRR with Fast Notification | draft-csaszar-ipfrr-fn | IETF 80, Prague | 2011-03-28 | Page 7 rea

  8. Fail-Over: Step by Step itle Initiate FN pt ws › Detect failure l 1 pt › Create (or just load) payload of FN packet -5 pt – OrigID: Identifier of the originator – NbrID: Identifier of the node to which the connectivity was lost Data pre-loaded – LinkID: Identifier of the link/SRLG through which the by IGP to ˆˇ connectivity was lost forwarding – Sequence number: LSDB digest plane › To protect against replay attacks › Disseminate using FN – Redundant tree distribution mode is preferred – Punt and forward in each hop – FN packet loss should be minimised (e.g. priority) › Redundant trees è likely receiving multiple replicas - At least one should get through to every node s or IPFRR with Fast Notification | draft-csaszar-ipfrr-fn | IETF 80, Prague | 2011-03-28 | Page 8 rea

  9. Fail-Over: Step by Step itle Activate Backups after Receiving FN pt ws › Implementation dependent l 1 pt -5 pt › In general: – Find routes which have alternates installed for FailureID ˆˇ › E.g. if Failure ID in pkt is “j”, make updates described by second row: Failure ID i New Value a New Value b New Value c … Pointer 1 Pointer 2 Pointer 3 Pointer 4 Pointer 5 Pointer 6 Failure ID j New Value c New Value a New Value d … Pointer 2 Pointer 5 Pointer 6 Pointer 1 Pointer 7 Pointer 8 … s or IPFRR with Fast Notification | draft-csaszar-ipfrr-fn | IETF 80, Prague | 2011-03-28 | Page 9 rea

  10. IPFRR with Fast Notification itle pt Legacy Node Bypass ws › Legacy l 1 pt – It can at least forward the multicast packets of FN -5 pt – FN packets are not recognised/processed à routes are not changed! › FN-capable nodes – When pre-calculating backups, have to Dest ˆˇ consider that legacy nodes FN FN won’t change routes › Needs: – Advertisement of FN capability FN FN legacy – Router Capability TLVs Dest › OSPF [RFC4970] › IS-IS [RFC4971] s or IPFRR with Fast Notification | draft-csaszar-ipfrr-fn | IETF 80, Prague | 2011-03-28 | Page 10 rea

  11. itle Summary pt ws › FN enables preparing for remote failures l 1 pt › IGP runs pre-calculation in the background preparing for -5 pt topology changes – IPFRR detour identical to “ final ” path (after IGP re-convergence) è eliminates IGP micro-loop ˆˇ s or IPFRR with Fast Notification | draft-csaszar-ipfrr-fn | IETF 80, Prague | 2011-03-28 | Page 11 rea

  12. itle Questions, comments? pt ws › FN Framework l 1 pt › FN Transport -5 pt › IPFRR FN ˆˇ s or IPFRR with Fast Notification | draft-csaszar-ipfrr-fn | IETF 80, Prague | 2011-03-28 | Page 12 rea

  13. BACKUP SLIDES tle pt tle pt

  14. itle IETF’s Existing IPFRR pt ws › Assumes very quick failure detection – not part of IPFRR l 1 pt – e.g. BFD, lower layer upcall -5 pt › “ … to compute backup routes that allow the failure to be repaired locally by the router(s) detecting the failure without ˆˇ the immediate need to inform other routers of the failure … ” › Options – Loop free alternates (LFA) – “Multi-hop repair paths” s or IPFRR with Fast Notification | draft-csaszar-ipfrr-fn | IETF 80, Prague | 2011-03-28 | Page 14 rea

  15. itle Existing Solutions pt ws l 1 › Rely on safe, loop-free neighbours (LFA) pt – Loop free alternative next-hops not always exist: not full coverage (ca. 80% in -5 practice) pt › Especially, if failure handling is needed bi-directionally › LFA can be good enough if we are in control of topology › Multi-hop repair paths (full coverage) – Rely on tunnelling/encapsulation (e.g. Not-Via Addresses) ˆˇ › Encapsulation not preferred due to fragmentation at MTU (SAR decreases forwarding performance) › Special tunnel endpoint addresses represent extra management burden – Rely on interface-specific forwarding (e.g. FIFR, U-Turn LFA) › Existing router design often have the same replica of the forwarding table at each linecard (serving multiple interfaces/adjacencies) – an assumption deep in HW/SW à hard to change – Assume packet marking to encode routing configuration ID (e.g. MRC) › No free bits in IP header for this purpose › Alternative would be encapsulation (see above) s or IPFRR with Fast Notification | draft-csaszar-ipfrr-fn | IETF 80, Prague | 2011-03-28 | Page 15 rea

  16. Fail-Over: Step by Step itle Processing FN: Identifying the Failure pt ws Failure-free l 1 FailureID=LinkID pt NodeID=NbrID FN msg: OrigID, NbrID, LinkID -5 pt SRLG failure FailureID=LinkID NodeID=NbrID Yes FN msg: OrigID, NbrID, LinkID ˆˇ Same SRLG? FailureID==LinkID No Yes No Common node? NodeID==NbrID FN msg: OrigID, Node failure Same node? NbrID, LinkID No Multiple failures FailureID==NbrID FailureID=NbrID Yes s or IPFRR with Fast Notification | draft-csaszar-ipfrr-fn | IETF 80, Prague | 2011-03-28 | Page 16 rea

  17. itle Application to LDP pt ws › LDP unsolicited / liberal retention mode l 1 pt -5 pt › FN initiates MPLS FIB update ~ New label & ~ Destinations new NH/adj ˆˇ needing update Failure ID i New Value a New Value b New Value c … Pointer 1 Pointer 2 Pointer 3 Pointer 4 Pointer 5 Pointer 6 Failure ID j New Value c New Value a New Value d … … Pointer 2 Pointer 5 Pointer 6 Pointer 1 Pointer 7 Pointer 8 s or IPFRR with Fast Notification | draft-csaszar-ipfrr-fn | IETF 80, Prague | 2011-03-28 | Page 17 rea

More recommend