Re: [mpls-tp] FW: CC/CV/RDI nee RE: [mpls] [PWE3] [AHMPLS-TP] Re: pollondraft-he-mpls-tp-csf-03.txt
Alexander Vainshtein <Alexander.Vainshtein@ecitele.com> Thu, 02 December 2010 20:43 UTC
Return-Path: <Alexander.Vainshtein@ecitele.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 E25883A69ED for <mpls-tp@core3.amsl.com>;
Thu, 2 Dec 2010 12:43:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.451
X-Spam-Level:
X-Spam-Status: No, score=-2.451 tagged_above=-999 required=5 tests=[AWL=0.147,
BAYES_00=-2.599, 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 XQYtKXHuyyT2 for
<mpls-tp@core3.amsl.com>; Thu, 2 Dec 2010 12:43:07 -0800 (PST)
Received: from ilptbmg01.ecitele.com (ilptbmg01-out.ecitele.com
[147.234.242.234]) by core3.amsl.com (Postfix) with ESMTP id E23E03A69EB for
<mpls-tp@ietf.org>; Thu, 2 Dec 2010 12:43:05 -0800 (PST)
X-AuditID: 93eaf2e7-b7ca6ae000000bc0-6e-4cf805267ba6
Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by
ilptbmg01.ecitele.com (Symantec Brightmail Gateway) with SMTP id
9E.E3.03008.62508FC4; Thu, 2 Dec 2010 22:44:22 +0200 (IST)
Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by
ilptexch01.ecitele.com ([172.31.244.40]) with mapi;
Thu, 2 Dec 2010 22:44:19 +0200
From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
To: John E Drake <jdrake@juniper.net>
Date: Thu, 2 Dec 2010 22:42:51 +0200
Thread-Topic: [mpls-tp] FW: CC/CV/RDI nee RE: [mpls] [PWE3] [AHMPLS-TP] Re:
pollondraft-he-mpls-tp-csf-03.txt
Thread-Index: AcuSUijDlkvmD4zSSVekx1DLid71qAAAMbZwAADUZxAAAtnW4g==
Message-ID: <A3C5DF08D38B6049839A6F553B331C76D6B78ED54E@ILPTMAIL02.ecitele.com>
References: <5E893DB832F57341992548CDBB33316398C549E2C2@EMBX01-HQ.jnpr.net>
In-Reply-To: <5E893DB832F57341992548CDBB33316398C549E2C2@EMBX01-HQ.jnpr.net>
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_A3C5DF08D38B6049839A6F553B331C76D6B78ED54EILPTMAIL02eci_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Brightmail-Tracker: AAAAAA==
Cc: Robert Rennison <Robert.Rennison@ecitele.com>,
"mpls-tp@ietf.org" <mpls-tp@ietf.org>
Subject: Re: [mpls-tp] FW: CC/CV/RDI nee RE: [mpls] [PWE3] [AHMPLS-TP] Re:
pollondraft-he-mpls-tp-csf-03.txt
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: Thu, 02 Dec 2010 20:43:09 -0000
John,
You've written:
There is a statement that Poll/Final is currently not used w/ GAL/GACH. I personally think this is a mistake.
I concur with this statement. There is no need to override the existing and widely deployed BFD state machine.
Regards,
Sasha
________________________________
From: mpls-tp-bounces@ietf.org [mpls-tp-bounces@ietf.org] On Behalf Of John E Drake [jdrake@juniper.net]
Sent: Thursday, December 02, 2010 9:24 PM
To: mpls-tp@ietf.org
Subject: [mpls-tp] FW: CC/CV/RDI nee RE: [mpls] [PWE3] [AHMPLS-TP] Re: pollondraft-he-mpls-tp-csf-03.txt
Resent with trailing emails elided.
Sent from my iPhone
From: John E Drake
Sent: Thursday, December 02, 2010 11:21 AM
To: 'Greg Mirsky'
Cc: LEVRAU, LIEVEN (LIEVEN); Rajiv Asati (rajiva); Yuanlong Jiang; mpls@ietf.org; Sprecher, Nurit (NSN - IL/Hod HaSharon); MPLS-TP ad hoc team; pwe3@ietf.org; mpls-tp@ietf.org
Subject: CC/CV/RDI nee RE: [mpls] [PWE3] [AHMPLS-TP] Re: [mpls-tp] pollondraft-he-mpls-tp-csf-03.txt
Hi,
Here is the relevant excerpt from CC/CV/RDI, for those that have not actually read it.
There are two clarifications to the base BFD spec (reference [4]) wrt the behavior of the MinRxInterval = 0. This is for independent mode *only*, and it may or may not actually be implemented by anyone.
There is a statement that Link Down Indication and Lock Report may be used as inputs to the BFD state machine. This may be done by mapping them to an existing input to the BFD state machine so the state machine is not changed in any way.
There is a statement that Poll/Final is currently not used w/ GAL/GACH. I personally think this is a mistake.
And that’s about it.
Thanks,
John
3.5. BFD Profile for MPLS-TP
BFD MUST operate in asynchronous mode. In this mode, the BFD Control
packets are periodically sent at configurable time rate. This rate is
typically a fixed value for the lifetime of the session. In the rare
circumstance where an operator has a reason to change session
parameters, the session must be moved to the ADMIN DOWN state.
Poll/final discipline can only used for VCCV and UDP/IP encapsulated
BFD.
The transport profile is designed to operate independent of the
control plane; hence the C bit SHOULD be set.
This document specifies bi-directional BFD for p2p transport LSPs,
hence the M bit MUST be clear.
There are two modes of operation for bi-directional LSPs. One in
which the session state of both directions of the LSP is coordinated
and one constructed from BFD sessions in such a way that the two
directions operate independently. A single bi-directional BFD session
is used for coordinated operation. Two independent BFD sessions are
used for independent operation.
Coordinated operation is as described in [4]. Independent operation
requires clarification of two aspects of [4]. Independent operation
is characterized by the setting of MinRxInterval to zero by the MEP
that is typically the session originator (referred to as the source
MEP), and there will be a session originator at either end of the bi-
directional LSP. Each source MEP will have a corresponding sink MEP
that has been configured to a Tx interval of zero.
The base spec is unclear on aspects of how a MEP with a BFD transmit
rate set to zero behaves. One interpretation is that no periodic
messages on the reverse component of the bi-directional LSP originate
with that MEP, it will only originate messages on a state change.
The first clarification is that when a state change occurs a MEP set
to a transmit rate of zero sends BFD control messages with a one
second period on the reverse component until such time that the state
change is confirmed by the session peer. At this point the MEP set to
a transmit rate of zero can resume quiescent behavior. This adds
robustness to all state transitions in the RxInterval=0 case.
The second is that the originating MEP (the one with a non-zero
TxInterval) will ignore a DOWN state received from a zero interval
peer. This means that the zero interval peer will continue to send
DOWN state messages that include the RDI diagnostic code as the state
change is never confirmed. This adds robustness to the exchange of
RDI indication on a uni-directional failure (for both session types
DOWN with a diagnostic of either control detection period expired or
neighbor signaled session down offering RDI functionality).
A further extension to the base specification is that there are
additional OAM protocol exchanges that act as inputs to the BFD state
machine; these are the Link Down Indication [5] and the Lock
Instruct/Lock Report transactions; Lock Report interaction being
optional.
Sent from my iPhone
From: Greg Mirsky [mailto:gregimirsky@gmail.com]
Sent: Thursday, December 02, 2010 10:53 AM
To: John E Drake
Cc: LEVRAU, LIEVEN (LIEVEN); Rajiv Asati (rajiva); Yuanlong Jiang; mpls@ietf.org; Sprecher, Nurit (NSN - IL/Hod HaSharon); MPLS-TP ad hoc team; pwe3@ietf.org; mpls-tp@ietf.org
Subject: Re: [mpls] [PWE3] [AHMPLS-TP] Re: [mpls-tp] pollondraft-he-mpls-tp-csf-03.txt
To stress that, IMHO, MPLS-TP CC/CV/RDI is neither IP, nor IP/MPLS BFD.
On Thu, Dec 2, 2010 at 10:26 AM, John E Drake <jdrake@juniper.net<mailto:jdrake@juniper.net>> wrote:
At this level of discussion, what’s your point?
Sent from my iPhone
From: Greg Mirsky [mailto:gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>]
Sent: Thursday, December 02, 2010 10:00 AM
To: John E Drake
Cc: LEVRAU, LIEVEN (LIEVEN); Rajiv Asati (rajiva); Yuanlong Jiang; mpls@ietf.org<mailto:mpls@ietf.org>; Sprecher, Nurit (NSN - IL/Hod HaSharon); MPLS-TP ad hoc team; pwe3@ietf.org<mailto:pwe3@ietf.org>; mpls-tp@ietf.org<mailto:mpls-tp@ietf.org>
Subject: Re: [mpls] [PWE3] [AHMPLS-TP] Re: [mpls-tp] pollondraft-he-mpls-tp-csf-03.txt
Dear John,
I think that MPLS-TP OAM CC/CV/RDI solution is based on BFD. It is not BFD in its entirety but is a subset with some aspects being specific for MPLS-TP and not part of RFC 5880.
Regards,
Greg
On Thu, Dec 2, 2010 at 5:45 AM, John E Drake <jdrake@juniper.net<mailto:jdrake@juniper.net>> wrote:
That statement is incorrect. MPLS-TP uses BFD for CC/CV/RDI (http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/)
Sent from my iPhone
> -----Original Message-----
> From: mpls-bounces@ietf.org<mailto:mpls-bounces@ietf.org> [mailto:mpls-bounces@ietf.org<mailto:mpls-bounces@ietf.org>] On Behalf Of
> LEVRAU, LIEVEN (LIEVEN)
> Sent: Thursday, December 02, 2010 5:17 AM
> To: Rajiv Asati (rajiva); Yuanlong Jiang
> Cc: mpls@ietf.org<mailto:mpls@ietf.org>; Sprecher, Nurit (NSN - IL/Hod HaSharon); MPLS-TP ad
> hoc team; pwe3@ietf.org<mailto:pwe3@ietf.org>; mpls-tp@ietf.org<mailto:mpls-tp@ietf.org>
> Subject: Re: [mpls] [PWE3] [AHMPLS-TP] Re: [mpls-tp] pollondraft-he-
> mpls-tp-csf-03.txt
>
> provocative statement alert- We should as we are talking about MPLS-TP
> and not about IP network layer.
>
- [mpls-tp] FW: CC/CV/RDI nee RE: [mpls] [PWE3] [AH… John E Drake
- Re: [mpls-tp] FW: CC/CV/RDI nee RE: [mpls] [PWE3]… Alexander Vainshtein
- Re: [mpls-tp] FW: CC/CV/RDI nee RE: [mpls] [PWE3]… John E Drake
- Re: [mpls-tp] FW: CC/CV/RDI nee RE: [mpls] [PWE3]… Greg Mirsky