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 _______________________________________________ Pce mailing list [email protected] https://www1.ietf.org/mailman/listinfo/pce
