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: Rüdiger 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
- THREAD 1 - Fwd: [Mter] Need to decide on potentia… JP Vasseur
- [Mter] Need to decide on potential next steps for… JP Vasseur
- Re: [Mter] Need to decide on potential next steps… Michael Menth
- Re: [Mter] Need to decide on potential next steps… Diego Caviglia
- Re: [Mter] Need to decide on potential next steps… JP Vasseur
- Re: Fwd: [Mter] Need to decide on potential next … Diego Caviglia