Subject: draft-shand-ipfrr-framework-00.txt as a WG document

From: Alex Zinin <[email-masked]>
Date: Fri, 21 May 2004 23:28:09 -0700

Folks-

 Mike wrote the first draft of the IP FRR framework that was mentioned earlier.
 I've reviewed the draft, believe that it is very well written, and serves the
 purpose as the basis for the corresponding work item. I suggest that this
 document becomes a WG item with Mike as the editor.

 Please send your comments within two weeks (by June 4th, 2004.)

-- 
Alex
http://www.psg.com/~zinin/

This is a forwarded message
From: [email-masked] <[email-masked]>
To: [email-masked]
Cc: 
Date: Friday, May 21, 2004, 12:49:42 PM
Subject: I-D ACTION:draft-shand-ipfrr-framework-00.txt

===8<==============Original message text===============
A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: IP Fast Reroute Framework
	Author(s)	: M. Shand
	Filename	: draft-shand-ipfrr-framework-00.txt
	Pages		: 8
	Date		: 2004-5-21
	
This document provides a framework for the development of IP fast re-
   route mechanisms which provide protection against link or router
   failure by invoking locally determined repair paths. Unlike MPLS
   Fast-reroute, the mechanisms are applicable to a network employing
   conventional IP routing and forwarding. An essential part of such
   mechanisms is the prevention of packet loss caused by the loops which
   normally occur during the re-convergence of the network following a
   failure.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-shand-ipfrr-framework-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-shand-ipfrr-framework-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-shand-ipfrr-framework-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

===8<===========End of original message text===========

ENCODING mime
FILE /internet-drafts/draft-shand-ipfrr-framework-00.txt

---

From: "Howard C. Berkowitz" <[email-masked]>
Date: Sat, 22 May 2004 14:00:58 -0400

>  Please send your comments within two weeks (by June 4th, 2004.)

A very nice piece of work, Mike.

Now, some general and very prelimimary comments.   I would suggest 
there be a management framework section in this document.  This will 
relate both to the IGP-independent aspects of fast reroute, plus 
specific implications for specific IGPs.  In the latter, we will have 
both the considerations of the MIB proper, as well as some specific 
protocol implications.

First, we may want to think of what aspects of some very fast events 
and computations reasonably can have a goal of being tracked in a 
MIB.  For example, in stages where we reasonably can expect 
micro-loops, do we expect the various tables (e.g., interface status, 
LSDB, RIB and FIB) to track the real-time status and possible 
inconsistencies, or is it adequate to add a variable that tags the 
appropriate element(s) in all of these "fast reroute in progress"?

As something of an aside, we might want to look at the FORCES model, 
as well as some of the control vs. forwarding plane convergence work 
in BMWG, so that we have consistent terminology for the status of 
various events.  This is a place to look at Mike's Section 2.

Current MIBs, and indeed protocols, emphasize the hello mechanism as 
the means of failure detection.  We need to have an abstraction of 
failure status, quite likely IGP-specific, that says up/down (plus 
possibly a "in transition" value), which abstracts both hardware and 
software (IGP hellos, liveliness protocols, etc.) up/down perspective.

Second, some of the things we currently track, such as missed hellos, 
may need to be optional if  we rely on hardware link failure 
detection.  Alternatively,hello tracking may continue to be mandatory 
for some functions, such as neighbor discovery and dead router 
detection, but optional for link failure detection.  I suspect that 
this will take some rethinking of the MIB, of capabilities 
negotiation between neighbors and dead router detection. Even if we 
have a hardware failure detection mechanism, we will still need 
hellos for neighbor discovery and mutual recognition.

