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

"Don Fedyk" <dwfedyk@nortel.com> Mon, 05 June 2006 18:45 UTC

Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnK4T-0002wO-79 for ccamp-archive@ietf.org; Mon, 05 Jun 2006 14:45:01 -0400
Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnK4R-0008Gu-Qt for ccamp-archive@ietf.org; Mon, 05 Jun 2006 14:45:01 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from <owner-ccamp@ops.ietf.org>) id 1FnJye-000C6z-3M for ccamp-data@psg.com; Mon, 05 Jun 2006 18:39:00 +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,SPF_PASS autolearn=ham version=3.1.1
Received: from [47.129.242.57] (helo=zcars04f.nortel.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from <DWFEDYK@nortel.com>) id 1FnJyc-000C6o-QS for ccamp@ops.ietf.org; Mon, 05 Jun 2006 18:38:58 +0000
Received: from zrtphxm2.corp.nortel.com (zrtphxm2.corp.nortel.com [47.140.202.51]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k55Icmh25468; Mon, 5 Jun 2006 14:38:49 -0400 (EDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Pce] Virtual Network Topology (VNT) changes and IP layer routingloops
Date: Mon, 05 Jun 2006 14:38:34 -0400
Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA408BEAF1C@zrtphxm2.corp.nortel.com>
In-Reply-To: <44845914.3090207@grotto-networking.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Pce] Virtual Network Topology (VNT) changes and IP layer routingloops
Thread-Index: AcaIu5iEb+JIM5PjSJeSLES9IYXNVwAERA9w
From: Don Fedyk <dwfedyk@nortel.com>
To: Greg Bernstein <gregb@grotto-networking.com>, ccamp@ops.ietf.org, pce@ietf.org
Sender: owner-ccamp@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be

Hi Greg

Whoa.... 

> -----Original Message-----
> From: Greg Bernstein [mailto:gregb@grotto-networking.com] 
> Sent: Monday, June 05, 2006 12:17 PM
> To: ccamp@ops.ietf.org; pce@ietf.org
> Subject: [Pce] Virtual Network Topology (VNT) changes and IP 
> layer routingloops
> 
> Hi folks, in drafts draft-ietf-ccamp-gmpls-mln-reqs-00.txt 
> and draft-ietf-pce-inter-layer-frwk-00.txt the concepts of 
> multi-layer and multi-region networking are defined and discussed. 
> 
> An important case is when the IP layer rests directly upon a 
> "virtual network topology" layer that we will desire to 
> change via GMPLS signaling. Changes to the IP layer VNT can 
> produce "transient IP layer routing loops" also known as 
> "micro loops" which can last 100's of mili seconds or more.  
> Hence any time we change a connection between IP layer 
> routers via GMPLS we can cause significant outages compared 
> to the recovery times that we set out to achieve with GMPLS 
> fast reroute and other mechanisms such as SDH APS (rings and linear).

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