Subject: RE: Work on IP fast rerouting in IGPs

From: "Don Fedyk" <[email-masked]>
Date: Tue, 20 Apr 2004 08:17:14 -0400

>  In this thread I would like to solicit feedback from the WG 
> on a more generic  question, independent of the details of 
> any specific draft, namely: do you  believe that we should 
> add the topic of "IP fast reroute in IGPs" to the  charter of RTGWG?

Yes it is an important area and we should add it to the charter.

Don

_______________________________________________
Rtgwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rtgwg

---

From: "Howard C. Berkowitz" <[email-masked]>
Date: Tue, 20 Apr 2004 11:35:28 -0400

>Yes it is an important area and we should add it to the charter.

I agree. One point that might be considered in the charter is that 
the problem has three parts:
     1. path determination that precomputes (or rapidly recomputes)
        alternate paths
     2. modifying FIBs with the new path
     3. Detecting a malfunction requiring reroute.

#1 and #2 are clearly within scope. Perhaps it's too obvious to 
mention, but #3 really has more scope than subsecond hellos, which is 
relevant. I believe we also want to have well-defined primitives 
(even if SNMP traps) that allow the rerouting process to receive 
specific hardware/network management asynchronous events to start the 
process.

---

From: Pekka Savola <[email-masked]>
Date: Thu, 22 Apr 2004 12:52:22 +0300 (EEST)

Yes, I think this is an important topic worth addressing.

However, I am similarly concerned as Howard that we have identified 
the problems we are tackling correctly, and that we get all the pieces 
in place as well. (However, currently I'm thinking that sub-second 
Hellos or similar may be sufficient for 3.)

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: "Howard C. Berkowitz" <[email-masked]>
Date: Thu, 22 Apr 2004 18:48:28 -0400

>Hellos or similar may be sufficient for 3.)

Your point about #3 raises some interesting questions about the real 
requirement. I have seen service providers want sub-50 millisecond 
reconvergence, but I suspect that is simply a cut-and-paste from SS#7 
and SONET cutover.

My sense has been that any control plane that has a significant 
number of peers and also a subsecond hello requirement will need to 
be multiprocessor, with hardware offload of the hello processing.

This does get into implementation and thus might be out of scope, but 
it's worth a passing mention.

---

From: David Meyer <[email-masked]>
Date: Thu, 22 Apr 2004 16:43:21 -0700

>> reconvergence, but I suspect that is simply a cut-and-paste from SS#7 

	I did a lot of work on this exactly this topic when I was
	at Sprint, and I the only thing I could find that
	approached a 50ms-like convergence requirement was some
	older mux equipment that would reset if it lost signal
	for more that about 75ms.    

	BTW, a reasonable reference here is "Is 50 ms Restoration
	Necessary?" by Jeff Schallenberg. I put the ppt on
	http://www.1-4-5.net/~dmm/Schallenburg_50ms.ppt for those
	who might be interested.

	Dave

---

From: "zafar ali" <[email-masked]>
Date: Thu, 22 Apr 2004 20:29:41 -0400

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of David Meyer
>Sent: Thursday, April 22, 2004 7:43 PM
>To: Howard C. Berkowitz
>Cc: [email-masked]
>Subject: Re: Work on IP fast rerouting in IGPs
>
>
>>> >the problems we are tackling correctly, and that we get all the 
>>> >pieces in place as well. (However, currently I'm thinking that 
>>> >sub-second Hellos or similar may be sufficient for 3.)
>>> 

I agree, I have seen similar studies else where that show that 50 msec is
NOT a requirement from application's view-point. 

Thanks

Regards... Zafar

---

From: "Howard C. Berkowitz" <[email-masked]>
Date: Thu, 22 Apr 2004 21:41:59 -0400

>NOT a requirement from application's view-point.

That is indeed my impression, at least with respect to POTS networks. 
When I was at a router vendor, however, carrier customers often 
demanded it, without knowing exactly why.

Somewhat apropos of the topic of when things happen in the router, 
our I-D on single-router BGP convergence, 
http://www.ietf.org/internet-drafts/draft-ietf-bmwg-conterm-05.txt

was conditionally approved by the IESG on April 2.  They made some 
good editorial suggestions, but I am trying to find out the 
administrative procedure to make the changes and then get the revised 
document to the RFC Editor. With the other documents I've gotten 
through the IESG, they either approved it or not.

---

From: Pekka Savola <[email-masked]>
Date: Fri, 23 Apr 2004 07:04:43 +0300 (EEST)

> 	for more that about 75ms.    

I've talked with some researchers about this and the reason they 
seemed to like sub-50ms, namely 10ms, is that with that you'd just 
lose one VoIP packet, and that would be automatically fixed by the 
error correction.

My take on that was a lot like.. "uhh, the user isn't going to notice 
100ms break if it happens once a month, and even 1s breaks would be 
acceptable if they didn't happen too frequently."

So, I don't think sub-50ms is a real requirement, but if we can get to 
sub-200/250ms area, we should be pretty well off.

---

From: Alex Zinin <[email-masked]>
Date: Thu, 29 Apr 2004 12:42:40 -0700

Folks-

 There's a clear consensus in the WG that this work item needs to be taken on.

 I also sense that it will be useful to produce a framework kind of document
 explaining what we're talking about and how different pieces of technology fit
 together. I would be fine with this, provided that it will be a lean and crisp
 document that we can finish within months, and someone commits to take an
 active (I mean really active) lead on this.

 We also need to think about how/whether MIBs may be affected. It is possible
 that the precalculated alternate next hops need to be reported in the MIB and
 marked as such. Opinions are welcome.
 
 At this point I see the following milestones that need to be added (the
 discussion on Alia's document may yield more):

   MAY 2004 Submit initial WG I-D documenting framework for fast IP rerouting

   MAY 2004 Submit initial WG I-D documenting basic fast IP rerouting mechanism
            based on precalculation of feasible loop-free next hops

   SEP 2004 Submit framework for fast IP rerouting to IESG for publication as INFO

   SEP 2004 Submit basic fast IP rerouting mechanism to IESG for publication as PS

 I will bring these to the IESG unless I hear an objection within a few days.

--
Alex