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

[Stewart Bryant <[e-mail]>]

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
>     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.
Please see above.

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

- Stewart
>
> 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
>>>>
>>>> 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
>>>> orftp://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