From mter-bounces@ietf.org Mon May 15 13:09:31 2006 Received: from [127.0.0.1] (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 [10.91.34.44] (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 ([171.68.10.87]) 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 ([171.68.10.93]) 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 [171.68.223.137]) 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 [64.102.31.102]) 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 ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 15 May 2006 13:09:07 -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); 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 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 |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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1209504537==" Errors-To: mter-bounces@ietf.org --===============1209504537== Content-Type: multipart/alternative; boundary=Apple-Mail-84--245465227 --Apple-Mail-84--245465227 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed 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. --Apple-Mail-84--245465227 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=US-ASCII
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-<= /SPAN> = 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.

= --Apple-Mail-84--245465227-- --===============1209504537== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MTER mailing list MTER@ietf.org https://www1.ietf.org/mailman/listinfo/mter --===============1209504537==-- From mter-bounces@ietf.org Mon May 15 14:41:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffi0K-0008Nq-0S; Mon, 15 May 2006 14:41:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffi0I-0008Nh-6R for mter@ietf.org; Mon, 15 May 2006 14:41:14 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ffi0F-0001dN-Km for mter@ietf.org; Mon, 15 May 2006 14:41:14 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 15 May 2006 14:41:11 -0400 X-IronPort-AV: i="4.05,130,1146456000"; d="scan'208,217"; a="88605375:sNHT52916248" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k4FIfBvF020831; Mon, 15 May 2006 14:41:11 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 15 May 2006 14:41:10 -0400 Received: from [10.86.104.178] ([10.86.104.178]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 15 May 2006 14:41:09 -0400 Mime-Version: 1.0 (Apple Message framework v749.3) References: <924BE816-7675-4E70-BB49-D2B4ED7FD885@cisco.com> Message-Id: <99441BFD-9A17-4478-94AA-C945F4DCF354@cisco.com> From: JP Vasseur Subject: THREAD 1 - Fwd: [Mter] Need to decide on potential next steps for MTER Date: Mon, 15 May 2006 14:41:06 -0400 To: mter@ietf.org X-Mailer: Apple Mail (2.749.3) X-OriginalArrivalTime: 15 May 2006 18:41:09.0495 (UTC) FILETIME=[22021870:01C6784F] X-Spam-Score: 0.2 (/) X-Scan-Signature: 6437e26f1586b9f35812ea5ebeedf4ad Cc: X-BeenThere: mter@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-TEchnology Recovery List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0684728037==" Errors-To: mter-bounces@ietf.org --===============0684728037== Content-Type: multipart/alternative; boundary=Apple-Mail-86--239942002 --Apple-Mail-86--239942002 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, With regards to scenario 1 of http://www.ietf.org/internet-drafts/ draft-ahmad-mter-problem-statement-00.txt Do you think that: (1) There is a need for more than simple hold-off timer (e.g. inter- layer token-based synchronization process) ? Note that this answer may be "Yes, but no need for standardization, implementation specific) (2) Requirement for identification failure mechanisms so as to trigger the appropriate mechanism? (3) Is there a need for a MIB that would keep track of the number of times each mechanism has triggered a recovery action and the reasons for each activation? (4) ... Thanks. JP, Raymond and Jean-Louis. Begin forwarded message: > From: JP Vasseur > Date: May 15, 2006 1:09:02 PM EDT > To: mter@ietf.org > Cc: raymond_zhang@bt.infonet.com > Subject: [Mter] Need to decide on potential next steps for MTER > > 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 --Apple-Mail-86--239942002 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi,


Do you think = that:=A0

(1) = There is a need for more than simple hold-off timer (e.g. inter-layer = token-based synchronization process) ? Note that this answer may be = "Yes, but no need for standardization, implementation = specific)
(2) Requirement for identification failure = mechanisms so as to trigger the appropriate mechanism?
(3) Is = there a need for a MIB that would keep track of the number of times each = mechanism
=A0 =A0 =A0has triggered a recovery action and the = reasons for each activation?=A0
(4) ...

Thanks.

JP, Raymond and = Jean-Louis.

Begin forwarded message:

From: = JP Vasseur <jvasseur@cisco.com>
=
Date: = May 15, 2006 1:09:02 PM EDT

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-<= /SPAN> = 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
=