IGPs, however, need to constrain their current MIB generalization of 
the use of hellos. We need to have a status mechanism that allows 
hello mechanisms to be bypassed. ospfIfRtrDeadInterval, for example, 
is not necessarily meaningful in a situation where the primary 
reliance is on hardware detection.  It may be meaningful if we rely 
on it to tell us when a router is taken out of service, a more 
general event than a link failure. Consider, though, a case when we 
need to know about a dead router faster than we might learn from a 
dead timer. There might need to be either some additional protocol 
messages, or possibly SNMP traps that are signaled to the IGP, when a 
routing process is shut down.

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

---

From: [email-masked]
Date: Sun, 23 May 2004 23:31:32 +0200

hi mike, all,

this is a good start, a concise document going to be point; some early 
comments here below:

(1) section 2

1. The time taken to detect the failure. This may be of the order
    of a few mS when it can be detected at the physical layer, up to
    several tens of seconds when a routing protocol hello is
    employed. During this period packets will be unavoidably lost.

2. The time taken for the local router to react to the failure.
    This will typically involve generating and flooding new routing
    updates, and re-computing the router's FIB.

-> is there no waiting for transient flaps (false alarms) and some
waiting time before sending out updates considered ?

3. The time taken to pass the information about the failure to
    other routers in the network. In the absence of routing protocol
    packet loss, this is typically between 10mS and 100mS per hop in
    a well designed router.

  [...]

(2) section 3.1 - Mechanisms for fast failure detection

it would appropriate to propose the following classification:
- physical detection data plane loss of signal/loss of light
- non-associated protocol detection (BFD)
- associated routing protocol detection (Hellos)

note that the media dependent detection will be there independently of 
the additional media independent/generic BFD but their applicability as 
trigger may vary wrt to the different network environments commonly 
considered: P2P, (P2MP,) and BA

it is also worth noticing that having a mechanism like BFD elevates the 
issue of non-homogeneous physical behaviour of both side of the links, 
i'd like to make this clearer compared to methods like MPLS FRR

(3) Section 3.1 - advisable to include appropriate references to the 
numbers of provided for the applicability of each method (if it is an 
evaluation performed in the scope of the document, corresponding 
reasoning could be included)

(4) Section 3.2.2 concerning the discussions on link versus node 
protection - Discussion about multiple adjacencies b/w two nodes
should be also covered nodes

(5) Processing in case of failure of the loop free alternates, since 
the failure probability of the alternates should not be different from 
the failure probability of the primary path(s)

(6) Editorial comments

- from the introduction "This is analogous to the technique employed by 
MPLS Fast Reroute [MPLSFRR], but the mechanisms employed for the backup 
routes in pure IP networks are necessarily very different." i don't 
perceive the real intent of this sentence

- section 3.3  "A number of solutions to the problem of micro-loop 
formation have been proposed." would you provide some material/ref's ?

thanks for the clarifications,
- dimitri.

---

-- 
Papadimitriou Dimitri
E-mail : [email-masked]
E-mail : [email-masked]
Webpage: http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491

---

From: mike shand <[email-masked]>
Date: Mon, 24 May 2004 09:10:10 +0100

>waiting time before sending out updates considered ?

Yes, that's true. In one sense these are artificially imposed delays which 
can be lowered in the search for rapid convergence, as opposed to 
fundamental limitations. However, it would do no harm to mention them.

>- associated routing protocol detection (Hellos)

Yes. that is more abstract.

>note that the media dependent detection will be there independently of the 
>additional media independent/generic BFD but their applicability as 

Of course.

>issue of non-homogeneous physical behaviour of both side of the links, i'd 
>like to make this clearer compared to methods like MPLS FRR

Not quite sure what you mean here. Do you mean that use of BFD on both ends 
of the link is more likely to result in de-synchronized triggers (which I 
don't think would necessarily be true), or do you mean that one end may use 
BFD and the other not. Or do you mean something else?

>evaluation performed in the scope of the document, corresponding reasoning 
>could be included)

Sorry, I'm confused again. Are you referring to the 80% and 95% numbers in 
section 3.2? Those numbers (or an approximation of them) come from Alia's 
presentation, but they are supported by my own simulations of real world 
networks.

