Subject: RE: fn-transport/ipfrr drafts

From: András Császár <[email-masked]>
Date: Tue, 5 Apr 2011 15:12:29 +0200

Dear All,

Note that fn-transport already is at version 01. Links to the docs:

http://tools.ietf.org/html/draft-lu-fn-transport-01
http://tools.ietf.org/html/draft-csaszar-ipfrr-fn-00

We'd really appreciate comments and suggestions. 

András

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Jeff Tantsura
> Sent: 2011. március 29. 14:58
> To: [email-masked]
> Subject: fn-transport/ipfrr drafts
> 
> Hi rtgwg,
> 
> The authors would like to solicit comments from the workgroup.
> 
> draft-lu-fn-transport-00
> draft-csaszar-ipfrr-fn-00
> 
> Thank you in advance!
> 
> Regards,
> Jeff  
> 
> _______________________________________________
> rtgwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtgwg
>

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 05 Apr 2011 17:37:52 -0400

In message <[email-masked]>
> We'd really appreciate comments and suggestions. 

Same comment as on the OSPF mailing list.  This is attacking a
non-problem.

Flooding time is not a problem on modern implementations, unless the
implementation is badly designed or badly coded.

IPFRR is intended to eliminate the need for an SPF and route
download and the need to contact any other router in any way to get an
initial repair done.  That is a different problem.

Curtis

---

From: Alia Atlas <[email-masked]>
Date: Tue, 5 Apr 2011 21:00:20 -0400

Curtis,

Andras is familiar with the problem IPFRR is trying to solve.

As I understand it, there are 3 separate questions:
   a) Is a multicast distribution mechanism that can report bad news
quickly & survive single failures useful?
   b) Is this useful for an IGP to speed network convergence?
   c) If one assumes very rapid ( speed of light)  delays for remote
failures, what pre-computation and FIB installation could be possible?

I have not heard requirements and rationale sufficient yet.
Security is also a concern - but the first questions are whether any
mechanism is  desirable.

Alia

---

From: mike shand <[email-masked]>
Date: Wed, 06 Apr 2011 10:25:14 +0100

Alia,

     My quick replies would be

a) possibly, but I'm not sure of the application. Certainly not (b).
b) I don't think so
c) I'd be very concerned about the scaling issues of doing that

     Mike

On 06/04/2011 02:00, Alia Atlas wrote:
> quickly&  survive single failures useful?
> 2011/4/5 Curtis Villamizar<[email-masked]>:
>> In message<[email-masked]>
>> András Császár writes:
>>> Dear All,
>>>

---

From: András Császár <[email-masked]>
Date: Wed, 6 Apr 2011 13:59:16 +0200

> initial repair done.  That is a different problem.

LFA does not need contact with other routers, but it cannot provide full coverage.
We explore the possibility of lifting the existing IPFRR constraint that explicit notification is not allowed.

So, instead of saying that explicit notification is not allowed, we think that a fast and lightweight dataplane based notification dissemination protocol could be a way ahead towards full FRR failure coverage.

The questions is then: Can this explicit notification be made quick and simple enough to be feasible? Our answer is yes, this is FN, described in draft-lu-fn-transport-01

IPFRR-FN is then the following: Assuming that there exists a fast notification protocol that can notify each node in the area about any single failure, could we then let the IGP to pre-calculate and pre-install failure specific backup routes? We think yes.

It is clear, though, that we should get back with (more) numbers on practical feasibility:
- What is amount of information needed to prepare backup routes for different local and non-local failures?
- How does this pre-calculation stress the CP?
- How does the CP-to-DP pre-downloading of this backup information stress a node?
- How fast can a linecard in practice change the information in its FIB using this local backup database?

BR,
András

---

From: András Császár <[email-masked]>
Date: Wed, 6 Apr 2011 14:20:45 +0200

Hi,

Probably you are more interested in the opinion of the rest of the community, but anyway:

a) yes, especially for those applications that target quick changing of active dataplane routes to alternative routes when something happens in the network (as for now this could be FRR, where event=failure). It could be also very useful in split DP-CP environments (such as FORCES and OpenFlow), where event specific alternative routes could be activated by forwarding elements without consulting the CP.

