Re: [PWE3] BFD for MPLS PWs

"Thomas D. Nadeau" <tnadeau@cisco.com> Tue, 15 August 2006 20:07 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD5CE-0004Xm-7S; Tue, 15 Aug 2006 16:07:30 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD5CD-0004Xh-Eg for pwe3@ietf.org; Tue, 15 Aug 2006 16:07:29 -0400
Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GD5CC-0001mn-4a for pwe3@ietf.org; Tue, 15 Aug 2006 16:07:29 -0400
Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 15 Aug 2006 16:07:27 -0400
X-IronPort-AV: i="4.08,128,1154923200"; d="scan'208"; a="96965004:sNHT33546260"
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7FK7RdM016158; Tue, 15 Aug 2006 16:07:27 -0400
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k7FK7Rh5005859; Tue, 15 Aug 2006 16:07:27 -0400 (EDT)
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Aug 2006 16:07:27 -0400
Received: from [10.83.15.52] ([10.83.15.52]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Aug 2006 16:07:27 -0400
In-Reply-To: <B99995113B318D44BBE87DC50092EDA91D5A1C24@nj7460exch006u.ho.lucent.com>
References: <B99995113B318D44BBE87DC50092EDA91D5A1C24@nj7460exch006u.ho.lucent.com>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <29DC8A5B-7315-47EB-B07F-45B6970B83EF@cisco.com>
Content-Transfer-Encoding: 7bit
From: "Thomas D. Nadeau" <tnadeau@cisco.com>
Subject: Re: [PWE3] BFD for MPLS PWs
Date: Tue, 15 Aug 2006 16:07:31 -0400
To: "Busschbach, Peter B (Peter)" <busschbach@lucent.com>
X-Mailer: Apple Mail (2.752.2)
X-OriginalArrivalTime: 15 Aug 2006 20:07:27.0165 (UTC) FILETIME=[6E24D6D0:01C6C0A6]
DKIM-Signature: a=rsa-sha1; q=dns; l=2939; t=1155672447; x=1156536447; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tnadeau@cisco.com; z=From:=22Thomas=20D.=20Nadeau=22=20<tnadeau@cisco.com> |Subject:Re=3A=20[PWE3]=20BFD=20for=20MPLS=20PWs |To:=22Busschbach,=20Peter=20B=20(Peter)=22=20<busschbach@lucent.com>; X=v=3Dcisco.com=3B=20h=3D153EeqHWM4NHFdhgQ0ntvaSrNJM=3D; b=iELUhZ+RhzYaexG7w2l1Q7HNHY+7vIARbCYRiV9XKQ5rTH/rTltCRigVEqPoEHOy23hPuCcY bBTMa9JBaq1BZmLfNNR2QAznHFvWzD+tSenRbF4SN5LmYlfSACPuSLiv;
Authentication-Results: rtp-dkim-1.cisco.com; header.From=tnadeau@cisco.com; dkim=pass ( sig from cisco.com verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4
Cc: Swallow George <swallow@cisco.com>, Pignataro Carlos <cpignata@cisco.com>, Morrow Monique <mmorrow@cisco.com>, "pwe3 WG ((((((((E-mail))))))))" <pwe3@ietf.org>, Danny McPherson <danny@tcb.net>, Agarwal Rahul <rahagarw@cisco.com>, "Stewart (stbryant) Bryant" <stbryant@cisco.com>
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>, <mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>, <mailto:pwe3-request@ietf.org?subject=subscribe>
Errors-To: pwe3-bounces@ietf.org

On Aug 15, 2006, at 3:35 PM, Busschbach, Peter B (Peter) wrote:

>
> Tom,
>
> I have a comment on the following part of your proposed text:
>
>>     The defined values for CV Types are:
>>
>>         0x00  None.
>>         0x01  ICMP Ping.
>>         0x02  LSP Ping.
>>         0x04  BFD for PW Fault Detection only.
>>         0x08  BFD for PW Fault Detection and AC/PW Fault
>>               Status Signaling.
>>     It should be noted that two different CV Types have been defined
>>     when BFD is used. In the case of type 0x08, the AC and PW status
>>     SHOULD be conveyed via BFD status codes as specified in [OAM- 
>> MAP].
>>     However, this type SHOULD NOT be used when a control protocl such
>>     as LDP is available that can signal the AC/PW status to the  
>> remote
>>     endpoint of the PW due to complications that can arise from
>>     synchronization issues between the control protocol's status
>>     signaling messags and the BFD messages containing fault status
>>     information.
>>
>
> I don't think it is correct to mandate that 0x08 should not be used  
> if LDP is used to setup PWs. An operator might prefer to use BFD  
> for both PW and AC fault notification, even if LDP is being used,  
> because BFD is transported in the data plane whereas LDP is in the  
> control plane. Since the control  plane is critical for correct  
> operation of the network, it makes sense to avoid overloading it  
> with data-plane-related  failure notifications.

	I agree, and am working on an updated version of the text
I posted based on your and the previous comments.  Basically
I switched to adding 2 new CV Types, as was originally stated
instead of a new CC type. I also corrected the Control Channel ID
in the CW, which was incorrect. I should be done with the new text
by tomorrow morning and will post it.

> Furthermore, I don't understand which "complications" you refer to.  
> Using BFD for both AC and PW fault status information is more  
> straightforward than using BFD for some faults and LDP for others.  
> The only complication that I see is that a developer must read  
> section 5.3.4 of OAM-MAP. If that text is ambiguous, it should be  
> updated, but otherwise I don't see what is complicated about it.

	The consensus I think we reached on the thread was to
use an OR function for detecting the down status either from
BFD/VCCV or LDP, but to use an AND function when detecting
the transition to the up status from both of these (if they
are in use). However, the de-facto status must always rely on
LDP as RFC4447 states that one MUST signal status using LDP for
PWs using the LDP status codes. Of course, this is if you are
using LDP as the signaling protocol instead of say setting up the
PWs statically.  I am adding this text to the draft, but after I
get the text on the CC/CV types straight.

	--Tom


>
> Peter

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