RE: [Mter] Any news?

"Diego Caviglia" <Diego.Caviglia@marconi.com> Wed, 15 March 2006 11:38 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJUL0-0005no-Mf; Wed, 15 Mar 2006 06:38:46 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJUL0-0005nj-Av for mter@ietf.org; Wed, 15 Mar 2006 06:38:46 -0500
Received: from smtpoutuk02.marconi.com ([128.87.251.113]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJUKz-00069t-TT for mter@ietf.org; Wed, 15 Mar 2006 06:38:46 -0500
Received: from cvdgwy01.uk.marconicomms.com (cvis26.uk.marconicomms.com [128.87.251.109]) by smtpoutuk02.marconi.com (8.12.11/8.12.11) with ESMTP id k2FBalkk030179; Wed, 15 Mar 2006 11:38:39 GMT (envelope-from Diego.Caviglia@marconi.com)
Sensitivity:
Subject: RE: [Mter] Any news?
To: jeanlouis.leroux@francetelecom.com
X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003
Message-ID: <OF3F9BE37D.B0C9B639-ONC1257132.003CDF1C-C1257132.003F03D9@uk.marconicomms.com>
From: Diego Caviglia <Diego.Caviglia@marconi.com>
Date: Wed, 15 Mar 2006 12:28:16 +0100
X-MIMETrack: Serialize by Router on CVDGWY01/S/EXT/MC1(5012HF354 | August 26, 2003) at 15/03/2006 11:38:38
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: 36b1f8810cb91289d885dc8ab4fc8172
Cc: "<mter" <mter@ietf.org>
X-BeenThere: mter@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Multi-TEchnology Recovery <mter.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mter>, <mailto:mter-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/mter>
List-Post: <mailto:mter@ietf.org>
List-Help: <mailto:mter-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mter>, <mailto:mter-request@ietf.org?subject=subscribe>
Errors-To: mter-bounces@ietf.org

Hi Jean-Louis,
               actually I'm interested in interworking between data plane
protection and control plane recovery mechanism.

My major concern on that issue is the interworking between the MS-SPRing
and GMPLS recovery.

Section 5.3.1 states that:
  "Note that some data plane recovery mechanisms such as the SONET/SDH
   protection mechanism may co-exist with GMPLS P&R mechanisms. The co-
   existence with data plane recovery and GMPLS recovery mechanisms is
   not addressed in this section."

Moreover
"7. Future items

   Here is a non exhaustive set of additional items that need to be
   covered as part of the MTER work:
    - Other combinations of recovery techniques (e.g. BGP-IGP
      interactions, IGP-IPFRR interactions, etc.);
    - Superset of elementary combinations (e.g IGP Fast Convergence for
      node data plane failures + Graceful Restart for node control plane
      failures + MPLS FRR link protection for link failures).
   -  Combination of recovery techniques to protect distinct traffics
      (e.g. IGP Fast convergence and end-to-end MPLS-TE recovery); "

Is the interworking between 'data palane' protection scheme and GMPLS
recovery mechanism in the scope of MTER?

My vote on that question is yes, that issue needs to be addressed.

Huub Dino and myself have written a requirement ID about the interworking
between MS-SPRing and GMPLS
(http://www1.ietf.org/internet-drafts/draft-caviglia-ccamp-gmpls-msspring-req-00.txt),
 is that work in the scope of MTER?  My last impression was that was in the
scope, is that impression correct?

Section 6.1 quotes AIS as possible mechanism to detect failures.

Is the following possible issue in the scope of MTER (actually is a
partitioning problem rather that a layer problem)

a<--------->b<--------->c<------->D<--------->E<---------->F<---------->G<-------->h<---------->i<-------->z

Caps letters indicates GMPLS capable nodes while the low caps are legacy
SDH/SONET nodes.

One can say that D, E, F, G is the backbone network while a, b, c and h, i,
z are two access network.

A network operator wants to set up a trail fom a to z, we can see that
trail made by three pieces:
1)    a<----->D
2)    D<----->G
3)    G<----->z

Pieces 1 and 3 are set-up via NMS and are not under the control of the
GMPLS while piece 2 is an e2e restored circuit.

If the AIS is used as trigger for the GMPLS restoration a failure in either
piece 1 or 2 (that injects AIS along all the trail) can trigger the e2e
GMPLS recovery scheme.  Given that the failure is not recoverable inside
the piece 2, the risk is that restoration never ends.

Regards

Diego





"LE ROUX Jean-Louis RD-CORE-LAN" <jeanlouis.leroux@francetelecom.com> on
15/03/2006 11.45.00

To:    "Diego Caviglia" <Diego.Caviglia@marconi.com>, <mter@ietf.org>
cc:

Subject:    RE: [Mter] Any news?

Hi Diego,

We are actually waiting for comments on the problem statement,
so feel free to comment!

Regards,

JL

> -----Message d'origine-----
> De : Diego Caviglia [mailto:Diego.Caviglia@marconi.com]
> Envoyé : mercredi 15 mars 2006 11:37
> À : mter@ietf.org
> Objet : [Mter] Any news?
>
> Hi all,
>              any news on the MTER activity?
>
> Regards
>
> Diego
>
> PS are there any ID apart the problem statement?
>
>
>
> _______________________________________________
> 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







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