Draft rtgwg minutes for July 24, 2007 meeting

Folks,

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

--John

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

Agenda:
=======

- 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
rtgwg@ietf.org
https://www1.ietf.org/mailman/listinfo/rtgwg