= --Apple-Mail-86--239942002-- --===============0684728037== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MTER mailing list MTER@ietf.org https://www1.ietf.org/mailman/listinfo/mter --===============0684728037==-- From mter-bounces@ietf.org Tue May 16 03:12:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FftjC-0006eZ-Cb; Tue, 16 May 2006 03:12:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FftjA-0006eU-TW for mter@ietf.org; Tue, 16 May 2006 03:12:20 -0400 Received: from wrzx28.rz.uni-wuerzburg.de ([132.187.3.28] helo=mailrelay.rz.uni-wuerzburg.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fftj8-0005H9-9r for mter@ietf.org; Tue, 16 May 2006 03:12:20 -0400 Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 22AC4D38; Tue, 16 May 2006 09:12:13 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 16959C62; Tue, 16 May 2006 09:12:13 +0200 (CEST) Received: from europa.informatik.uni-wuerzburg.de (wicx01.informatik.uni-wuerzburg.de [132.187.11.1]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id D18E2B9B; Tue, 16 May 2006 09:12:12 +0200 (CEST) Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.106.5]) by europa.informatik.uni-wuerzburg.de (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 [132.187.106.123] (win3123.informatik.uni-wuerzburg.de [132.187.106.123]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id 6E3D56F58E; Tue, 16 May 2006 09:13:01 +0200 (CEST) Message-ID: <44697B48.5010909@informatik.uni-wuerzburg.de> Date: Tue, 16 May 2006 09:12:08 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: JP Vasseur Subject: Re: [Mter] Need to decide on potential next steps for MTER References: <924BE816-7675-4E70-BB49-D2B4ED7FD885@cisco.com> In-Reply-To: <924BE816-7675-4E70-BB49-D2B4ED7FD885@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: =?ISO-8859-1?Q?R=FCdig?= =?ISO-8859-1?Q?er_Martin?= , raymond_zhang@bt.infonet.com, mter@ietf.org X-BeenThere: mter@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: Multi-TEchnology Recovery List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mter-bounces@ietf.org 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 From mter-bounces@ietf.org Tue May 16 03:23:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fftu5-0001bK-HN; Tue, 16 May 2006 03:23:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fftu3-0001bF-Gz for mter@ietf.org; Tue, 16 May 2006 03:23:35 -0400 Received: from smtpmast05.marconi.com ([128.87.251.114]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fftu3-0005Tg-00 for mter@ietf.org; Tue, 16 May 2006 03:23:35 -0400 Received: from cvdgwy02.uk.marconicomms.com (cvis27.uk.marconicomms.com [128.87.251.110]) by smtpmast05.marconi.com (8.12.11.20060308/8.12.11) with ESMTP id k4G7NNPx004241; Tue, 16 May 2006 08:23:23 +0100 (BST) (envelope-from Diego.Caviglia@marconi.com) Sensitivity: Subject: Re: [Mter] Need to decide on potential next steps for MTER To: JP Vasseur , raymond_zhang@bt.infonet.com X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: "Diego Caviglia" Date: Tue, 16 May 2006 09:23:19 +0200 X-MIMETrack: Serialize by Router on CVDGWY02/S/EXT/MC1(Release 5.0.13a |April 8, 2004) at 16/05/2006 08:23:22 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Cc: mter X-BeenThere: mter@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-TEchnology Recovery List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mter-bounces@ietf.org Some times ago I've published an ID about the requirements for interwor= king between MS-SPRing and GMPLS, I think that this kind of interworking is something that is MTER related and is also interesting from a carrier prespective at least this is my feeling. Regards Diego Michael Menth on 16/05/2006 09.12.0= 8 Please respond to menth@informatik.uni-wuerzburg.de To: JP Vasseur cc: R=FCdiger Martin , raymond_zhang@bt.infonet.com, mter@ietf.org Subject: Re: [Mter] Need to decide on potential next steps for MTER 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.pd= f http://www3.informatik.uni-wuerzburg.de/~menth/Publications/Menth05f.pd= f http://www3.informatik.uni-wuerzburg.de/~menth/Publications/Menth06f.pd= f 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 decid= e > 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 us= e > of multiple recovery mechanisms in combination is the following: > > -> There are cases where being able to identify the root failure caus= e > 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 lik= e > the availability of such tools would help Service Providers to manage= , > tune and troubleshooting their network. Again, feed-backs from this M= L > are critical to see how to move forward and if the community expresse= d > 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 = _______________________________________________ MTER mailing list MTER@ietf.org https://www1.ietf.org/mailman/listinfo/mter From mter-bounces@ietf.org Tue May 16 07:26:35 2006 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 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?= , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 From mter-bounces@ietf.org Tue May 16 09:16:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfzPZ-0001Go-V9; Tue, 16 May 2006 09:16:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfyCZ-00060F-GC for mter@ietf.org; Tue, 16 May 2006 07:58:59 -0400 Received: from smtpmast05.marconi.com ([128.87.251.114]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FfyCW-0002So-7a for mter@ietf.org; Tue, 16 May 2006 07:58:59 -0400 Received: from cvdgwy02.uk.marconicomms.com (cvis27.uk.marconicomms.com [128.87.251.110]) by smtpmast05.marconi.com (8.12.11.20060308/8.12.11) with ESMTP id k4GBwh5L005565; Tue, 16 May 2006 12:58:43 +0100 (BST) (envelope-from Diego.Caviglia@marconi.com) Sensitivity: Subject: Re: Fwd: [Mter] Need to decide on potential next steps for MTER To: "JP Vasseur , mter@ietf.org X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: "Diego Caviglia" Date: Tue, 16 May 2006 13:58:38 +0200 X-MIMETrack: Serialize by Router on CVDGWY02/S/EXT/MC1(Release 5.0.13a |April 8, 2004) at 16/05/2006 12:58:42 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 8d99e2862a1ba097be60bce990cc30ed X-Mailman-Approved-At: Tue, 16 May 2006 09:16:27 -0400 Cc: raymond_zhang X-BeenThere: mter@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-TEchnology Recovery List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mter-bounces@ietf.org Hi JP, the ID expired in April this year so is no longer on the ID database. Here is the ID, comments are very welcome. Regards Diego CCAMP Internet Draft Diego Caviglia (Marconi) Dino Bramanti (Marconi) Huub van Helvoort(Huawei Technologie= s Ltd) Document: draft-caviglia-ccamp-gmpls-msspring- req-00 Expires: April 2006 October= 2005 GMPLS Requirements for MS-SPRing support Status of this Memo By submitting this Internet-Draft, each author represents that an= y applicable patent or other IPR claims of which he or she is aware= have been or will be disclosed, and any of which he or she become= s aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering= Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six mo= nths and may be updated, replaced, or obsoleted by other documents at = any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as =F4work in progress=F6. The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract GMPLS [1] provides ideally a robust and flexible control plane protocols set designed for application over generalized transport= network. A typical application of GMPLS is, among others, the con= trol of transport networks based on SDH/SONET [2] technology. In this scenario, the introduction of GMPLS based control plane should en= sure support of and/or compatibility with the most important and widel= y exploited SDH/SONET features, making possible a seamless interwor= king with inherent data plane requirements. In this document we focus = on one of the most attractive SDH/SONET protection mechanism, implemented through MS-SPRing (G.841 [3]), a widely deployed ITU standard for ring-shared protection. Caviglia Expires - April 2006 [Page = 1] =0C draft-caviglia-ccamp-GMPLS-MSSPRing-Req-00 October= 2005 In general, when setting up and configuring a data plane circuit traversing a MS-SPRing ring (or segments of it) via traditional management plane control, special constraints, which are specific= to this kind of technology, have to be considered in order to ensure= its correct operation. The same constraints have to be carefully take= n into account when the data plane circuit is no more set up in a traditional way, but through a GMPLS based control plane. The specific constraints imposed by MS-SPRing are related to: . Time Slot Interchange (TSI) . Ring Map filling in case of squelching In this document a brief overview of MS-SPRing operation is introduced and its specific requirements are explained, putting i= n evidence the way they may impact when GMPLS is used as control pl= ane. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT= ", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in = this document are to be interpreted as described in RFC-2119 [4]. Table of Contents 1. MS-SPRing Bird Eye Overview...................................= 3 1.1 Information needed by MS-SPRing..............................= 5 1.2 MS-SPRing Example............................................= 6 1.3 Time Slot Interchange (TSI).................................1= 1 1.4 Squelching..................................................1= 1 2. GMPLS requirements imposed by MS-SPRing......................1= 3 2.1 LSP Set-Up..................................................1= 3 2.2 Data Plane and Control Plane misalignment...................1= 3 2.3 Interworking between GMPLS restoration and MS-SPRing Protecti= on14 3. Security Considerations......................................1= 4 References......................................................1= 4 Acknowledgments.................................................1= 5 Author's Addresses..............................................1= 5 Caviglia Expires - April 2006 [Page = 2] =0C draft-caviglia-ccamp-GMPLS-MSSPRing-Req-00 October= 2005 1. MS-SPRing Bird Eye Overview The main reference for this Section is ITU-T G.841. G.841 define= s two different kinds of MS-SPRing namely two fibers and four fiber= s. Two-fiber MS switched rings require only two fibers for each span= of the ring. Each fiber carries both working channels and protection= channels. On each fiber, up to half the channels are defined as working channels and up to half are defined as protection channel= s. It is possible that some channels are not protected at all, being= defined as Non-pre-emptible Unprotected Traffic (NUT) channels. The traffic carried on working channels inside one fiber is prote= cted by channels going in the opposite direction around the ring. Thi= s allows for a bi-directional transport of normal traffic and makes= possible a sharing of the protection resources when needed. The following picture illustrates the two fibers case, no NUT in = this example. WPx links are 50% for worker traffic and 50% for protection traff= ic, e.g. and STM-16 links have 8 AU-4 timeslot for worker traffic and= 8 AU-4 timeslot for protection. TNE A TNE B TNE C +------------+ +------------+ +-----------= -+ | | | | | = | | | | | | = | | | | | | = | | |----------->| |----------->| = | | | WP1 | | WP2 | = | | |<-----------| |<-----------| = | | | | | | = | | | | | | = | | | | | | = | +------------+ +------------+ +-----------= -+ ^ | ^ | | | | | | | | | | WP3 | WP Links Resources are | WP4 | | | 50% Worker | | | | 50% Protection | | | v | v +------------+ +------------+ +-----------= -+ | | | | | = | | | | | | = | | | | | | = | | |----------->| |----------->| = | Caviglia Expires - April 2006 [Page = 3] =0C draft-caviglia-ccamp-GMPLS-MSSPRing-Req-00 October= 2005 | | WP5 | | WP6 | = | | |<-----------| |<-----------| = | | | | | | = | | | | | | = | | | | | | = | +------------+ +------------+ +-----------= -+ TNE F TNE E TNE D Figure 1-1: MS-SPRing two fibers reference circuit Four-fiber MS shared protection rings require four fibers for eac= h span of the ring. As illustrated in Figure 1-2, working and protection channels are carried over different fibers: two multip= lex sections transmitting in opposite directions carry the working channels while two multiplex sections, also transmitting in oppos= ite directions, carry the protection channels. This enables the bi- directional transport of normal traffic, sharing as well the protection capability. The following picture illustrates the reference circuit (four fib= er MS-SPRing) used in this Section. TNE A TNE B TNE C +------------+ +------------+ +-----------= -+ | | | | | = | | |----------->| |----------->| = | | | W1 | | W2 | = | | |<-----------| |<-----------| = | | | | | | = | | |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| |=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| | | | P1 | | P2 | = | | |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D| |<=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D| | | | | | | = | +------------+ +------------+ +-----------= -+ ^ | ^ l ^ l ^ |= | | l l l l | |= | | l l l l | |= |W3| lP3l ------------ Working Link lP4l |W4|= | | l l llll and =3D=3D=3D Protection Link l l= | | | | l l l l | |= | v l v l v | v= +------------+ +------------+ +-----------= -+ | | | | | = | | |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| |=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| | | | P5 | | P6 | = | | |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D| |<=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D| | | | | | | = | | |----------->| |----------->| = | | | W5 | | W6 | = | Caviglia Expires - April 2006 [Page = 4] =0C draft-caviglia-ccamp-GMPLS-MSSPRing-Req-00 October= 2005 | |<-----------| |<-----------| = | | | | | | = | +------------+ +------------+ +-----------= -+ TNE F TNE E TNE D Figure 1-2: Reference circuit for MS-SPRing, four fibers varia= nt 1.1 Information needed by MS-SPRing The MS-SPRing protection mechanism is implemented via a SDH signalling protocol known as Automatic Protection Switching (APS)= . This protocol makes use of SDH overhead bytes (K1 and K2, MS over= head bytes) as a means to transport its own information. APS is not detailed here as it is outside the scope of this document. Each node on the ring shall be assigned an ID that is a number fr= om 0 to 15, allowing a maximum of 16 nodes on the ring. Such ID value = is not related to the position of corresponding node in the ring, i.= e. the order of the nodes is not tied to nodes ID assignment. Each node has a ring topology map that associates a node=C6s ID w= ith its address. With respect to the Figures 1-1/2 the ring topology map is: TNE-ID TNE-Address 1 B 2 F 3 A 4 E 5 C 6 D Table 1-1 Ring Topology map The following tables represent the traffic matrix of the ring and= the squelching (for definition of squelching please refer to Section = 1.4) tables of the TNEs. +----------------------------------------------------------------= --+ | AU | <---- West Nodes East ---= ->| | Number | A B C D E F = A| +--------+-------------------------------------------------------= --+ | 1 | <--------> <------------------> = | | 2 | <-----------------------------> = | | 3 | <--------------------><-------------------------> = | +----------------------------------------------------------------= --+ Caviglia Expires - April 2006 [Page = 5] =0C draft-caviglia-ccamp-GMPLS-MSSPRing-Req-00 October= 2005 Table 1-2 Traffic Matrix +---------------------------------+------------------------------= --- TNE-A | TNE-B AU West East | AU West Ea= st Src Dst Src Dst | Src Dst Src = Dst 1 A B | 1 B A B = D 2 A D | 2 D A A = D 3 A C | 3 C A C = F ----------------------------------+------------------------------= ---- ----------------------------------+------------------------------= --- TNE-C | TNE-D AU West East | AU West Ea= st Src Dst Src Dst | Src Dst Src = Dst 1 D B B D | 1 D B B = D 2 D A A D | 2 D A A = D 3 C A C F | 3 F C C = F ----------------------------------+------------------------------= --- ----------------------------------+------------------------------= --- TNE-E | TNE-F AU West East | AU West Ea= st Src Dst Src Dst | Src Dst Src = Dst 1 | 1 2 | 2 3 F C C F | 3 F C C = F ----------------------------------+------------------------------= --- Table 1-3 Squelching Table When a node determines that a protection switch is required, it sources the appropriate bridge request using the APS protocol to = the node at the far end of the affected MS (for more details on how A= PS carries that information please refer to G.841 [4]). We=C6ll call Ring Map the sum of the information contained in all= the above Tables. 1.2 MS-SPRing Example The worker circuit follows this path (4_fibers/2_fibers): TNE-A <-Link W1/WP1-> TNE-B <-Link W2/WP2-> TNE-C <-Link W4/WP4->= TNE-D : AU Timeslot 1 Caviglia Expires - April 2006 [Page = 6] =0C draft-caviglia-ccamp-GMPLS-MSSPRing-Req-00 October= 2005 In four fibers scenario failure of Links W2 and P2 triggers the M= S- SPRing protection. Traffic is protected using this path: TNE-A <-Link W1-> TNE-B [Internal Bridge] <-Link P1-> TNE-A <-Lin= k P3-> TNE F <-Link P5-> TNE-E <-Link P6-> TNE-D <-Link P4-> TNE-C [Internal Bridge] <- Link W4 -> TNE-D: AU Timeslot 1. The following picture illustrates the state of the network after = the recovery, by means of MS-SPRing, of the failure. 1 TNE A v TNE B TNE C +----------|-+ +------------+ +-----------= -+ | | | | | | = | | +------------->----->----+ |XXXXXXXXXXXX| +--------+= | | | W1 | | | W2 | | |= | | |<-----------| | |XXXXXXXXXXXX| | |= | | | | v | | ^ v= | | |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| | |XX= XXXXXXXXXX| | | | | | P1 | | | P2 | | |= | | +--<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D-----<----+ |XX= XXXXXXXXXX| | | | | | | | | | | |= | +----------|-+ +------------+ +-|--------|= -+ ^ | ^ l ^ l ^ |= | | l l l l | |= | | l l l l | |= |W3| lP3l ------------ Working Link lP4l |W4|= | | l l llll and =3D=3D=3D Protection Link l l= | | | | l l l l | |= | v l v l v | v= +----------|-+ +------------+ +-|--------|= -+ | | | | | | | |= | | +--=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>------->------=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>--+ | | | | P5 | | P6 | |= | | |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D| |<=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D| | | | | | | | v= | | |----------->| |----------->| |= | | | W5 | | W6 | |= | | |<-----------| |<-----------| |= | | | | | | |= | +------------+ +------------+ +----------|= -+ TNE F TNE E TNE D v= 1= Figure 1-3: MS-SPRing four fibers ring-switching Caviglia Expires - April 2006 [Page = 7] =0C draft-caviglia-ccamp-GMPLS-MSSPRing-Req-00 October= 2005 The extra traffic in spans P1, P3, P4, P5 and P6 is affected. Note that in this case working traffic passes the same section tw= o times, i.e. link W1 and link P1, link P4 and link W4. If these sections are very long, e.g. in trans-oceanic applicatio= ns, the propagation delay is affected considerably and will result in= a degradation of performance. For trans-oceanic applications intermediate nodes, not adjacent t= o an affected section, will switch bridges as well. Traffic is now protected using this path: TNE-A [Internal Bridge] TNE-A <-Link P3-> TNE F <-Link P5-> TNE-E= <- Link P6-> TNE-D [Internal Bridge] TNE-D: AU Timeslot 1. The following picture illustrates the state of the network after = the recovery, by means of trans-oceanic MS-SPRing, of the failure. 1 TNE A v TNE B TNE C +----------|-+ +------------+ +-----------= -+ | | | | | | = | | | |----------->| |XXXXXXXXXXXX| = | | | | W1 | | W2 | = | | | |<-----------| |XXXXXXXXXXXX| = | | v | | | | = | | | |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| |XX= XXXXXXXXXX| | | | | P1 | | P2 | = | | | |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D| |XX= XXXXXXXXXX| | | | | | | | = | +----------|-+ +------------+ +-----------= -+ ^ | ^ l ^ l ^ |= | | l l l l | |= | | l l l l | |= |W3| lP3l ------------ Working Link lP4l |W4|= | | l l llll and =3D=3D=3D Protection Link l l= | | | | l l l l | |= | v l v l v | v= +----------|-+ +------------+ +-----------= -+ | | | | | | = | | +--=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>------->------=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>------>----+ | | | P5 | | P6 | |= | | |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D| |<=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D| | | | | | | | v= | | |----------->| |----------->| |= | | | W5 | | W6 | |= | | |<-----------| |<-----------| |= | | | | | | |= | +------------+ +------------+ +----------|= -+ Caviglia Expires - April 2006 [Page = 8] =0C draft-caviglia-ccamp-GMPLS-MSSPRing-Req-00 October= 2005 TNE F TNE E TNE D v= 1= Figure 1-4: MS-SPRing four fibers trans-oceanic ring-switchin= g Only the extra traffic in spans P3, P5 and P6 is affected. Instead of bridging all working traffic to the protections channe= ls in the nodes adjacent to the failure in trans-oceanic ring-switch= ing the individual AU tributaries are switched in their ingress and egress nodes using ring maps and APS information. Due to the tran= sfer and evaluation of the information more time is required for the protection switch to complete, the objective is 300 ms or less. Because tributaries are switched in their ingress and egress node= s no squelching is required and protection channels not required for protection may carry pre-empted extra traffic. A mechanism is required to auto-provision the ring maps and maint= ain their consistency. In two fibers scenario failure of Links W2 and P2 triggers the MS= - SPRing protection. Traffic is protected using this path: TNE-A <-Link WP1-> TNE-B [Internal Bridge] <-Link WP1-> TNE-A <-L= ink WP3-> TNE F <-Link WP5-> TNE-E <-Link WP6-> TNE-D <-Link WP4-> TN= E-C [Internal Bridge] <- Link WP4 -> TNE-D: AU Timeslot 1 is used on = all the links. The following picture illustrates the state of the network after = the recovery from the failure done by means of MS-SPRing mechanism. | TNE A v TNE B TNE C +------------+ +------------+ +-----------= -+ | | | | | | = | | | | | | | = | | | | | | | = | | +-|----------->|------+ |xxxxxxxxxxx>| +-----+ = | | | WP1 | | | WP2 | | | = | | +----|<-----------|------+ |<-----------| ^ v = | | | | | | | | | = | | | | | | | | | = | | | | | | | | | = | +------------+ +------------+ +-----------= -+ ^ | ^ | | | | | | | | | | WP3 | WP Links Resources are | WP4 | Caviglia Expires - April 2006 [Page = 9] =0C draft-caviglia-ccamp-GMPLS-MSSPRing-Req-00 October= 2005 | | 50% Worker | | | | 50% Protection | | | v | v +------------+ +------------+ +-----------= -+ | | | | | | | | = | | | | | | | | | = | | | | | | | | | = | | +----|----------->|------------|----------->|---+ | = | | | WP5 | | WP6 | | = | | |<-----------| |<-----------| | = | | | | | | | = | | | | | | | = | | | | | | | = | +------------+ +------------+ +-----------= -+ TNE F TNE E TNE D v Figure 1-5: MS-SPRing two fibers ring-switching Figure 1-3 and 1-5 illustrates the so-called =F4ring-switching=F6= protection. In four-fiber MS-SPRing there exists also =F4span-switching=F6 an= d in this case only the working fibers are cut while the protection fi= bers remain intact. See figure 1-6. The protection switch affects the extra traffic in span P2. 1 TNE A v TNE B TNE C +----------|-+ +------------+ +-----------= -+ | | | | | | = | | +------------->----->----+ |XXXXXXXXXXXX| +--------+= | | | W1 | | | W2 | | |= | | |<-----------| v |XXXXXXXXXXXX| ^ |= | | | | | | | | |= | | |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| +---=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>--+ v | | | P1 | | P2 | |= | | |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D| |<=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D| | | | | | | | |= | +------------+ +------------+ +----------|= -+ ^ | ^ l ^ l ^ |= | | l l l l | |= | | l l l l | |= |W3| lP3l ------------ Working Link lP4l |W4|= | | l l llll and =3D=3D=3D Protection Link l l= | | | | l l l l | |= | v l v l v | v= +------------+ +------------+ +----------|= -+ | | | | | |= | | |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| |=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| | | Caviglia Expires - April 2006 [Page 1= 0] =0C draft-caviglia-ccamp-GMPLS-MSSPRing-Req-00 October= 2005 | | P5 | | P6 | |= | | |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D| |<=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D| | | | | | | | v= | | |----------->| |----------->| |= | | | W5 | | W6 | |= | | |<-----------| |<-----------| |= | | | | | | |= | +------------+ +------------+ +----------|= -+ TNE F TNE E TNE D v= 1= Figure 1-6: MS-SPRing span-switch 1.3 Time Slot Interchange (TSI) TSI is the connection function capability of changing the time sl= ot position of through-connected traffic (i.e. traffic that is not a= dded or dropped from the node). At present there is no TSI capability specified in nodes belonging to a MS-SPRing sub network. Channels= at MS-SPRing node=C6s egress are nailed to the same timeslot used by= the same channels at node=C6s ingress. This is a currently required condition to ensure MS-SPRing correct operation. 1.4 Squelching Squelching is defined as the process of inserting AU-AIS in order= to prevent misconnections. The squelching process application over traffic results in an =F4all 1=C6s=F6 signal. 1.4.1 Squelching to avoid misconnected traffic To perform a ring switch, the protection channels are essentially= shared among each span of the ring. Also, extra traffic may resid= e in the protection channels when the protection channels are not currently being used to restore normal traffic transported on the= working channels. Thus, each protection channel time slot is subj= ect to use by multiple services (services from the same time slot but= on different spans, and service from extra traffic). With no extra traffic on the ring, under certain multiple point failures, such = as those that cause node(s) isolation, services (from the same time = slot but on different spans) may contend for access to the same protec= tion channel time slot. This yields a potential for misconnected traff= ic. With extra traffic on the ring, even under single point failures,= normal traffic on the working channels may contend for access to = the same protection channel time slot that carries the extra traffic.= This also yields a potential for misconnected traffic. Without a mechanism to prevent misconnection, the following failu= re scenario would yield misconnections. Caviglia Expires - April 2006 [Page 1= 1] =0C draft-caviglia-ccamp-GMPLS-MSSPRing-Req-00 October= 2005 Referring to Figure 1-1, two circuits traverse the MS-SPRing name= ly circuit Q and R the path that they traverse is: Circuit R: TNE-A <-Link WP3 AU 1-> TNE-F Circuit Q: TNE-A <-Link WP1 AU 1-> TNE-B <-Link WP2 AU 1-> TNE-C= = Suppose a cut in both the spans between nodes A and F and between= nodes A and B (isolating node A, that is the same as a TNE A fail= ure) causes circuits Q and R to attempt to access time slot #1P on the= protection channels. The mechanism for the MS-SPRing protection = is as depicted in previous sub-section. A potential misconnection is determined by identifying the nodes = that will act as the switching nodes for a bridge request, and by examining the traffic that will be affected by the switch. The switching nodes can be determined from the node addresses in the = K1 and K2 bytes. The switching nodes determine the traffic affected = by the protection switch from the information contained in their rin= g maps and from the identifications of the switching nodes. Potenti= al misconnections shall be squelched by inserting the appropriate AU= -AIS in those time slots where misconnected traffic could occur. Specifically, the traffic that is sourced or dropped at the node(= s) isolated from the ring by the failure shall be squelched. For rin= gs operating at an AU-4 level, this squelching occurs at the switchi= ng nodes. AU level squelching occurs for the normal or extra traffic= into or out of the protection channels (i.e. normal traffic into = or out of working channels is never squelched). For example, consider a segment of a ring consisting of three nod= es, A, B, and C where B has failed. In a typical scenario, both A and= C will send bridge requests destined for B. When A sees the bridge request from C, and sees that B is between A and C (from the node= map) it can deduce that B is isolated from the ring. A and C will= use their respective maps to find out which channels are added or dro= pped by B. A and C will squelch these channels before the ring switch = is performed by inserting AU-AIS. Thus, any node on the ring that wa= s connected to B will now receive AIS on those channels. Each of the ring maps, then, shall contain at minimum: 1. a ring map that contains information regarding the order in wh= ich the nodes appear on the ring; 2. a cross-connect map that contains the AU-4 time-slot assignmen= ts for traffic that is both terminated at that node and passed- through that node; 3. a squelch table that contains, for each of these AU-4 time slo= ts, the node addresses at which the traffic enters and exits the r= ing; and Caviglia Expires - April 2006 [Page 1= 2] =0C draft-caviglia-ccamp-GMPLS-MSSPRing-Req-00 October= 2005 4. an optional indication of whether the AU is being accessed at = the lower order VC level somewhere on the ring (not covered by thi= s Document) An example of such ring maps and squelching table is given in Sec= tion 1.1. 2. GMPLS requirements imposed by MS-SPRing When setting up (either via traditional management plane actions = or via GMPLS control plane protocols) a data plane circuit going acr= oss parts of the network that include MS-SPRing based protection mechanism, it MUST be done according to MS-SPRing specific needs = as explained in previous sections. 2.1 LSP Set-Up When GMPLS is used for circuit setup, the presence of MS-SPRing r= ings in the network results in a set of requirements that have to be handled at control plane level. Basically when setting up an LSP over a data plane that includes = TNEs connected in MS-SPRing scheme, the control plane taking care of routing and signaling of such LSP has to behave in a way that 1. the label(corresponding to a SDH/SONET timeslot) must not be changed within the MS-SPRing ring traversed; 2. involved TNE MUST have all the information necessary to fill t= he Ring Map. From the NMS point of view it is important to be able to univocal= ly identify a ring in the network, this leads to the Ring Identifier= (RingId) concept. Even if the RingId is not needed for the MS-SP= Ring operation it is needed for management issues. Given the above there is the requirement to add the RingId information to the information stored when an LSP traverses a nod= e that is part of a MS-SPRing. The above requirements can be satisfied either via signaling only= or signaling plus routing. 2.2 Data Plane and Control Plane misalignment When a failure affects an LSP that traverse an MS-SPRing protecte= d ring the data plane scenario is the same as in Figure 1-3. Data Traffic is flowing through: Node-A<-->Node-B<-->Node-A<-->Node-F<-->Node-E<-->Node-D<-->Node-= C<-- >Node-D while from a control plane perspective traffic is still flowing through Node-A<-->Node-B<-->Node-C<-->Node-D. It may be noted that the loop Node-A<-->Node-B<-->Node-A can be Caviglia Expires - April 2006 [Page 1= 3] =0C draft-caviglia-ccamp-GMPLS-MSSPRing-Req-00 October= 2005 bridged and releases the protection channels for use by extra tra= ffic thus increasing the availability of extra traffic, however this requires an update to the Ring map. The misalignment between control and data plane arises because th= e control plane is un-aware of the failure. In this case there is the need for a control plane data plane re-= alignment. When, without the intervention of the control plane, inherent protection scheme changes some characteristic of an LSP there sho= uld be a communication mechanism that re-aligns control plane and dat= a plane information. 2.3 Interworking between GMPLS restoration and MS-SPRing Protection A hold-off timer e.g. 50 ms should be provided in order to allow = MS- SPRing protection to react firstly to a failure. In case of failures unrecoverable by MS-SPRing the hold-off elaps= e triggering the control plane recovery mechanism, of course in ord= er to recover the traffic control plane and data plane must be align= ed, see above Section about control plane and data plane misalignment= . 3. Security Considerations This document does not introduce any additional Security issues. References [1] Mannie, E. =F6Generalized Multi-Protocol Label Switching (GMP= LS) Architecture=F6 Standard Track, RFC 3945, October 2004 [2] ITU-T G.707 =F4Network node interface for the synchronous dig= ital hierarchy (SDH)=F6, December 2003 [3] ITU-T G.841 "Types and characteristics of SDH network protect= ion architectures", October 1998. [4] Bradner, S., "The Internet Standards Process -- Revision 3", = BCP 9, RFC 2026, October 1996 Caviglia Expires - April 2006 [Page 1= 4] =0C draft-caviglia-ccamp-GMPLS-MSSPRing-Req-00 October 20= 05 Acknowledgments Greg Bernstein Grotto Networking Email: gregb@grotto-networking.com Author's Addresses Diego Caviglia Marconi V. A. Negrone 16/A 16153 Cornigliano (GE) Italy Phone: +390106003736 Email: diego.caviglia@Marconi.com Huub van Helvoort Huawei Technologies Ltd. Kolkgriend 38 NL-1356 BC Almere the Netherlands Phone: +31365315076 Email: hhelvoort@chello.nl Intellectual Property Rights Notices The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed t= o pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information= on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use o= f such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository a= t http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Caviglia Expires - April 2006 [Page 15] =0C draft-caviglia-ccamp-GMPLS-MSSPRing-Req-00 October 20= 05 Full Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on a= n "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENT= S OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Caviglia Expires - April 2006 [Page 16] = _______________________________________________ MTER mailing list MTER@ietf.org https://www1.ietf.org/mailman/listinfo/mter From mter-bounces@ietf.org Wed May 17 09:50:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgMPZ-0002M4-3N; Wed, 17 May 2006 09:50:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgMPY-0002Lz-L8 for mter@ietf.org; Wed, 17 May 2006 09:50:00 -0400 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgMPV-0001w0-QN for mter@ietf.org; Wed, 17 May 2006 09:50:00 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 May 2006 15:49:55 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 17 May 2006 15:50:03 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: THREAD 2 - Combining IGP Fast Covnergence and Graceful Restart Thread-Index: AcZ4TyUc/+Ddyg8MStiIB2dPZFLb/wBOB6yQ From: "LE ROUX Jean-Louis RD-CORE-LAN" To: X-OriginalArrivalTime: 17 May 2006 13:49:55.0424 (UTC) FILETIME=[C779F600:01C679B8] X-Spam-Score: 0.2 (/) X-Scan-Signature: c375f2012a4f820b0c0fd6fb14a28357 Cc: Subject: [Mter] THREAD 2 - Combining IGP Fast Covnergence and Graceful Restart X-BeenThere: mter@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-TEchnology Recovery List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0092836602==" Errors-To: mter-bounces@ietf.org This is a multi-part message in MIME format. --===============0092836602== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C679B8.C73E4441" This is a multi-part message in MIME format. ------_=_NextPart_001_01C679B8.C73E4441 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi folks, =20 Let's start discussion on scenario 2 =3D Combining IGP Fast Convergence and IGP Graceful Restart (section 5.2 of draft-ahmad-mter-problem-statement-00.txt) =20 Comments on this scenario are required. In particluar your feedback on these two points would be really useful: -Is there a need for a mechanism that would allow to rapidly make a clear distinction between control plane failures and data plane failures?=20 Such mechanism may be considered to efficiently handle this MTER scenario.=20 -Is there a need for a MIB allowing to monitor such interaction: -e.g. record cases where a GR procedure has failed, leading to increasing convergence time of the IGP -Monitor GR performances in order to be able to tune more aggressively IGP timers=20 =20 Regards, =20 JL, JP and Raymond. =20 =20 From: JP Vasseur Date: May 15, 2006 1:09:02 PM EDT To: mter@ietf.org Cc: raymond_zhang@bt.infonet.com Subject: [Mter] Need to decide on potential next steps for MTER Hi, =09 =09 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. =09 =09 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. =09 =09 Thanks. =09 =09 JP, Jean-Louis and Raymond. =09 =09 =09 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 ------_=_NextPart_001_01C679B8.C73E4441 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Hi folks,
 