>should be also covered nodes

Sorry, I don't understand. Do you mean something like the material covered 
in section 4.6.2 of

http://www.ietf.org/internet-drafts/draft-bryant-ipfrr-tunnels-00.txt

Although that is explicitly the ECMP case. You could have parallel links 
with different costs (why I don't know).

>(5) Processing in case of failure of the loop free alternates, since the 
>failure probability of the alternates should not be different from the 
>failure probability of the primary path(s)

Again, could you expand on that please?

>perceive the real intent of this sentence

It was to give readers an idea that the concept of rapidly switching to a 
pre-computed backup path was similar to something with which they are 
familiar (i.e. MPLS FRR), but pointing out that the way the backup paths is 
computed is very different.

>formation have been proposed." would you provide some material/ref's ?

See section 6 of

http://www.ietf.org/internet-drafts/draft-bryant-ipfrr-tunnels-00.txt

>thanks for the clarifications,

Thanks for the comments.

         Mike

---

From: mike shand <[email-masked]>
Date: Mon, 24 May 2004 09:16:43 +0100

Howard,
         I agree that we will need to consider the management/MIB 
implications, but I suspect that until we have gone down this road a little 
further we can only really put a placeholder in the framework document. 
When we have a clearer idea of where we are going (and in particular what 
mechanisms we are using to get there), we will be able to think of the 
management aspects in more concrete terms. What you say below is a good basis.

         Mike

At 14:00 22/05/2004 -0400, Howard C. Berkowitz wrote:
>Now, some general and very prelimimary comments.   I would suggest there 
>be a management framework section in this document.  This will relate both 
>to the IGP-independent aspects of fast reroute, plus specific implications 
>for specific IGPs.  In the latter, we will have both the considerations of 
>the MIB proper, as well as some specific protocol implications.
>
>First, we may want to think of what aspects of some very fast events and 
>computations reasonably can have a goal of being tracked in a MIB.  For 
>example, in stages where we reasonably can expect micro-loops, do we 
>expect the various tables (e.g., interface status, LSDB, RIB and FIB) to 
>track the real-time status and possible inconsistencies, or is it adequate 
>to add a variable that tags the appropriate element(s) in all of these 
>"fast reroute in progress"?
>
>As something of an aside, we might want to look at the FORCES model, as 
>well as some of the control vs. forwarding plane convergence work in BMWG, 
>so that we have consistent terminology for the status of various 
>events.  This is a place to look at Mike's Section 2.
>
>Current MIBs, and indeed protocols, emphasize the hello mechanism as the 
>means of failure detection.  We need to have an abstraction of failure 
>status, quite likely IGP-specific, that says up/down (plus possibly a "in 
>transition" value), which abstracts both hardware and software (IGP 
>hellos, liveliness protocols, etc.) up/down perspective.
>
>Second, some of the things we currently track, such as missed hellos, may 
>need to be optional if  we rely on hardware link failure 
>detection.  Alternatively,hello tracking may continue to be mandatory for 
>some functions, such as neighbor discovery and dead router detection, but 
>optional for link failure detection.  I suspect that this will take some 
>rethinking of the MIB, of capabilities negotiation between neighbors and 
>dead router detection. Even if we have a hardware failure detection 
>mechanism, we will still need hellos for neighbor discovery and mutual 
>recognition.
>
>IGPs, however, need to constrain their current MIB generalization of the 
>use of hellos. We need to have a status mechanism that allows hello 
>mechanisms to be bypassed. ospfIfRtrDeadInterval, for example, is not 
>necessarily meaningful in a situation where the primary reliance is on 
>hardware detection.  It may be meaningful if we rely on it to tell us when 
>a router is taken out of service, a more general event than a link 
>failure. Consider, though, a case when we need to know about a dead router 
>faster than we might learn from a dead timer. There might need to be 
>either some additional protocol messages, or possibly SNMP traps that are 
>signaled to the IGP, when a routing process is shut down.
>

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 24 May 2004 10:25:45 +0100

> waiting time before sending out updates considered ?

Yes, but this was taken to be a component of (1) above.

> i'd like to make this clearer compared to methods like MPLS FRR

I do not understand this statement. In particular I do not see why
there is any difference between the BFD failure detection in an IP
system vs an MPLS system.

> reasoning could be included)

