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

[Allwyn Carvalho <[e-mail]>]

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

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



On 08/09/2012 09:35, Saku Ytti wrote:
  

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,  <[e-mail]> wrote:
    

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" rel="nofollow">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" rel="nofollow">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" rel="nofollow">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/" rel="nofollow">ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/i-d-announce" rel="nofollow">https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html" rel="nofollow">http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt" rel="nofollow">ftp://ftp.ietf.org/ietf/1shadow-sites.txt