Let's start discussion on scenario 2 =3D = Combining IGP=20 Fast Convergence and IGP Graceful Restart
(section 5.2 of=20 draft-ahmad-mter-problem-statement-00.txt)
 
Comments on this scenario are=20 required.
In particluar your feedback on these two = points would=20 be really useful:
-Is there a need for a mechanism = that would=20 allow to rapidly make a clear distinction between control plane = failures=20 and data plane failures?
Such mechanism may be considered to = efficiently=20 handle this MTER scenario.
-Is there a need for a MIB allowing to=20 monitor such interaction:
     -e.g. record = cases where=20 a GR procedure has failed, leading to increasing convergence time = of the=20 IGP
     -Monitor GR = performances=20 in order to be able to tune more aggressively IGP=20 timers 
 
Regards,
 
JL, JP and Raymond.
 
 
From: JP Vasseur = <jvasseur@cisco.com>
Date: May 15, = 2006 1:09:02 PM=20 EDT
To: mter@ietf.org
Cc: raymond_zhang@bt.infonet.com=
Subject: = [Mter] = Need to decide=20 on potential next steps for MTER

Hi,
Below the email=20 we sent to the list some time ago, seeking for feed-backs but so far = the=20 list has been pretty quiet. During the past few months we received a = very=20 few off-line positive feed-backs indicating some interest in this = work. It=20 is now a good time to decide on whether there is enough interest to = work on=20 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=20 work.
So = we will=20 follow up with a few discussion threads related to the scenarios = described=20 in the problem statement ID, for which we'd like to get your = feed-back=20 relatively quickly, should you think that it is worth being=20 pursed.
Thanks.
JP, Jean-Louis=20 and Raymond.
Hi,