b) I'm not an author of the ospf-fn draft but in my opinion it could be useful in those cases when regular OSPF flooding is a noticable part of the overall convergence. This may be the case with modern routers where the existing convergence bottlenecks are greatly reduced (SPF calc is not long anymore, RIB-to-FIB download bottleneck is getting optimised by incremental updates and a few updates causing many route updates in the FIB)

c) We should come back definitely with more numbers on (copy/pasting from the email I just sent responding to Curtis):

Some initial estimations you can find in the Appendix of the ipfrr-fn draft.

An important note: You don't have to download alternative routes for each failure for each destination! Only those that matter:
1. Failure is on shortest path towards the destination
2. Failure results in route change

This is much less.

Will come back with more numbers.

Kind regards,
András

> On Behalf Of mike shand
> Sent: 2011. április 6. 11:25
> To: [email-masked]
> Subject: Re: fn-transport/ipfrr drafts
> 
> Alia,
> 
> >> In 
> message<8DCD771BDA4A394E9BCBA8932E83929720E74AF21C@ESESSCMS036
> 3.eemea.ericsson.se>
> >> András Császár writes:
> >>> Dear All,
> >>>

---

From: Peter Psenak <[email-masked]>
Date: Wed, 06 Apr 2011 14:35:15 +0200

András,

> 2. Failure results in route change

the amount of computation and LC storage to cover for all 'interesting' 
failures and all impacted destinations would likely be still 
significant. Which is in contrast to a limited gain you get for it, 
compared to 'traditional' LFA.

thanks,
Peter

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 06 Apr 2011 14:15:48 +0100

Andras

To make sure that we are not talking at cross purposes, can you let us 
know what size of network that you anticipate applying this to?

Stewart

---

From: John E Drake <[email-masked]>
Date: Wed, 6 Apr 2011 08:03:06 -0700

Comments inline

Sent from my iPhone

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Alia Atlas
> Sent: Tuesday, April 05, 2011 6:00 PM
> To: [email-masked]
> Cc: [email-masked]

JD:  Is IGP flooding a significant contributor to network convergence and is a multicast distribution mechanism sufficiently faster to justify the control plane complexity associated with building and maintaining a multicast tree?  Data plane support of multicast, even in hardware, involves packet replication and is seldom line-rate.  The drafts' treatment of building and maintaining a multicast tree in a dynamic network is akin to 'magic happens'.

>    b) Is this useful for an IGP to speed network convergence?

JD:  See above.  When we actually did this, nearly twenty years ago, it proved to be of dubious benefit.

> failures, what pre-computation and FIB installation could be possible?

JD:  This is implementation specific and should be outside the scope of the discussion.

> Security is also a concern - but the first questions are whether any

JD:  You can probably guess what I think.

> > In message
> <[email-masked]
> .se>
> > András Császár writes:
> >>
> >> Dear All,
> >>

---

From: András Császár <[email-masked]>
Date: Wed, 6 Apr 2011 17:57:02 +0200

Hi,

In the appendix (http://tools.ietf.org/html/draft-csaszar-ipfrr-fn-00#appendix-A) we started to make some preliminary estimations on how much information is need to maintain failure specific backups for areas with 200 & 500 nodes with 500k routes. They were, we think, pretty worst case estimations.

We will check for 1000 node area size, too. And we got a suggestion not to overestimate the network diameter, which will result in much smaller numbers.

But it is clear that we need to answer more questions then just the backup database size. Further questions I mentioned in my previous emails.

BR,
András

> On Behalf Of Stewart Bryant
> Sent: 2011. április 6. 15:16
> To: [email-masked]

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 07 Apr 2011 22:47:59 -0400

> c) I'd be very concerned about the scaling issues of doing that

Agree.

BTW - Wording nit: I assume Alia meant "very rapid (speed of light)
propogation of the news of remote failures".  The failures thenselves
are already very fast, so no need to make them faster. :-)

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 07 Apr 2011 22:53:23 -0400

In message <[email-masked]>
> know what size of network that you anticipate applying this to?

Stewart,

Size in number of nodes and links or in delay diameter?  Complexity or
geography?  I could see that datacenter (very small geography) and
long haul provider network (large geography) might differ.

Curtis