Subject: Review request for draft-lu-fast-notification-framework-00.txt

From: Wenhu Lu <[email-masked]>
Date: Wed, 3 Nov 2010 19:59:51 -0400

Dear all,

We would like to solicit comments and inputs of the new draft "Fast Notification Framework".

   This document describes an architectural work that competes with the
   IP Fast Re-Route (IPFRR) solution which aims to minimize the network
   down time in the event of equipments failure.  The work provides a
   layered framework based upon which applications such as the domain-
   wide fast convergence may be achieved through the transport layer
   fast delivery of failure notifications.

We plan to give a presentation on this in the upcoming IETF79.
The draft can be found at http://tools.ietf.org/html/draft-lu-fast-notification-framework-00

Your review and comments are greatly appreciated.

Thank you,
-wenhu

---

From: mike shand <[email-masked]>
Date: Thu, 04 Nov 2010 09:05:33 +0000

This draft seems to completely miss the point. It focusses on 
attempting to improve the time to distribute failure information 
(although it is not clear that the proposed methods offer significantly 
faster propagation of information than that already achieved by a well 
tuned IGP flooding process). But it completely ignores the time taken to 
process that information and update the hardware forwarding tables, 
which, as is well known, is the rate determining step.

     Mike

On 03/11/2010 23:59, Wenhu Lu wrote:
> The draft can be found at 
> _http://tools.ietf.org/html/draft-lu-fast-notification-framework-00_
> _______________________________________________
> rtgwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtgwg

-- 
For corporate legal information go to:
www.cisco.com/web/about/doing_business/legal/cri

---

From: Wenhu Lu <[email-masked]>
Date: Thu, 4 Nov 2010 17:27:58 -0400

Hi Mike,

Thank you very much for the review and comments.

Let me outline what this draft intends to achieve.
The proposed framework separates the domain-wide total convergence time into
Network delay + local delay.
These two delays are independent and can be improved independently. Do you agree?

The network delay part can be minimized or even eliminated if some good fast notification measure is employed in the transport layer. This is part of the goals of this draft. We will discuss this in detail in the upcoming IETF meeting when we get chance.
The local delay is also very important. It is an integral part of the overall convergence. We didn't ignore this and mentioned it in section 4.4. 
However this should not be a reason to drag the effort in reducing the network prapagation delay. Do you agree?

As for the local delay, we understand that for now the route download time is a significant factor of convergence. But who can say this won't change given the time and so many smart brains.

Regards,
-wenhu

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of mike shand
Sent: Thursday, November 04, 2010 2:06 AM
To: [email-masked]
Subject: Re: Review request for draft-lu-fast-notification-framework-00.txt

  This draft seems to completely miss the point. It focusses on attempting to improve the time to distribute failure information (although it is not clear that the proposed methods offer significantly faster propagation of information than that already achieved by a well tuned IGP flooding process). But it completely ignores the time taken to process that information and update the hardware forwarding tables, which, as is well known, is the rate determining step.

     Mike

---

From: Olivier Bonaventure <[email-masked]>
Date: Thu, 04 Nov 2010 23:17:29 +0100

Wenhu,
> However this should not be a reason to drag the effort in reducing the network prapagation delay. Do you agree?

I'm not sure that reducing the network delay will have an impact on the
overall performance. In a 2005 paper, we performed simulations to study
the factors that influence the convergence time of routing protocols in
ISP networks and found that as Mike noted that the propagation delay of
the failure notification did not influence the convergence time
significantly.

See
http://inl.info.ucl.ac.be/publications/achieving-sub-second-igp-convergence-

and look e.g. for the simulation results for the convergence time in a
worldwide network were all link delays are set to 1 millisecond instead
of the actual propagation delay

Olivier

-- 
INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be

---

From: Wenhu Lu <[email-masked]>
Date: Thu, 4 Nov 2010 18:46:52 -0400

Thanks Olivier for the pointer, will take a look of your 2005 paper.
-wenhu 

-----Original Message-----
From: Olivier Bonaventure [mailto:[email-masked]] 
Sent: Thursday, November 04, 2010 3:17 PM
To: Wenhu Lu
Cc: [email-masked]
Subject: Re: Review request for draft-lu-fast-notification-framework-00.txt

Wenhu,
> The proposed framework separates the domain-wide total convergence 
> time into Network delay + local delay.

I'm not sure that reducing the network delay will have an impact on the overall performance. In a 2005 paper, we performed simulations to study the factors that influence the convergence time of routing protocols in ISP networks and found that as Mike noted that the propagation delay of the failure notification did not influence the convergence time significantly.

See

and look e.g. for the simulation results for the convergence time in a worldwide network were all link delays are set to 1 millisecond instead of the actual propagation delay

Olivier

---

From: <[email-masked]>
Date: Mon, 8 Nov 2010 09:28:24 +0100

Olivier,

I agree with your point of view about the network delays.

Wenhu,

Moreover I think that network wide convergence will never permit to
achieve the same level of service (in term of packet loss) than local
protection mechanism like LFA, or FRR using MPLS TE. So if you to
achieve tens of msec packet loss, LR is needed absolutely.

