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,<[email protected]> 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
[email protected]
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
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
