THREAD 1 - Fwd: [Mter] Need to decide on potential next steps for MTER

[JP Vasseur <[e-mail]>]

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 <[e-mail]>
> Date: May 15, 2006 1:09:02 PM EDT
> To: [e-mail]
> Cc: [e-mail]
> 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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/mter

_______________________________________________
MTER mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mter