[Mter] Time to start the discussion ?

JP Vasseur <jvasseur@cisco.com> Tue, 28 February 2006 22:31 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEDNO-0004lt-27; Tue, 28 Feb 2006 17:31:26 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEDNN-0004jt-63 for mter@ietf.org; Tue, 28 Feb 2006 17:31:25 -0500
Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEDNL-0002zR-SV for mter@ietf.org; Tue, 28 Feb 2006 17:31:25 -0500
Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 28 Feb 2006 14:31:24 -0800
X-IronPort-AV: i="4.02,154,1139212800"; d="scan'208"; a="258557555:sNHT33452814"
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k1SMVJXl027080; Tue, 28 Feb 2006 14:31:20 -0800 (PST)
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, 28 Feb 2006 17:31:19 -0500
Received: from [10.86.104.179] ([10.86.104.179]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 28 Feb 2006 17:31:19 -0500
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <49F0ECD8-F080-4DC1-9CD3-0363258A4972@cisco.com>
Content-Transfer-Encoding: 7bit
From: JP Vasseur <jvasseur@cisco.com>
Date: Tue, 28 Feb 2006 17:30:42 -0500
To: mter@ietf.org
X-Mailer: Apple Mail (2.746.2)
X-OriginalArrivalTime: 28 Feb 2006 22:31:19.0174 (UTC) FILETIME=[B1D2E260:01C63CB6]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4
Cc: "David Kessens \(E-mail\)" <david.kessens@nokia.com>, lei.wang@telenor.com, "Bert \(Bert\) Wijnen" <bwijnen@lucent.com>, Jaime Miles <Jaime.Miles@Level3.com>
Subject: [Mter] Time to start the discussion ?
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,

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