Re: [Pce] Virtual Network Topology (VNT) changes and IP layer routingloops

[Olivier Bonaventure <[e-mail]>]

Don,
>>-----Original Message-----
>>From: Greg Bernstein [mailto:[e-mail]] 
>>
>>Hi Don, I'm using the term "Virtual Network Topology" related 
>>to the data plane not the control plane.  For example, when I 
>>interconnect IP routers via a WDM or SDH switching layer the 
>>resulting IP layer topology is termed a "virtual network 
>>topology" since the connectivity amongst the IP routers is 
>>not necessarily the same as the fiber topology. It is these 
>>changes to the IP layer topology that can cause the traffic 
>>disrupting micro loops.  Note that other ways that micro loops occur
>>are: (1) during IGP link weight adjustments and (2) 
>>maintenance operations.
>>
>>The connection to GMPLS/PCE is we are trying to make setting 
>>up these virtual topologies quicker and potential for traffic 
>>engineering purposes. There have been some good papers in the 
>>literature on using GMPLS and advanced algorithms for the VNT 
>>design problem.
> 
> 
> OK In as much as these topologies represent nodes and links, some how
> distributed, I would agree that: 
> 
> 1) Proactive topology changes should be dealt with in a graceful manner.

I think that everyone agrees on this. Some operators have procedures to
deal with planned link shutdowns by first setting the OSPF/ISIS weight
of those links to the maximum metric value. This is a good way to move
traffic before shutting down the link, but this technique may lead to
transient loops during the OSPF/ISIS convergence.

> One way is to have loop free alternates activated then make the topology
> changes.  

Loop free alternates have one drawback. Only about 80% of the links in
common ISP topologies are protected by loop-free alternates. How should
the operator deal with links without LFA ?

I'm not convinced that operators would like solution like the following ;
- check whether the link is protected by LFA
- if the link is protected by LFA, do something
- otherwise do another check and do something else

I guess operators will prefer a solution where the router recognise
proactive changes and deal with them automatically.

> This may result in slowly stepwise shifting the topology when turning on/off resources. 
> More elaborate schemes can add coverage in this case. But you can just
> as well design mechanisms for this particular case that explicit versus
> algorithmic. 

There is one simple solution to deal with proactive topology changes :
order the FIB updates on the routers. This ordering guarantees that the
network will converge without any transient loop and thyus without
packet losses. This ordering can be easily added to link state protocols
as shown in the following drafts :

http://www.ietf.org/internet-drafts/draft-francois-ordered-fib-01.txt
http://www.ietf.org/internet-drafts/draft-bonaventure-isis-ordered-00.txt

Furthermore, we recently did simulations to evaluate the convergence
time of IS-IS with the proposed extension. For these simulations, we
used as parameters the measured time to perform SPF, FIB updates, etc.
on Cisco 12k as discussed in
http://www.info.ucl.ac.be/people/OBO/papers/ccr403.pdf

The simulations were performed by considering a European network and a
Tier-1 ISP with presence in Europe, USA and Asia. In the Tier-1 ISP, the
paper mentionned above showed that sub-second convergence with regular
IS-IS can be achieved. Our recent simulations with the ordering of FIB
updates indicate that sub-second *ordered* convergence is also achieved
in this Tier-1 ISP.

Basically, in this Tier-1 ISP, our simulations indicate that for a
single link shutdown, regular IS-IS converges within 200- 300
milliseconds depending on the link being shutdown. During this regular
IS-IS convergence, there are transient loops that lead to packet losses.
With the ordered-ISIS, the convergence time is not larger than 750
milliseconds. During this convergence, there are *NO* packet losses in
contrast to regular IS-IS. Thus, in contrast to popular belief, ordered
FIB updates do not lead to slow network convergence...


Olivier






_______________________________________________
Pce mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/pce