Subject: Adopting draft-francois-ordered-fib-00.txt as a WG document

From: Olivier Bonaventure <[email-masked]>
Date: Mon, 21 Nov 2005 22:17:28 +0100

Dear All,

We would like to propose to consider draft-francois-ordered-fib-00.txt
as a working group document. This draft was presented in Paris and no
objections were raised. It proposes techniques to order the FIB updates
in an IP network using a link state routing protocol to avoid transient
forwarding loops. We believe that this draft is important for the fast
reroute work done within this WG, but also as a standalone document.
Measurements performed in IP networks show that planned topology changes
are very common. For example, [1] reports that in the Sprint network,
20% of the topology changes are due to maintenance operations. We
discussed this issue with several ISPs that confirmed that correctly
handling the non-urgent topology changes was an important problem to be
solved.

You can find the current version of the draft on the IETF web site
http://www.ietf.org/internet-drafts/draft-francois-ordered-fib-00.txt

[1] Athina Markopoulou and Gianluca Iannaccone and Supratik
Bhattacharyya and Chen-Nee Chuah and Christophe Diot (2004).
Characterization of Failures in an IP Backbone.
In: IEEE Infocom. Hong Kong. March 2004.
http://ipmon.sprint.com/pubs_trs/trs/failure-characterization.pdf

Best regards,

Olivier Bonaventure

-- 
CSE Dept. UCL, Belgium - http://www.info.ucl.ac.be/people/OBO/

_______________________________________________
Rtgwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rtgwg

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 21 Nov 2005 16:53:07 -0500

I am really uncomfortable with changing the general convergence behavior of 
the routing protocols to handle the case when the human knows he will shut 
things down.  If this were only triggered by a special advertisement that 
indicated orderly shutdown, that might be less bothersome.
Particularly, it seems strange to be talking about slowing convergence when 
we are repeatedly being asked to speed up convergence.
Yours,
Joel M. Halpern

---

From: Olivier Bonaventure <[email-masked]>
Date: Mon, 21 Nov 2005 23:01:49 +0100

Joel,

> I am really uncomfortable with changing the general convergence behavior
> of the routing protocols to handle the case when the human knows he will
> shut things down.  If this were only triggered by a special
> advertisement that indicated orderly shutdown, that might be less
> bothersome.

Of course, the ordered FIB update would only be used for non-urgent
topology changes. Those topology changes include :
- link up event (all link up events are non-urgent)
- metric change event (going up or going down - all metric changes are
non-urgent)
- manual shutdown of a link (could be explicitely indicated by first
setting the metric to almost infinity and later removing the link)
- failure of a link which is protected by a fast reroute protection
technique (again, if the link is protected, then its metric can be set
to a large value)

> Particularly, it seems strange to be talking about slowing convergence
> when we are repeatedly being asked to speed up convergence.

Note that with the completion messages described in the draft, the
convergence time can be reasonable. Our simulations indicate that
sub-second ordered convergence is possible with completion messages.
These simulations are not yet published, but if there is some interest
we could prepare a short technical with our findings.

Olivier

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 21 Nov 2005 17:19:19 -0500

Remember that "protected by a fast reroute protection technique" may be on 
a prefix by prefix basis (protected for some, but not for others) and may 
be hard to determine.

If this were restricted to
o link up
o metric change
then I would not be as uncomfortable.  Those are indeed generally cases 
where care is more important than speed.

Yours,
Joel M. Halpern

PS: Orderly shutdown would then be a manual metric change followed later (a 
few seconds later would suffice) by abrupt removal.

---

From: Olivier Bonaventure <[email-masked]>
Date: Mon, 21 Nov 2005 23:30:02 +0100

Joel,

> Remember that "protected by a fast reroute protection technique" may be
> on a prefix by prefix basis (protected for some, but not for others) and
> may be hard to determine.

Agreed, this depends on the type of protection technique. A link should
be marked as protected only if all the destinations are protected.

> PS: Orderly shutdown would then be a manual metric change followed later
> (a few seconds later would suffice) by abrupt removal.

Would you agree if section 2 of the draft was updated and link down
events were removed and only the following events were supported :
- metric change
- link up
- router down and router up (overload bit transition in ISIS)

This would mean that if a router wants to either supports graceful
manual link shutdown or graceful shutdown of fully protected link, it
should first advertise the considered link with a very large metric and
later remove it from its link state packet.

Olivier

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 21 Nov 2005 17:34:45 -0500

If by router up/down you mean only the case of the overload bit changing, then
yes, if section two states those listed cases are the applicable events I 
would agree.
I would understand the value and the behavioral tradeoff.

Yours,
Joel

---

From: Alia Atlas <[email-masked]>
Date: Mon, 21 Nov 2005 16:00:55 -0800

Olivier,

Could you outline the changes to the proposal since we discussed it in
detail last year?
I believe that the same objections were raised to it in Paris as came
out of the design team discussion.  Certainly, I believe that I voiced
the same concerns.  These related to the much larger convergence time,
the amount of additional signaling and the clear handling of SRLGs &
nodes.  In addition, a clear algorithm for the computation would be
useful.