Other point, when you talk about current mechanism of LSP ack mechanism
in current IGPs (paragraph 3) that involves control plane and so slow
down the network wide convergence, you are right (purely theorically)
but this is clearly necessary I think. It would be bad if you start
flooding corrupted information network wide ...

Some vendors like CISCO already implements some fast-flooding mechanism
not in the same way you propose, but that can theorically permit to save
some extra computation on nodes.

Other point, how are you planning to manage churn of events with your
framework ? There is still a need like in most IGP to slowdown event
propagation in case of churn. Fastconvergence is good for a single
event, but you still need to adapt to churn and slowing down convergence
to prevent life of you nodes :)

Last point, is that here you deal only with IGP convergence, but on a
node which is running multiple routing protocols, an IGP event as
directly an effect on other routing protocols (PIM, BGP ...). And we
already saw on our network, that concurrence of protocols inside a node
is a major issue for fast IGP convergence (BGP slowing down IGP
convergence for example due to bad process prioritization) and here we
are dependent of vendor implementations. On some router OS, there is a
huge work on this with vendors.

To conclude from my point of view, I'm not sure there will be a gain in
network wide convergence with your proposal.

Regards,

Stephane Litkowski
France Telecom

*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************

---

From: Wenhu Lu <[email-masked]>
Date: Mon, 8 Nov 2010 15:02:38 -0500

Hi Stephane,
Thanks for your comments.
Please see my responses inline started with [luw].

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, November 08, 2010 12:28 AM
To: [email-masked]; Wenhu Lu
Cc: [email-masked]
Subject: RE: Review request for draft-lu-fast-notification-framework-00.txt

Olivier,

Wenhu,

Moreover I think that network wide convergence will never permit to achieve the same level of service (in term of packet loss) than local protection mechanism like LFA, or FRR using MPLS TE. So if you to achieve tens of msec packet loss, LR is needed absolutely.
[luw] What is the base of this conclusion? Even RFC[5714] itself admits that it cannot guarantee 100% coverage.

Other point, when you talk about current mechanism of LSP ack mechanism in current IGPs (paragraph 3) that involves control plane and so slow down the network wide convergence, you are right (purely theorically) but this is clearly necessary I think. It would be bad if you start flooding corrupted information network wide ...
[luw] Were you talking about paragraph 3 under "Introduction"? That paragraph simply says "if only others know our situations...".

Some vendors like CISCO already implements some fast-flooding mechanism not in the same way you propose, but that can theorically permit to save some extra computation on nodes.
[luw] I'm not familiar with that.

Other point, how are you planning to manage churn of events with your framework ? There is still a need like in most IGP to slowdown event propagation in case of churn. Fastconvergence is good for a single event, but you still need to adapt to churn and slowing down convergence to prevent life of you nodes :)
[luw] Quite opposite. The curent IPFRR solutions will incur lot of work on the affected routers. It takes lots of churns for the network to recover from the events and become ready for the next hit.

Last point, is that here you deal only with IGP convergence, but on a node which is running multiple routing protocols, an IGP event as directly an effect on other routing protocols (PIM, BGP ...). And we already saw on our network, that concurrence of protocols inside a node is a major issue for fast IGP convergence (BGP slowing down IGP convergence for example due to bad process prioritization) and here we are dependent of vendor implementations. On some router OS, there is a huge work on this with vendors.
[luw] This is a good problem to have, right? There are two choices:
      a. Forbid IGP's improvement and make PIM, BGP happy;
      b. Improve PIM, BGP ... accordingly. 
The choice is obvious.

To conclude from my point of view, I'm not sure there will be a gain in network wide convergence with your proposal.
[luw] Please note that this draft proposes a fast notification framework which aims to achieve the seamless link state synchronization. It doesn't exclude the improvement in other areas. In fact, it encourages the improvement/innovation in various areas such as control plane processing, data plane updating, and the communication between them.
Please also note that it's not our purpose to cut down the transmission delay (i.e. travelling the wire). The transmission delay cannot be cut or shortened. It is governed by the law of Physics. It can however be compensated (see section 5.2).

Best Regards,
-wenhu

Regards,

Stephane Litkowski
France Telecom

---

From: <[email-masked]>
Date: Mon, 8 Nov 2010 22:00:18 +0100

>>>Moreover I think that network wide convergence will never permit to
achieve the same level of service (in term of 
>>>packet loss) than local protection mechanism like LFA, or FRR using
MPLS TE. So if you to achieve tens of msec packet
>>>loss, LR is needed absolutely.
[luw] What is the base of this conclusion? Even RFC[5714] itself admits
that it cannot guarantee 100% coverage.

[sli] clearly with LFA you can't have 100% coverage inside a network
(except if you build it based on LFA limitations :) ) but there is some
solutions that can permit to approach the 100% coverage. But to be more
clear about what I said : protection/local repair mechanism have not the
same purpose than network wide convergence. And you will never be able
to achieve a network wide convergence with the same level of packet loss
than the one proposed by protection mechanism like TE or LFA :
basically, in protection mechanism, there is no computation involved
when the failure occurs (pre computation is done), the FIB/LFIBs are
just switching states. So both are complementary, LFA/TE are not there
to replace network wide convergence, it's just a temporary mechanism
until convergence occurs.

