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

Kohei Shiomoto <shiomoto.kohei@lab.ntt.co.jp> Wed, 07 June 2006 03:42 UTC

Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnowM-0003gu-NN for ccamp-archive@ietf.org; Tue, 06 Jun 2006 23:42:43 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnoEL-0002rG-7y for ccamp-archive@ietf.org; Tue, 06 Jun 2006 22:57:13 -0400
Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fnnx1-0007lH-TK for ccamp-archive@ietf.org; Tue, 06 Jun 2006 22:39:22 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from <owner-ccamp@ops.ietf.org>) id 1FnnrP-0001To-W8 for ccamp-data@psg.com; Wed, 07 Jun 2006 02:33:31 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level:
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1
Received: from [129.60.39.102] (helo=tama5.ecl.ntt.co.jp) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from <shiomoto.kohei@lab.ntt.co.jp>) id 1FnnrL-0001SU-TZ for ccamp@ops.ietf.org; Wed, 07 Jun 2006 02:33:28 +0000
Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.13.6/8.13.6) with ESMTP id k572Vb5T020862; Wed, 7 Jun 2006 11:31:37 +0900 (JST)
Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112]) by vcs3.rdh.ecl.ntt.co.jp (8.13.6/8.13.6) with ESMTP id k572VYR1026484; Wed, 7 Jun 2006 11:31:34 +0900 (JST)
Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.13.6/8.13.6) with ESMTP id k572VVBx026275; Wed, 7 Jun 2006 11:31:31 +0900 (JST)
Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.13.6/8.13.6) with ESMTP id k572VVf7021287; Wed, 7 Jun 2006 11:31:31 +0900 (JST)
Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id k572VUuT017346; Wed, 7 Jun 2006 11:31:30 +0900 (JST)
Received: from imc.m.ecl.ntt.co.jp (imc0.m.ecl.ntt.co.jp [129.60.5.141]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id k572VUNl017341; Wed, 7 Jun 2006 11:31:30 +0900 (JST)
Received: from [127.0.0.1] ([129.60.80.125]) by imc.m.ecl.ntt.co.jp (8.13.6/8.13.6) with ESMTP id k572VMEI020774; Wed, 7 Jun 2006 11:31:30 +0900 (JST)
Message-ID: <44863A78.2030601@lab.ntt.co.jp>
Date: Wed, 07 Jun 2006 11:31:20 +0900
From: Kohei Shiomoto <shiomoto.kohei@lab.ntt.co.jp>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.7.11) Gecko/20050728
X-Accept-Language: ja, en-us, en
MIME-Version: 1.0
To: Greg Bernstein <gregb@grotto-networking.com>
CC: Don Fedyk <dwfedyk@nortel.com>, ccamp@ops.ietf.org, pce@ietf.org
Subject: Re: [Pce] Virtual Network Topology (VNT) changes and IP layer routingloops
References: <34B3EAA5B3066A42914D28C5ECF5FEA408BEAF1C@zrtphxm2.corp.nortel.com> <44848FC5.7000902@grotto-networking.com> <44860BA7.2090301@lab.ntt.co.jp> <448623E2.5090204@grotto-networking.com>
In-Reply-To: <448623E2.5090204@grotto-networking.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-ccamp@ops.ietf.org
Precedence: bulk
X-Spam-Score: -2.6 (--)
X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c

Hi Greg

Thank you for your reply.

> Hi Kohei,  For the folks who haven't read the "micro-loop" drafts. These 
> describe transient loops that can occur at the IP layer or in MPLS with 
> LDP. In the GMPLS world we may also use the term LSP somewhat loosely to 
> apply to SDH, WDM, G.709 connections. Since these are all explicitly 
> routed (and due to their circuit switched nature too) we won't get loops 
> at these layers.

I just meant to explicit-routed LSP in MPLS domain over VNT in the
previous email.

> 
> However, when we use GMPLS to set up a new SDH, WDM, G.709, etc... 
> connection (or tear down a connection) between IP routers (modifying the 
> IP layer VNT) this looks like a link up or down "maintenance" action to 
> the IP layer and hence the issue with micro-loops so well described in 
> the drafts.

Yes. I called it VNT reconfiguration in the previous email. Either IP
datagram or MPLS labeled packet can be forwarded over the VNT. If we use
the explicit routed LSP to forward the MPLS labeled packet, we can
control the route to avoid micro-loop before the VNT changes.

Of course we need a micro-loop avoidance mechanism when we carry IP
datagram packet directly over the VNT. Such issue need to be addressed
in the future revision in the MLN docs and the Inter-layer PCE/VNT
manager docs.

Thanks,
--
Kohei

> 
> Regards
> 
> Greg B.
> 
> Kohei Shiomoto wrote:
> 
>> 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
3-9-11 Midori, Musashino, Tokyo 180-8585, Japan