Re: [Mter] Need to decide on potential next steps for MTER

Michael Menth <> Tue, 16 May 2006 07:12 UTC

Received: from [] ( by with esmtp (Exim 4.43) id 1FftjC-0006eZ-Cb; Tue, 16 May 2006 03:12:22 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1FftjA-0006eU-TW for; Tue, 16 May 2006 03:12:20 -0400
Received: from ([] by with esmtp (Exim 4.43) id 1Fftj8-0005H9-9r for; Tue, 16 May 2006 03:12:20 -0400
Received: from virusscan.mail (localhost []) by mailrelay.mail (Postfix) with ESMTP id 22AC4D38; Tue, 16 May 2006 09:12:13 +0200 (CEST)
Received: from localhost (localhost []) by virusscan.mail (Postfix) with ESMTP id 16959C62; Tue, 16 May 2006 09:12:13 +0200 (CEST)
Received: from ( []) by (Postfix) with ESMTP id D18E2B9B; Tue, 16 May 2006 09:12:12 +0200 (CEST)
Received: from ( []) by (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id k4G7CC719378; Tue, 16 May 2006 09:12:12 +0200
Received: from [] ( []) by (Postfix) with ESMTP id 6E3D56F58E; Tue, 16 May 2006 09:13:01 +0200 (CEST)
Message-ID: <>
Date: Tue, 16 May 2006 09:12:08 +0200
From: Michael Menth <>
Organization: University of Wuerzburg
User-Agent: Thunderbird (Windows/20060308)
MIME-Version: 1.0
To: JP Vasseur <>
Subject: Re: [Mter] Need to decide on potential next steps for MTER
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db
Cc: Rüdig er Martin <>,,
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Multi-TEchnology Recovery <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

Dear JP, Jean-Louis, and Raymond,

we are working on the field of multi-layer resilience, in particular 
regarding the required backup capacity of protection and restoration 
mechanisms, e.g. MPLS-FRR and others:

We, as a university, are interested in the mter discussion to share our 
experience and to find new relevant issues for further research. I hope 
that sufficiently many manufacturers and operators also express their 
interest in this activity.

Kind regards,


JP Vasseur wrote:
> Hi,
> Below the email we sent to the list some time ago, seeking for 
> feed-backs but so far the list has been pretty quiet. During the past 
> few months we received a very few off-line positive feed-backs 
> indicating some interest in this work. It is now a good time to decide 
> on whether there is enough interest to work on this topic by the IETF 
> community in which case we will request a BOF approval or whether the 
> interest is too weak to pursue this work.
> So we will follow up with a few discussion threads related to the 
> scenarios described in the problem statement ID, for which we'd like 
> to get your feed-back relatively quickly, should you think that it is 
> worth being pursed.
> Thanks.
> JP, Jean-Louis and Raymond.
> Hi,
> It took a little while to come up with a clear problem statement but 
> we now have an I-D ( 
> mter-problem-statement-00.txt (thanks to the authors)) that will 
> hopefully trigger some discussion with the objective to see whether 
> there is enough interest to pursue this work at the IETF.
> The draft has been structured so as to first show three scenarios 
> where various recovery mechanisms could be used in combination. This 
> does not aim to cover all possible cases but some pretty common 
> deployment scenario for the sake of illustration. Then various Multi- 
> TEchnology Recovery (MTER) issues are discussed.
> What is the objective of this work ?
> Let's start with the set of non-objective first ...
> * There is no intention to come up with protocols extensions that are 
> being worked out in existing WGs (ISIS, IDR, CCAMP, ....)
> * Discuss implementation-specific issues
> Now the objectives ...
> What has been shown through the three MTER deployment cases making use 
> of multiple recovery mechanisms in combination is the following:
> -> There are cases where being able to identify the root failure cause 
> would significantly improve various recovery metrics such as the 
> convergence time, required backup capacity, ... and so on. Do we need 
> to work on such mechanisms at the IETF is an open question ?
> -> MIBs and OAM tools have been defined for most of the recovery 
> techniques (IGP, BGP, MPLS FRR, GMPLS, ... ) and there are clearly no 
> such tool for the aspects related to their combined use. It looks like 
> the availability of such tools would help Service Providers to manage, 
> tune and troubleshooting their network. Again, feed-backs from this ML 
> are critical to see how to move forward and if the community expressed 
> some interest.
> Thanks for your feed-backs.
> JP, Jean-Louis and Raymond.
> ------------------------------------------------------------------------
> _______________________________________________
> MTER mailing list

Dr. Michael Menth, Assistant Professor
University of Wuerzburg, Institute of Computer Science
Am Hubland, D-97074 Wuerzburg, Germany, room B206
phone: (+49)-931/888-6644, fax: (+49)-931/888-6632

MTER mailing list