I assume that you mean the detection latency. That is highly dependent
on the media, the netwoek and the implementation.

> should be also covered nodes

Isn't this covered by 3.2.2 item 1 which says that the IPFRR path must
not transit the failure? If you are doing node protection you have
to exclude all links to the failed node.

> failure probability of the primary path(s)

I do not understand this comment.

> perceive the real intent of this sentence

To say that IPFRR is conceptually similar to MPLS FRR as far a preplanning
the repair, having fast detection and fast local invocation of FRR with
communicating with other nodes at the time of failure, BUT the absence of
the circuit switching mode that MPLS has (because source routing is not
implemented in the IP fast path) means that we have to use alternative
methods to force the packet along the repair path.

> formation have been proposed." would you provide some material/ref's ?

Some of the techniques are described in draft-bryant-ipfrr-tunnels-00.txt
which.

- Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 24 May 2004 11:04:56 +0100

mike shand wrote:

> implications, but I suspect that until we have gone down this road a 
> little further we can only really put a placeholder in the framework 
> document. When we have a clearer idea of where we are going (and in 
> particular what mechanisms we are using to get there), we will be able 
> to think of the management aspects in more concrete terms. What you say 
> below is a good basis.
> 
>         Mike
> 

Don't forget that we need to consider both the management of IPFRR and the
use of loop-free in the management of the network.

- Stewart

>> this will take some rethinking of the MIB, of capabilities negotiation 
>> between neighbors and dead router detection. Even if we have a 
>> hardware failure detection mechanism, we will still need hellos for 
>> neighbor discovery and mutual recognition.
>>
>> reliance is on hardware detection.  It may be meaningful if we rely on 
>> it to tell us when a router is taken out of service, a more general 
>> event than a link failure. Consider, though, a case when we need to 
>> know about a dead router faster than we might learn from a dead timer. 
>> There might need to be either some additional protocol messages, or 
>> possibly SNMP traps that are signaled to the IGP, when a routing 
>> process is shut down.
>>

---

From: [email-masked]
Date: Mon, 24 May 2004 13:17:36 +0200

hi mike,

