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

Greg Bernstein <gregb@grotto-networking.com> Mon, 05 June 2006 20:10 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnLPc-0003qT-G3; Mon, 05 Jun 2006 16:10:56 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnLPb-0003qO-1v for pce@ietf.org; Mon, 05 Jun 2006 16:10:55 -0400
Received: from pro.abac.com ([66.226.64.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnLPZ-0000lE-LH for pce@ietf.org; Mon, 05 Jun 2006 16:10:55 -0400
Received: from [192.168.0.100] (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 k55KAkid076396 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Jun 2006 13:10:51 -0700 (PDT) (envelope-from gregb@grotto-networking.com)
Message-ID: <44848FC5.7000902@grotto-networking.com>
Date: Mon, 05 Jun 2006 13:10:45 -0700
From: Greg Bernstein <gregb@grotto-networking.com>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: Don Fedyk <dwfedyk@nortel.com>
Subject: Re: [Pce] Virtual Network Topology (VNT) changes and IP layer routingloops
References: <34B3EAA5B3066A42914D28C5ECF5FEA408BEAF1C@zrtphxm2.corp.nortel.com>
In-Reply-To: <34B3EAA5B3066A42914D28C5ECF5FEA408BEAF1C@zrtphxm2.corp.nortel.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 34d35111647d654d033d58d318c0d21a
Cc: ccamp@ops.ietf.org, pce@ietf.org
X-BeenThere: pce@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Path Computation Element <pce.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/pce>
List-Post: <mailto:pce@lists.ietf.org>
List-Help: <mailto:pce-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@lists.ietf.org?subject=subscribe>
Errors-To: pce-bounces@lists.ietf.org

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



_______________________________________________
Pce mailing list
Pce@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce