Re: [Pce] Virtual Network Topology (VNT) changes and IP layer routingloops
Kohei Shiomoto <shiomoto.kohei@lab.ntt.co.jp> Tue, 06 June 2006 23:23 UTC
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnktk-0000ge-Ce for ccamp-archive@ietf.org; Tue, 06 Jun 2006 19:23:44 -0400
Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fnkth-0000t8-TE for ccamp-archive@ietf.org; Tue, 06 Jun 2006 19:23:44 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from <owner-ccamp@ops.ietf.org>) id 1FnkiX-000C3U-Ux for ccamp-data@psg.com; Tue, 06 Jun 2006 23:12:09 +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 1FnkiV-000C2x-KG for ccamp@ops.ietf.org; Tue, 06 Jun 2006 23:12:07 +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 k56NBoYp008121; Wed, 7 Jun 2006 08:11:50 +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 k56NBnWf021495; Wed, 7 Jun 2006 08:11:49 +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 k56NBmmv024588; Wed, 7 Jun 2006 08:11:48 +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 k56NBmgP020595; Wed, 7 Jun 2006 08:11:48 +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 k56NBmWc001179; Wed, 7 Jun 2006 08:11:48 +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 k56NBlq2001176; Wed, 7 Jun 2006 08:11:47 +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 k56NBamF004857; Wed, 7 Jun 2006 08:11:47 +0900 (JST)
Message-ID: <44860BA7.2090301@lab.ntt.co.jp>
Date: Wed, 07 Jun 2006 08:11:35 +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>
In-Reply-To: <44848FC5.7000902@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: 0.0 (/)
X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2
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
- Virtual Network Topology (VNT) changes and IP lay… Greg Bernstein
- RE: [Pce] Virtual Network Topology (VNT) changes … Don Fedyk
- Re: [Pce] Virtual Network Topology (VNT) changes … Greg Bernstein
- Re: [Pce] Virtual Network Topology (VNT) changes … Kohei Shiomoto
- Re: [Pce] Virtual Network Topology (VNT) changes … Greg Bernstein
- Re: [Pce] Virtual Network Topology (VNT) changes … Kohei Shiomoto
- Re: [Pce] Virtual Network Topology (VNT) changes … JP Vasseur
- RE: [Pce] Virtual Network Topology (VNT) changes … Don Fedyk
- Re: [Pce] Virtual Network Topology (VNT) changes … Olivier Bonaventure