Subject: I-D Action: draft-ietf-rtgwg-ordered-fib-07.txt

From: [email-masked]
Date: Fri, 07 Sep 2012 10:40:57 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Routing Area Working Group Working Group of the IETF.

	Title           : Loop-free convergence using oFIB
	Author(s)       : Mike Shand
                          Stewart Bryant
                          Stefano Previdi
                          Clarence Filsfils
                          Pierre Francois
                          Olivier Bonaventure
	Filename        : draft-ietf-rtgwg-ordered-fib-07.txt
	Pages           : 25
	Date            : 2012-09-07

Abstract:
   This document describes a mechanism for use in conjunction with link
   state routing protocols which prevents the transient loops which
   would otherwise occur during topology changes.  It does this by
   correctly sequencing the forwarding information base (FIB) updates on
   the routers.

   This mechanism can be used in the case of non-urgent link or node
   shutdowns and restarts or link metric changes.  It can also be used
   in conjunction with a fast re-route mechanism which converts a sudden
   link or node failure into a non-urgent topology change.  This is
   possible where a complete repair path is provided for all affected
   destinations.

   After a non-urgent topology change, each router computes a rank that
   defines the time at which it can safely update its FIB.  A method for
   accelerating this loop-free convergence process by the use of
   completion messages is also described.

   The technology described in this document has been subject to
   extensive simulation using real network topologies and costs, and
   pathological convergence behaviour.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-ordered-fib

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-rtgwg-ordered-fib-07

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-rtgwg-ordered-fib-07

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Saku Ytti <[email-masked]>
Date: Sat, 8 Sep 2012 11:35:27 +0300

I'm confused.

'2. Introduction' says this:
---
The mechanisms that are used in the
   failure case are exactly the same as those used for managed changes.
   For simplicity this document makes no further distinction between
   managed and unplanned changes.
---

Does this imply, this is as useful in failure cases as it is in
managed changes?

I understand why it would be useful in managed changes such as metric
changes or artificially delayed interface shut. But I don't understand
how this can do any good in unmanaged change.

Domestically my network is 5ms long, it takes me 10ms on fastest
available modern route engine to calculate SPF change. I flood LSP
immediately before calculating SFP. So before I've finished
calculating SPF on local-to-fault router, furthest domestic node has
already been busy calculating it it for 5ms and is 5ms from finishing
it?
Non-domestic routers would not cause loop,, regardless or not if
they've changed FIB.

Wouldn't I double my delay, in the best scenario? As I'm waiting for
permission to update my FIB and I'm bound by network delay not only to
propagate LSP from up->down but to propagate permissions from
down->up?
So essentially I'm trading short transient loop to significantly
longer packet loss (remember, using the old topology will cause packet
loss, as link is already down).

I'm probably not understanding this right. If this feature should also
provide help in failure cases, would it be possible to have step by
step description for both cases normal and oFIB? In terms of what
happens millisecond to millisecond? (In same topology, where each link
has described millisecond, each router described time to calculate SPF
and each router described time to update FIB after SPF).

Thanks,
On 7 September 2012 20:40,  <[email-masked]> wrote:
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

-- 
  ++ytti

---

From: Stewart Bryant <[email-masked]>
Date: Sun, 09 Sep 2012 20:45:23 +0100

Saku

The expected use of this technology in the failure case
is in conjunction with IPFRR where following a protected
failure, and in the absence of a convergence control
technology, microloops may form and/or the repair
may be staved.

Note not only do you need to learn of the failure
and compute the new SPF, you also need to update the
FIB. The FIB update time can be the dominant factor in
re-convergence.

- Stewart

-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Saku Ytti <[email-masked]>
Date: Mon, 10 Sep 2012 15:58:41 +0300

> technology, microloops may form and/or the repair

If failure cannot be IPFRR protected, conventional FIB insertion would be used?

> FIB. The FIB update time can be the dominant factor in

Yes, certain modern chassis based L3 switch can literally take >hour
in real network to update its FIB.

I once thought of sending commit-to-FIB absolute time in TLV in LSP
(Router NTP can give 500us precision easily). But maybe that wouldn't
be deterministic enough. In oFIB I fear that FIB delay in devices I'd
actually want to use in practical scenarios are less than my
linkdelays, so signalling would just reduce convergence time.

-- 
  ++ytti

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 10 Sep 2012 17:24:58 +0100

> If failure cannot be IPFRR protected, conventional FIB insertion would be used?

Yes.

> in real network to update its FIB.
If the platform takes hour you definately need IPFRR.
> linkdelays, so signalling would just reduce convergence time.
Have you looked at the loop free convergence framework?

This was an idea we considered in the early days we called
it synchronized FIB.

- Stewart

---

From: Allwyn Carvalho <[email-masked]>
Date: Mon, 10 Sep 2012 14:12:16 -0700

In the following:

--- start ---

For example, in Figure 1, if the link between X and Y is shut down by
an operator, packets destined to X can loop between R and Y when Y
has updated its FIB while R has not yet updated its FIB, and packets
destined to Y can loop between X and S if X updates its FIB before S.
According to the current behaviour of ISIS and OSPF, this scenario
will happen most of the time because X and Y are the first routers to
be aware of the failure, so that they will update their FIBs first.

1
X-------------/-------------Y
| |
| |
| |
| |
1 | | 1
| |
| |
| |
| |
S---------------------------R
2

Figure 1: A simple topology

--- end ---

I guess you are talking about packets originating at R and
going to X.  Y should not use R as a loop-free alternative because it
is not "downstream".  Cost (R,X) > Cost (Y,X).  Y does not have loop
free alternative to X.  So, yes, there will be packet loss until
convergence, but at least there should be no micro-loops.

Allwyn.

Stewart Bryant wrote:

Saku

- Stewart

I'm confused.

Thanks,

Abstract:

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 10 Sep 2012 22:52:51 +0100

On 10/09/2012 22:12, Allwyn Carvalho wrote:
> In the following:
>
> --- start ---
>
>     For example, in Figure 1,
Please look at this text:
> if the link between X and Y is shut down by
>     an operator,
There is no IPFRR here, it is an ordinary management action.
> packets destined to X can loop between R and Y when Y
> I guess you are talking about packets originating at R and going to 
> X.  Y should not use R as a loop-free alternative because it is not 
> "downstream".  Cost (R,X) > Cost (Y,X).  Y does not have loop free 
> alternative to X.  So, yes, there will be packet loss until 
Please see above.

The packets originate at R, or arrive at R via some un-shown network 
fragment.

- Stewart
>>> On 7 September 2012 20:40,<[email-masked]>  wrote:
>>>      
>>>> Internet-Draft directories:http://www.ietf.org/shadow.html
>>>> orftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>>>        
>>>      
>>
>>
>>