It = took a little=20 while to come up with a clear problem statement but we now have an = I-D=20 (http://www.ietf.org/internet-drafts/draft-ahmad- mter-problem-statement-00.txt (thanks to = the=20 authors)) that will hopefully trigger some discussion with the = objective to=20 see whether there is enough interest to pursue this work at the=20 IETF.

The draft has=20 been structured so as to first show three scenarios where various = recovery=20 mechanisms could be used in combination. This does not aim to cover = all=20 possible cases but some pretty common deployment scenario for the = sake of=20 illustration. Then various Multi- TEchnology Recovery (MTER) issues = are=20 discussed.

What is the=20 objective of this work ?

Let's start with=20 the set of non-objective first ...
* = There is no=20 intention to come up with protocols extensions that are being worked = out in=20 existing WGs (ISIS, IDR, CCAMP, ....)
* = Discuss=20 implementation-specific issues

Now the=20 objectives ...

What has been=20 shown through the three MTER deployment cases making use of multiple = recovery mechanisms in combination is the = following:

-> There are=20 cases where being able to identify the root failure cause would=20 significantly improve various recovery metrics such as the = convergence time,=20 required backup capacity, ... and so on. Do we need to work on such=20 mechanisms at the IETF is an open question ?

-> MIBs and=20 OAM tools have been defined for most of the recovery techniques = (IGP, BGP,=20 MPLS FRR, GMPLS, ... ) and there are clearly no such tool for the = aspects=20 related to their combined use. It looks like the availability of = such tools=20 would help Service Providers to manage, tune and troubleshooting = their=20 network. Again, feed-backs from this ML are critical to see how to = move=20 forward and if the community expressed some = interest.

Thanks for your=20 feed-backs.

JP, Jean-Louis=20 and Raymond.

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

------_=_NextPart_001_01C679B8.C73E4441-- --===============0092836602== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MTER mailing list MTER@ietf.org https://www1.ietf.org/mailman/listinfo/mter --===============0092836602==-- From mter-bounces@ietf.org Wed May 24 15:00:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fiyb3-0003h9-SB; Wed, 24 May 2006 15:00:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fiyb2-0003h1-AY for mter@ietf.org; Wed, 24 May 2006 15:00:40 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fiyb1-0008SN-1V for mter@ietf.org; Wed, 24 May 2006 15:00:40 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 24 May 2006 15:00:12 -0400 X-IronPort-AV: i="4.05,169,1146456000"; d="scan'208,217"; a="89379412:sNHT336538910" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k4OJ0ETL003913; Wed, 24 May 2006 15:00:14 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 24 May 2006 15:00:11 -0400 Received: from [161.44.71.181] ([161.44.71.181]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 24 May 2006 15:00:10 -0400 Mime-Version: 1.0 (Apple Message framework v750) To: mter@ietf.org Message-Id: From: JP Vasseur Date: Wed, 24 May 2006 15:00:08 -0400 X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 24 May 2006 19:00:10.0766 (UTC) FILETIME=[47F9FAE0:01C67F64] X-Spam-Score: 0.2 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: raymond_zhang@bt.infonet.com Subject: [Mter] MTER - Status ... X-BeenThere: mter@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-TEchnology Recovery List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0956921043==" Errors-To: mter-bounces@ietf.org --===============0956921043== Content-Type: multipart/alternative; boundary=Apple-Mail-43-538800407 --Apple-Mail-43-538800407 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, This mailing list was originally set up in order to evaluate the potential interest of the IETF community for the topic of Multi- TEchnology Recovery (MTER) as a follow up of off-line discussions that we had with several of you. A problem statement was published (http://www.ietf.org/internet-drafts/draft-ahmad-mter-problem- statement-00.txt). Since the list has been very quiet although a number of people had registered, it is probably safe to assume that there is not enough interest at this point to proceed further and request for a BOF. Thanks. JP, Jean-Louis and Raymond. --Apple-Mail-43-538800407 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi,

This mailing list = was originally set up in order to evaluate the potential interest of the = IETF community for the topic of Multi-TEchnology Recovery (MTER) as a = follow up of off-line discussions that we had with several of you. A = problem statement was published (http://www.ietf.org/internet-drafts/draft-ahmad-mter-problem-= statement-00.txt).=A0
Since the list has = been very quiet although a number of people had registered, it is = probably safe to assume that there is not enough interest at this point = to proceed further and request for a BOF.

Thanks.

JP, Jean-Louis and = Raymond.
= --Apple-Mail-43-538800407-- --===============0956921043== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MTER mailing list MTER@ietf.org https://www1.ietf.org/mailman/listinfo/mter --===============0956921043==--