Routing Area WG (rtgwg) 73rd IETF - Minneapolis, MN TUESDAY, November 18, 2008 1710-1810 Afternoon Session III ============================================================== CHAIR(s): Alex Zinin (not present) John Scudder Alia Atlas Scribe: Bob Salmi existing work item update a) expect a last call on the 2 framework drafts after ietf. b) progress ordered fib draft progressing revived is-is extensions draft no ospf extensions draft need to investigate this. c) longer term ipfrr-notvia-addresses d) drafts which are on hold pending demand ipfrr-ip-mib microloop-analysis draft What things need a home now ------------------------------- dmitry: propose what about multicast frr should this be part of charter update ? jgs: Mcast frr would be reasonable to add dward : 1) igp scaling architectural issues 2) composite transport groups (Not clear if there are deliverables now/yet) Danny: transport layer protecction align with work going on in other groups Stuart Bryant: you mean layer 4 right Danny: yes Dward: some of this may happen in opsec ----------------------- Loop Free IP fast reroute using Local and remote LFAP's presentation Extensions needed to local lfap X-hop neighborhood parameter route tables of nodes within X-hop neighborhood are locally calculated using lsdb and calculation of SPT without exchanging information no impact on convergence failure notification mechanism How it works 1) receive lsdb from ospf 2) calculate LFAP's 3) verify interfaces via fea 4) on failure send notification via fea & istall lfap's to rib 5) on receipt of fail notification install lFAP's to rib have implementation using "WISER" emulation tool Fedora core 8 and XORP Convergence results in slides loop free discussion Comments: Mike Shand: Are you saying that for unicast you won;t get micro loops ? yes Mike You may get remote loops outside the diameter of the repair area Alia: Inconsistencies in draft regarding how LFA's are computed some examples in draft would cause forwarding loops Alia: Why is the notification not applicable to the IGP. I.E. Why not just tune the IGP instead of shorting it. everything is pre computed so you can just trigger the install George Swallow: do you need to precompute all the failures for your neighbors links as well yes George: so that lots of state I have to maintain right. I have to have a strategy for all failures Stewart in a realistic topology is this order k neighbors to the power of x hops the number for the number of strategies we need to precompute and store Stewart: what about competing solutions also should look at some of the work with frr tunnels what is wrong with an encapsulation based solution disadvantage is overhead of additional header and processing jgs: perhaps we should take this discussion offline. jgs: 2nd or 3rd time this draft has been presented what do you want to do with it jgs: based on room poll we will pass on this work