[mpls-tp] BFD sessions wrt protection types
Lavanya Srivatsa <lavanya.srivatsa@aricent.com> Wed, 09 June 2010 11:45 UTC
Return-Path: <lavanya.srivatsa@aricent.com>
X-Original-To: mpls-tp@core3.amsl.com
Delivered-To: mpls-tp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix)
with ESMTP id AABDC28C0F6 for <mpls-tp@core3.amsl.com>;
Wed, 9 Jun 2010 04:45:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.002
X-Spam-Level:
X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[AWL=-0.001,
BAYES_50=0.001, 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 oT0TBlV4XLhL for
<mpls-tp@core3.amsl.com>; Wed, 9 Jun 2010 04:45:11 -0700 (PDT)
Received: from jaguar.aricent.com (jaguar.aricent.com [121.241.96.11]) by
core3.amsl.com (Postfix) with ESMTP id 4B5B03A6830 for <mpls-tp@ietf.org>;
Wed, 9 Jun 2010 04:45:10 -0700 (PDT)
Received: from jaguar.aricent.com (localhost [127.0.0.1]) by postfix.imss71
(Postfix) with ESMTP id 6BA2336BA6 for <mpls-tp@ietf.org>;
Wed, 9 Jun 2010 17:15:04 +0530 (IST)
Received: from GUREXHT01.ASIAN.AD.ARICENT.COM (gurexht01.asian.ad.aricent.com
[10.203.171.136]) by jaguar.aricent.com (Postfix) with ESMTP id 5619636B8D
for <mpls-tp@ietf.org>; Wed, 9 Jun 2010 17:15:04 +0530 (IST)
Received: from GUREXMB02.ASIAN.AD.ARICENT.COM ([10.203.171.134]) by
GUREXHT01.ASIAN.AD.ARICENT.COM ([10.203.171.137]) with mapi;
Wed, 9 Jun 2010 17:15:08 +0530
From: Lavanya Srivatsa <lavanya.srivatsa@aricent.com>
To: MPLS TP <mpls-tp@ietf.org>
Date: Wed, 9 Jun 2010 17:15:07 +0530
Thread-Topic: BFD sessions wrt protection types
Thread-Index: AcsHyTVFfLyTNt2fR5mS6ReefWpUvQ==
Message-ID: <AF085525D89CCA4EB233BE7E5BF2FDAB1693EBA7AF@GUREXMB02.ASIAN.AD.ARICENT.COM>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative;
boundary="_000_AF085525D89CCA4EB233BE7E5BF2FDAB1693EBA7AFGUREXMB02ASIA_"
MIME-Version: 1.0
Subject: [mpls-tp] BFD sessions wrt protection types
X-BeenThere: mpls-tp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: MPLS-TP Mailing list <mpls-tp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mpls-tp>,
<mailto:mpls-tp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls-tp>
List-Post: <mailto:mpls-tp@ietf.org>
List-Help: <mailto:mpls-tp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls-tp>,
<mailto:mpls-tp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Jun 2010 11:45:14 -0000
All, When the draft-ietf-mpls-tp-cc-cv-rdi states: "A single bi-directional BFD session is used for fate sharing operation. Two independent BFD sessions are used for independent operation. .... The normal usage is that 1:1 protected paths must use fate sharing, and independent operation applies to 1+1 protected paths." Does this mean that every time (and whenever it is done so) the protection switching architecture is changed by configuration/administrator from one to the other, the number of BFD sessions must change? Changing BFD sessions would include tear down or new setup of sessions? Since protection switching is an "application" that uses the OAM functionality to protect traffic, why should the "underlying" OAM operation be disturbed just because the "application" above it undergoes a change? I am unable to understand the dependency of the number of BFD-OAM sessions based on the protection switching architectures/types. Can somebody please clarify? - Lavanya
- [mpls-tp] BFD sessions wrt protection types Lavanya Srivatsa
- Re: [mpls-tp] BFD sessions wrt protection types David Allan I
- Re: [mpls-tp] BFD sessions wrt protection types Maarten Vissers
- Re: [mpls-tp] BFD sessions wrt protection types Lavanya Srivatsa
- Re: [mpls-tp] BFD sessions wrt protection types John E Drake
- Re: [mpls-tp] BFD sessions wrt protection types John E Drake