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

JP Vasseur <jvasseur@cisco.com> Mon, 15 May 2006 17:09 UTC

Received: from [] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfgZX-0001eO-Ja; Mon, 15 May 2006 13:09:31 -0400
Received: from [] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfgZW-0001eG-DB for mter@ietf.org; Mon, 15 May 2006 13:09:30 -0400
Received: from sj-iport-5.cisco.com ([]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FfgZT-0007Kw-LX for mter@ietf.org; Mon, 15 May 2006 13:09:30 -0400
Received: from sj-dkim-8.cisco.com ([]) by sj-iport-5.cisco.com with ESMTP; 15 May 2006 10:09:10 -0700
X-IronPort-AV: i="4.05,130,1146466800"; d="scan'208,217"; a="276885695:sNHT2246951606"
Received: from sj-core-3.cisco.com (sj-core-3.cisco.com []) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id k4FH9Ap5004859; Mon, 15 May 2006 10:09:10 -0700
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com []) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k4FH97Jj016391; Mon, 15 May 2006 10:09:07 -0700 (PDT)
Received: from xfe-rtp-202.amer.cisco.com ([]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 15 May 2006 13:09:07 -0400
Received: from [] ([]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 15 May 2006 13:09:06 -0400
Mime-Version: 1.0 (Apple Message framework v749.3)
To: mter@ietf.org
Message-Id: <924BE816-7675-4E70-BB49-D2B4ED7FD885@cisco.com>
From: JP Vasseur <jvasseur@cisco.com>
Date: Mon, 15 May 2006 13:09:02 -0400
X-Mailer: Apple Mail (2.749.3)
X-OriginalArrivalTime: 15 May 2006 17:09:06.0268 (UTC) FILETIME=[45E889C0:01C67842]
DKIM-Signature: a=rsa-sha1; q=dns; l=13955; t=1147712950; x=1148576950; c=relaxed/simple; s=sjdkim8001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:JP=20Vasseur=20<jvasseur@cisco.com> |Subject:Need=20to=20decide=20on=20potential=20next=20steps=20for=20MTER; X=v=3Dcisco.com=3B=20h=3DKOygrgaYdmconWyKy/XF74mhwnc=3D; b=iNKecPqvCAUa/B1EPXQJaMec8pV+iWNlgHweS+jpOSZQOU3x/e74OGqMvKxOhu9MJ24tpQfO ivtIioFPE5Tpd4siiqDxoY+fX0mm/+E6qy4jhlqX0r4Nx6iXACgQxwXq;
Authentication-Results: sj-dkim-8.cisco.com; header.From=jvasseur@cisco.com; dkim=pass ( 30 extraneous bytes; sig from cisco.com verified; );
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 1e467ff145ef391eb7b594ef62b8301f
Cc: raymond_zhang@bt.infonet.com
Subject: [Mter] Need to decide on potential next steps for MTER
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>
Content-Type: multipart/mixed; boundary="===============1209504537=="
Errors-To: mter-bounces@ietf.org


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.


JP, Jean-Louis and Raymond.


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