mike shand wrote:
> Yes, that's true. In one sense these are artificially imposed delays 
> which can be lowered in the search for rapid convergence, as opposed to 
>> the additional media independent/generic BFD but their applicability 
>> as trigger may vary wrt to the different network environments commonly 
>> it is also worth noticing that having a mechanism like BFD elevates 
>> the issue of non-homogeneous physical behaviour of both side of the 
>> links, i'd like to make this clearer compared to methods like MPLS FRR
> 
> Not quite sure what you mean here. Do you mean that use of BFD on both 
> ends of the link is more likely to result in de-synchronized triggers 
> (which I don't think would necessarily be true), or do you mean that one 
> end may use BFD and the other not. Or do you mean something else?

i mean that usage of BFD is a clear improvment compared to mechanisms 
that rely only data plane failure detection that do not guarantee that 
both sides would react in the same in case of failure, here there is an 
opportunity to make the design more robust from this perspective, it is 
also possible to explicit the sequence that could happen (since physical 
detection and loss of adjacency will occur)

> Sorry, I'm confused again. Are you referring to the 80% and 95% numbers 
> in section 3.2? Those numbers (or an approximation of them) come from 
> Alia's presentation, but they are supported by my own simulations of 
> real world networks.

yes this is what i meant by adding the references

> Sorry, I don't understand. Do you mean something like the material 
> covered in section 4.6.2 of
> 

sorry for the typo in the above sentence, i was referring to the 
discussion concerning multiple adjacencies b/w two nodes

> with different costs (why I don't know).

yes - it is a generic 4.6.2 (sub-case 1) case - as an another example 
one may point out to (and subsequent):
<http://www.nanog.org/mtg-0202/ppt/isis/sld038.htm>

and it would be advisable to have a (small) discussion upon the tradeoff 
between making them "invisible" wrt to capacity of loop free alternates 
computation

> Again, could you expand on that please?

document focuses on pre-computation of alternates for the primary path 
in case of failure, it doesn't say anything related to the maintenance 
of these alternates

>> (6) Editorial comments
>>
>> - from the introduction "This is analogous to the technique employed 
>> by MPLS Fast Reroute [MPLSFRR], but the mechanisms employed for the 
>> backup routes in pure IP networks are necessarily very different." i 
>> don't perceive the real intent of this sentence 
> 
> It was to give readers an idea that the concept of rapidly switching to 
> a pre-computed backup path was similar to something with which they are 
> familiar (i.e. MPLS FRR), but pointing out that the way the backup paths 
> is computed is very different.

ok

> http://www.ietf.org/internet-drafts/draft-bryant-ipfrr-tunnels-00.txt

ok

thanks (if there are points that are still unclear please let me know)
- dimitri.

---

From: mike shand <[email-masked]>
Date: Mon, 24 May 2004 12:42:43 +0100

At 13:17 24/05/2004 +0200, [email-masked] wrote:
>i mean that usage of BFD is a clear improvment compared to mechanisms that 
>rely only data plane failure detection that do not guarantee that both 
>sides would react in the same in case of failure, here there is an 

I would anticipate that most IPFRR implementations would use a combination 
of physical (Loss of light etc.) and BFD and trigger on whichever gave the 
first indication of failure.

Note that I would expect the repair paths to be invoked immediately, but 
that the announcement of the failure in the IGP would be held down in case 
the link came back quickly. Simply invoking repair is much less disruptive 
than reconverging the network, although it will introduce potential packet 
misordering and jitter, so should not be invoked gratuitously.

What I am saying is that with IPFRR, while we should  be careful to avoid 
false indications of failure, the consequences of a false indication are 
rather less than in the conventional case, and so we can perhaps afford to 
sail a little closer to the wind.

>>Alia's presentation, but they are supported by my own simulations of real 
>>world networks.
>

OK.

>yes - it is a generic 4.6.2 (sub-case 1) case - as an another example one 
>may point out to (and subsequent):

Yes such information hiding is standard practise, but I don't think it 
matters here because (depending on the level of abstraction at which you 
view it), the local router which detects the failure does have the 
information about the potential multiple paths even though it has chosen 
not to advertise those links in its LSP/As.

There is a LOT of such detailed discussion which COULD be included in the 
framework, but my initial brief was to keep it very concise. I therefore 
omitted such material from the first draft. We need to decide as a WG 
whether we want to keep the framework in that style, or whether we want to 
make it a comprehensive treatise on every aspect of the subject.  i.e. 
which are the important aspects.

>document focuses on pre-computation of alternates for the primary path in 
>case of failure, it doesn't say anything related to the maintenance of 
>these alternates

Yes. That's an omission. Alex has already mentioned that to me. There are 
(at least) two things which need to be mentioned:

1) Once you have invoked repair paths, when do you stop using them? The 
simple answer is when they are no longer needed because the network has 
reconverged and no traffic is being directed towards them.

2) When do you recompute new repair paths? Again you do this when the 
network has reconverged. There is no particular hurry to perform these 
computations (which could be extensive) and so they would typically be 
performed as a background task. The only important factor (and perhaps what 
you were alluding to with your first comment) is that until you have 
completed this recomputation you are exposed to a "second" failure 
occurring in the network.