[email protected]
[Top] [All Lists]

Draft rtgwg minutes for July 24, 2007 meeting

Subject: Draft rtgwg minutes for July 24, 2007 meeting
From: "John G. Scudder"
Date: Fri, 27 Jul 2007 11:07:23 -0500

Here are our draft minutes. Please send any corrections before August 10. Thanks to Saravana for taking notes.

RTGWG minutes
July 24, 2007
Scribe: Saravana K (with additional notes from John Scudder)


- Administrivia
   John Scudder
   5 min
- Applicability of not-via to distance vector and path vector protocols
   Stewart Bryant
   10 min
- draft-ietf-rtgwg-ordered-fib update
   Pierre Francois
   10 min
- Graceful Restart extensions for RIP
   Saravana K
   15 min
- draft-hokelek-rLFAP-00
   Ibrahim Hokelek
   20 min

------------------------------------------------------------------------ -
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-
Topology applicability.
- 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
address families.
- 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 routes. 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 unscalable.
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
numbers/time budgets.
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
[email protected]

<Prev in Thread] Current Thread [Next in Thread>
  • Draft rtgwg minutes for July 24, 2007 meeting, John G. Scudder <=