Here are our draft minutes. Please send any corrections before
August 10. Thanks to Saravana for taking notes.
July 24, 2007
Scribe: Saravana K (with additional notes from John Scudder)
- Applicability of not-via to distance vector and path vector protocols
- draft-ietf-rtgwg-ordered-fib update
- Graceful Restart extensions for RIP
Working Group Update :
- John Scudder presented a update on the progress of the working
group with regard to the current status of the documents and milestones.
- John wanted to know if any people were interested in coming up with
drafts on the following areas : IPFRR for Multicast and Multi-
- wrt Multi-Topology applicability the requirement is to come up with
some use cases to help people understand how MT can be used in other
circumstances other than just using it for supporting different
- Any interested persons to notify John.
Applicability of not-via to distance vector and path vector protocols
- Stewart Bryant
John : Where do you want go with this presentation
Stewart : The current work for not-via is concentrated on mostly for
link state protocols, wanted to highlight its applicability for link
state and distance vector protocols as well.
Graceful Restart extensions for RIP - Saravana K
Acee : Why cannot RIP do a mechanism to preserve the stale routes in
forwarding table, wait for a static time for the route updates to be
received and then update the forwarding table and clean up the stale
Saravana : The main issue is topology change handling, if any routes
are deleted during the restart the restarting router will not
propagate the received withdraws. So the topology wont converge for
180s. Also if there are multiple ECMPs, the set of paths selected
before and after a restart might be different.
Andrew Lange : What is the requirement for this issue, why the sudden
need for GR in RIP
Saravana : We do have some active deployments of RIP, one of the
latest requirements was for the seamless software upgrade capability
for RIP and when analyzing those requirements we came up with these
possible issues when RIP undergoes a restart.
Bill Fenner: Your customer is OK with RIP's other deficiencies such
as counting to infinity, but not this? Why not migrate them to some
more capable IGP?
Saravana: It's what the customer wants.
Ross Callon: Do customers thing this will solve all RIP's problems?
Saravana: It's mostly for seamless software upgrade.
Ina Minei: One of the assumptions for GR is topology is stable, so
what is the issue in RIP with regard to this.
Saravana : In other protocols the topology will converge immediately
after the protocols complete their restart processing, but in RIP it
wont converge for a very long time (180s)
John Scudder: Where do you go from here, request show of hands?
Saravana: We're planning to implement it, would like to offer it as
WG doc if others are interested in standardizing.
Chris Hopps : Need some time to go back to the RIP protocol.
John Scudder: OK, let's move this to the mailing list so folks can
have a chance to review RIP.
draft-hokelek-rLFAP-00 - Ibrahim Hokelek
Stewart Bryant: If you have time to do signaling of failure, why not
just do an IGP convergence?
Ibrahim: We precompute within a region, we just need failure info
Chris Hopps : IS-IS LSP fragment is advertised when a link fails --
seems about the same as your failure info. What is the difference?
Chris Hopps: With IS-IS nearby neighbors will get the flooded LSP
fragment first so convergence ought to be similar.
Ibrahim : If the link is flapping all the time (esp in case of radio
links), if you are going to be sending the info again and again, it
will affect the network. Our proposal scopes flooding.
Stewart: Can't you just hold down flapping links though?
Ibrahim: Scoped flooding means we don't have to.
Stewart : The idea of FRR is to pre-compute the repair paths, even
the not-via addresses are pre-computed.
Ibrahim : One issue is that the backup information is computed for
all the network and the overhead involved is large. In this proposal
the backup computation is only for the immediate nexthops
Mike Shand: You seem to be overestimating the overhead of not-via?
Ibrahim: Various other proposals don't cover multiple failures or are
Chris : Give some concrete examples of difference between normal
convergence used by the protocols and using this mechanism. Because
it seems like both the mechanisms are similar. Please include
John : What to do with this draft
Ibrahim : Get feedback and see if the WG is interested in the draft
John : move this to the mailing list
rtgwg mailing list