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

[Stewart Bryant <[e-mail]>]

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
>>
>> 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/
>>
>> _______________________________________________
>> I-D-Announce mailing list
>> [e-mail]
>> 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
>
>


-- 
For corporate legal information go to:

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