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

JP Vasseur <jvasseur@cisco.com> Tue, 16 May 2006 11:26 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffxh9-0005yM-7S; Tue, 16 May 2006 07:26:31 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffxh7-0005yE-IT for mter@ietf.org; Tue, 16 May 2006 07:26:29 -0400
Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ffxh6-0008OL-72 for mter@ietf.org; Tue, 16 May 2006 07:26:29 -0400
Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 16 May 2006 07:26:27 -0400
X-IronPort-AV: i="4.05,133,1146456000"; d="scan'208"; a="88649216:sNHT32224012"
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k4GBQRvF010354; Tue, 16 May 2006 07:26:27 -0400 (EDT)
Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 16 May 2006 07:26:27 -0400
Received: from [10.86.104.178] ([10.86.104.178]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 16 May 2006 07:26:26 -0400
In-Reply-To: <44697B48.5010909@informatik.uni-wuerzburg.de>
References: <924BE816-7675-4E70-BB49-D2B4ED7FD885@cisco.com> <44697B48.5010909@informatik.uni-wuerzburg.de>
Mime-Version: 1.0 (Apple Message framework v749.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <95A61A84-7C33-452C-BD65-EAAE3E00E267@cisco.com>
Content-Transfer-Encoding: 7bit
From: JP Vasseur <jvasseur@cisco.com>
Subject: Re: [Mter] Need to decide on potential next steps for MTER
Date: Tue, 16 May 2006 07:26:24 -0400
To: menth@informatik.uni-wuerzburg.de
X-Mailer: Apple Mail (2.749.3)
X-OriginalArrivalTime: 16 May 2006 11:26:26.0940 (UTC) FILETIME=[9201CBC0:01C678DB]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6
Cc: =?ISO-8859-1?Q?R=FCdiger_Martin?= <martin@informatik.uni-wuerzburg.de>, raymond_zhang@bt.infonet.com, mter@ietf.org
X-BeenThere: mter@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Multi-TEchnology Recovery <mter.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mter>, <mailto:mter-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/mter>
List-Post: <mailto:mter@ietf.org>
List-Help: <mailto:mter-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mter>, <mailto:mter-request@ietf.org?subject=subscribe>
Errors-To: mter-bounces@ietf.org

Hi Michael,

Do you see any particular items in your work that would require  
standardization (protocol, MIBs, ...) ?

JP.

On May 16, 2006, at 3:12 AM, Michael Menth wrote:

> 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:
> http://www3.informatik.uni-wuerzburg.de/~menth/Publications/ 
> Menth04c.pdf
> http://www3.informatik.uni-wuerzburg.de/~menth/Publications/ 
> Menth05f.pdf
> http://www3.informatik.uni-wuerzburg.de/~menth/Publications/ 
> Menth06f.pdf
>
> 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,
>
>    Michael
>
> 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 (http://www.ietf.org/internet-drafts/draft- 
>> ahmad- 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
>> MTER@ietf.org
>> https://www1.ietf.org/mailman/listinfo/mter
>>
>
> -- 
> 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
> mailto:menth@informatik.uni-wuerzburg.de
> http://www3.informatik.uni-wuerzburg.de/research/ngn

_______________________________________________
MTER mailing list
MTER@ietf.org
https://www1.ietf.org/mailman/listinfo/mter