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

[Kohei Shiomoto <shiomoto.kohei@lab.ntt.co.jp>]

Hi Greg

Thank you for your kind notice.

I think that the avoiding micro-loop is an important work. Micro-loop
could unnecessarily amplify traffic load as much as 128 times, which
should be a serious problem for today's wire-speed packet forwarding at
high-speed link.

So far micro-loop avoidance has been discussed in the context of
maintenance operations including link install/removal, IGP link cost
change, etc. As you pointed out, micro-loop may form in the process of
VNT reconfiguration if IP datagram is forwarded directly on top of VNT
(if we use explicit-routed LSP, we could avoid micro-loop). Micro-loop
avoidance should also be considered in the context of VNT reconfiguration.

Thank you again for your pointer.
--
Kohei


Greg Bernstein wrote:

> 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.
> 
> Greg B.
> 
> Don Fedyk wrote:
> 
>> Hi Greg
>>
>> Whoa....
>>   [Snip]
>> 1) These virtual topologies are for control traffic and they are solid
>> most of the time.
>> 2) The existing data traffic is not disrupted when the control traffic
>> has microloops. 3) There may be a delay in signaling of new or 
>> rerouted connections when
>> the control traffic has microloops. This is analogous to Graceful
>> recovery of the control plane where the data plane is momentarily unable
>> to adapt to new changes.
>> 4) Many of the optical technologies we have do not need response to
>> signaling in less than 100s of milliseconds so the delay is not
>> critical.
>> 5) We need a clear separation of protection which can be locally driven
>> and fast (50 msec) and routing and rerouting which are slower
>> restoration mechanisms. As long as protection mechanisms are independent
>> of the control plane primary protection is safe IMHO.
>>
>>
>>  
>>
>>> At the Routing working group, Alex's draft 
>>> draft-ietf-rtgwg-microloop-analysis-01.txt provides some analysis and 
>>> a method to reduce the impact (duration too) of the transient loops.  
>>> More recently the drafts:
>>> (1) draft-bryant-shand-lf-applicability-01.txt
>>> (2) draft-bryant-shand-lf-conv-frmwk-02.txt
>>> (3) draft-francois-ordered-fib-01.txt
>>> Address this problem more generally including in (3) a method that 
>>> guarantee loop free convergence.
>>>
>>>     
>>
>>
>> Loop Free Alternates are a good thing.  But with more advanced
>> mechanisms it is very hard to determine if the cure is worse than the
>> symptoms.
>>
>>
>>  
>>
>>> The problem is that these have generated very little interest at the 
>>> RTG WG and may not move forward.  This area is not within PCE or 
>>> CCAMPs charter but can have an impact on the adoption of GMPLS in 
>>> multi-layer/region networking. If you're interested please take a 
>>> look and comment to the RTG WG.  Note I wasn't involved with writing 
>>> these, but came across them when considering the effects of GMPLS 
>>> changes on the IP layer VNT.
>>>     
>>
>>
>> There was a lot of interest and a genuine amount of push back.
>> Personally I would be very concerned about tight coupling of a control
>> plane convergence to impacts on a GMPLS control data plane.
>> Regards,
>> Don
>>
>>  
>>
>>> Thanks
>>>
>>> Greg B.
>>>
>>> -- 
>>> ===================================================
>>> Dr Greg Bernstein, Grotto Networking (510) 573-2237
>>>     
>>
>>
>>
>>   
> 
> 


-- 
Kohei Shiomoto
NTT Network Service Systems Laboratories