>>Other point, when you talk about current mechanism of LSP ack
mechanism in current IGPs (paragraph 3) that involves 
>>control plane and so slow down the network wide convergence, you are
right (purely theorically) but this is clearly
>>necessary I think. It would be bad if you start flooding corrupted
information network wide ...

[luw] Were you talking about paragraph 3 under "Introduction"? That
paragraph simply says "if only others know our situations...".

[sli] Here was the statement I was referencing : "Regular routing
protocol performs the flooding in store-and-forward
   manner.  While this is reliable (retransmission) and secure
   (adjacency check), it involves control plane operation and the
   control plane to data plane communication.  It inevitably drags the
network wide convergence"

>>Other point, how are you planning to manage churn of events with your
framework ? There is still a need like in mostIGP 
>>to slowdown event propagation in case of churn. Fastconvergence is
good for a single event, but you still need to adapt
>>to churn and slowing down convergence to prevent life of you nodes :) 

[luw] Quite opposite. The curent IPFRR solutions will incur lot of work
on the affected routers. It takes lots of churns for the network to
recover from the events and become ready for the next hit.

[sli] can you explain a bit what you mean by "It takes lots of churns
for the network to recover from the events and become ready for the next
hit." to be sure I'm undertanding correctly. If you mean than protection
mechanism are not well designed for churns, you are totally right (I
share this opinion) but some other mechanism need to be implemented (IGP
backoff, dampening ...) to limit churns. 

>>Last point, is that here you deal only with IGP convergence, but on a
node which is running multiple routing protocols, >>an IGP event as
directly an effect on other routing protocols (PIM, BGP ...). And we
already saw on our network, that >>concurrence of protocols inside a
node is a major issue for fast IGP convergence (BGP slowing down IGP
convergence for >>example due to bad process prioritization) and here we
are dependent of vendor implementations. On some router OS, >>there is a
huge work on this with vendors.
[luw] This is a good problem to have, right? There are two choices:
      a. Forbid IGP's improvement and make PIM, BGP happy;
      b. Improve PIM, BGP ... accordingly. 
	The choice is obvious.
[sli] Yes clearly !!

Regards,

Stephane

---

From: Wenhu Lu <[email-masked]>
Date: Mon, 8 Nov 2010 18:32:41 -0500

Hi Stephane,
Please see my comments inline [luw2]. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, November 08, 2010 1:00 PM
To: [email-masked]
Subject: RE: Review request for draft-lu-fast-notification-framework-00.txt

[sli] clearly with LFA you can't have 100% coverage inside a network (except if you build it based on LFA limitations :) ) but there is some solutions that can permit to approach the 100% coverage. But to be more clear about what I said : protection/local repair mechanism have not the same purpose than network wide convergence. And you will never be able to achieve a network wide convergence with the same level of packet loss than the one proposed by protection mechanism like TE or LFA :
basically, in protection mechanism, there is no computation involved when the failure occurs (pre computation is done), the FIB/LFIBs are just switching states. So both are complementary, LFA/TE are not there to replace network wide convergence, it's just a temporary mechanism until convergence occurs.
[luw2] Exactly, it's a temporary workaround. As good as IETF, IMHO we shouldn't settle on workaround and not seeking excellence. I understand and agree with you that by now most other solutions do not switch as crispy as LFA does. But I dare not say never.

[sli] Here was the statement I was referencing : "Regular routing protocol performs the flooding in store-and-forward
   manner.  While this is reliable (retransmission) and secure
   (adjacency check), it involves control plane operation and the
   control plane to data plane communication.  It inevitably drags the network wide convergence"
[luw2] Here the point is to skip the middle-men's store-and-forward.

[sli] can you explain a bit what you mean by "It takes lots of churns for the network to recover from the events and become ready for the next hit." to be sure I'm undertanding correctly. If you mean than protection mechanism are not well designed for churns, you are totally right (I share this opinion) but some other mechanism need to be implemented (IGP backoff, dampening ...) to limit churns. 
[luw2] I was referring: one of current IPFRR solutions requires after the topology change, "m" SPFs on multiple routers in the network, where "m" is the number of neighbors (can be fewer).
Regards,
-wenhu

>>Last point, is that here you deal only with IGP convergence, but on a
node which is running multiple routing protocols, >>an IGP event as directly an effect on other routing protocols (PIM, BGP ...). And we already saw on our network, that >>concurrence of protocols inside a node is a major issue for fast IGP convergence (BGP slowing down IGP convergence for >>example due to bad process prioritization) and here we are dependent of vendor implementations. On some router OS, >>there is a huge work on this with vendors.
[luw] This is a good problem to have, right? There are two choices:
      a. Forbid IGP's improvement and make PIM, BGP happy;
      b. Improve PIM, BGP ... accordingly. 
	The choice is obvious.
[sli] Yes clearly !!

Regards,

Stephane