IETF Logo Mail Archive

Re: [mpls] [mpls-tp] Last Call: draft-ietf-mpls-tp-survive-fwk (Multiprotocol Label Switching Transport Profile Survivability Framework) to Informational RFC

"Sprecher, Nurit (NSN - IL/Hod HaSharon)" <nurit.sprecher@nsn.com> Mon, 26 April 2010 18:05 UTC

Return-Path: <nurit.sprecher@nsn.com>
X-Original-To: mpls@core3.amsl.com
Delivered-To: mpls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 517DE28C20D; Mon, 26 Apr 2010 11:05:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.216
X-Spam-Level:
X-Spam-Status: No, score=-1.216 tagged_above=-999 required=5 tests=[AWL=-0.107, BAYES_05=-1.11, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jEurC8ssl4X1; Mon, 26 Apr 2010 11:05:00 -0700 (PDT)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 3B13A28C1FD; Mon, 26 Apr 2010 11:05:00 -0700 (PDT)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o3QI4hsR001898 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 26 Apr 2010 20:04:43 +0200
Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o3QI4hhp007314; Mon, 26 Apr 2010 20:04:43 +0200
Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Apr 2010 20:04:43 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAE56A.F26F41DA"
Date: Mon, 26 Apr 2010 20:04:38 +0200
Message-ID: <077E41CFFD002C4CAB7DFA4386A532640217BCC6@DEMUEXC014.nsn-intra.net>
In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD693F03BB408@SJEXCHCCR02.corp.ad.broadcom.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [mpls-tp] Last Call: draft-ietf-mpls-tp-survive-fwk (Multiprotocol Label Switching Transport Profile Survivability Framework) to Informational RFC
thread-index: AcrlEKMJKW4co4rgQzWwQkyryVUYFgAVcNFgAAAz9YA=
References: <FD5A8004D1C845CE852F2349DAA15935@your029b8cecfe><OF7C053C4F.50B60391-ON48257711.0027594D-48257711.0027B4F9@zte.com.cn> <2C2F1EBA8050E74EA81502D5740B4BD693F03BB408@SJEXCHCCR02.corp.ad.broadcom.com>
From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <nurit.sprecher@nsn.com>
To: ext Shahram Davari <davari@broadcom.com>, mpls@ietf.org, mpls-tp@ietf.org
X-OriginalArrivalTime: 26 Apr 2010 18:04:43.0085 (UTC) FILETIME=[F279E7D0:01CAE56A]
Cc: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <nurit.sprecher@nsn.com>
Subject: Re: [mpls] [mpls-tp] Last Call: draft-ietf-mpls-tp-survive-fwk (Multiprotocol Label Switching Transport Profile Survivability Framework) to Informational RFC
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Apr 2010 18:05:06 -0000

Hi Shaharm,

I cannot recall that we used the statement exactly as appears below, but
in principle this is correct.  RFC 4873
<http://datatracker.ietf.org/doc/rfc4873/>  provides a solution for
segment protection, without using a PST. 

The draft is a framework and it introduces various elements of control
to trigger the recovery action (e.g. OAM signaling, network failure
detection, control-plane signaling, administrative commands, etc.),
different levels of recovery, different mechanisms, etc. 

It is correct that in order to monitor a segment of a path using OAM we
need a PST, because OAM messages may be initiated only by MEPs which
reside at the endpoints of a path. But there other elements of controls
that can be used as well and the framework introduce them as well. RFC
4873 for example makes use of the control-plane signaling to trigger a
recovery. 

Best regards,

Nurit

 

P.S. please note that FRR is limited in its applicability as it handles
uni-directional protection switching only!

 

 

From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On
Behalf Of ext Shahram Davari
Sent: Monday, April 26, 2010 8:36 PM
To: mpls@ietf.org; mpls-tp@ietf.org
Subject: Re: [mpls-tp] Last Call: draft-ietf-mpls-tp-survive-fwk
(Multiprotocol Label Switching Transport Profile Survivability
Framework) to Informational RFC

 

Hi,

 

I have a comment regarding this draft.

 

This draft states that an MPLS-TP tunnel can be protected in one of its
segments without use of a PST. This I assume is something similar to FRR
detour protection. What is not clear in the draft is how is OAM (and not
control plane) used to detect failure so that an intermediate node can
perform protection. As we know an intermediate node can't initiate BFD.

 

Thanks,

Shahram

v2.23.0 | Report a Bug | By Email