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

Greg Bernstein <gregb@grotto-networking.com> Wed, 07 June 2006 01:09 UTC

Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnmY2-0002Wi-IL for ccamp-archive@ietf.org; Tue, 06 Jun 2006 21:09:26 -0400
Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnmY1-0006ox-4S for ccamp-archive@ietf.org; Tue, 06 Jun 2006 21:09:26 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from <owner-ccamp@ops.ietf.org>) id 1FnmTS-000KTw-2o for ccamp-data@psg.com; Wed, 07 Jun 2006 01:04:42 +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=BAYES_00 autolearn=ham version=3.1.1
Received: from [66.226.64.2] (helo=pro.abac.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from <gregb@grotto-networking.com>) id 1FnmTR-000KTX-4k for ccamp@ops.ietf.org; Wed, 07 Jun 2006 01:04:41 +0000
Received: from [192.168.0.103] (c-67-188-134-148.hsd1.ca.comcast.net [67.188.134.148]) (authenticated bits=0) by pro.abac.com (8.13.6/8.13.6) with ESMTP id k570swPW065715 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Jun 2006 17:55:04 -0700 (PDT) (envelope-from gregb@grotto-networking.com)
Message-ID: <448623E2.5090204@grotto-networking.com>
Date: Tue, 06 Jun 2006 17:54:58 -0700
From: Greg Bernstein <gregb@grotto-networking.com>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: Kohei Shiomoto <shiomoto.kohei@lab.ntt.co.jp>
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>
In-Reply-To: <44860BA7.2090301@lab.ntt.co.jp>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Sender: owner-ccamp@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac

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.

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.

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
>>>>     
>>>>         
>>>
>>>   
>>>       
>>     
>
>
>   

-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237