I can certainly see some uses for the maintenance (link up or metric
change) related events.  The signaling part could use more details and
discussion of the dynamics.

Alia

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 22 Nov 2005 08:02:32 +0000

Joel M. Halpern wrote:

> I am really uncomfortable with changing the general convergence 
> behavior of the routing protocols to handle the case when the human 
> knows he will shut things down.  If this were only triggered by a 
> special advertisement that indicated orderly shutdown, that might be 
> less bothersome.
Please can we be clear that PLSN (which is of course a WG draft)
has very similar properties -

1) It slows convergence to some extent (with as far as I can see
- no mechanism to use signalling to accelerate)

2) Needs to be applied to all routers in the network

It therefore changes the convergence properties of the whole
network, but it does not provide complete protection against
all loops.

If we have doubts as to whether we wish to change the convergence
process,  maybe we should put the PLSN draft on hold?

Convergence dynamics can be safely modified when we are sure that
that all traffic will continue to be safely delivered during the
process. This is true IFF the old path is still functional or
when ALL traffic that was previously using  it is protected.

- Stewart

---

From: Alia Atlas <[email-masked]>
Date: Tue, 22 Nov 2005 00:18:09 -0800

> - no mechanism to use signalling to accelerate)

true, but we are having discussions on how to handle the case where
there isn't an alternate. The added delay is substantially less than
what the Ordered FIB install would provide.  This affects the window
of vulnerability to another event happening.

> 2) Needs to be applied to all routers in the network

If one is looking for as full micro-loop protection as possible, then
it needs to be applied to all routers in the network.  It is, however,
very possible to do limited deployments and safely see the effects. 
Deploying PLSN on a router affects that router & its neighbors.  It's
more limited.  I don't see a similar incremental
deployment/functionality scenario with Ordered FIB.

> process,  maybe we should put the PLSN draft on hold?

Didn't we have this discussion a year ago?  What has changed?  Is it that you
have a greater level of confidence/understanding/experience with Ordered FIB?
Is it that because this is being proposed for maintenance, that the rather long
(diameter of the network x FIB install-time) convergence delays seem acceptable?
Is it that you've got a clearly written and articulated algorithm &
signaling changes
that consider the various corner cases?  Is it that you feel this is a
better complement
to not-via than PLSN & you only want to see one deployed?

Without new/additional information, I think this is going to head the same way
that the previous discussions have.  Could you provide a bit more insight into
your reasoning?

Alia

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 22 Nov 2005 08:57:35 +0000

>of vulnerability to another event happening.
Signaling will remove all but essential delays.

>deployment/functionality scenario with Ordered FIB.
You could do the same limited deployment with oFIB, with similar results.

>Didn't we have this discussion a year ago?  What has changed? 
>
Joel raised concerns about changing the convergence process. I am
simply pointing out that PLSN also changes the convergence process.

- Stewart

> Is it that you

---

From: Olivier Bonaventure <[email-masked]>
Date: Tue, 22 Nov 2005 22:00:07 +0100

Alia,
> the same concerns.  These related to the much larger convergence time,

As I said to Joel, Pierre François did simulations with the completion
messages on real ISP topologies and his simulations show that sub-second
ordered convergence is possible. If the WG is interested by such
simulation results, we could write a short technical report and make it
available. I don't think that an IETF draft would be the best place to
report simulation results.

> the amount of additional signaling 

The completion messages are used to speed up the convergence. Each
router sends at most one completion message per link. This is not a
significant amount of signalling.

> and the clear handling of SRLGs

There are two types of SRLG to consider :
- SRLGs were all links are attached to a router, such as line card
up/down. In this case, the ordered FIB update can be used as a single
message is sufficient to describe the SRLG change
- SRLGs with links attached to different routers. In this case, we can
find an ordering for N common link downs and N common link up events
together. However, the main issue with such types of events is that
routers will not flood their link state packets describing the SRLG
change exactly at the same time. This is a common problem to all
solutions that have to deal with SRLG events. There are two possible
approaches :
1. Wait until all link state packets corresponding to the SRLG have been
received
2. Consider that, as soon as one event with an SRLG has been received,
all the links of the SRLG have the same event

I would suggest that to handle events with links attached to different
routers, a safe approach would be to consider such events as an urgent
failure and not apply an ordering.

> &
> nodes.  

For the nodes, the document describes how to support router up and
router down events (aka overload bit transitions in ISIS)

In addition, a clear algorithm for the computation would be
> useful.

We can update this part if you believe that it is not clear enough.

> change) related events.  The signaling part could use more details 

I think that the draft would be useful for maintenance operations
independently of the fast reroute work being done in this WG. Concerning
the signaling part, we would need to write a specific draft for IS-IS
and another one for OSPF. I guess those drafts should be submitted to
the isis and ospf working groups.

> and discussion of the dynamics.

Could you elaborate what you mean by dynamics ?

Thanks for your comments

Olivier