Re: [PWE3] BFD for MPLS PWs

"Thomas D. Nadeau" <tnadeau@cisco.com> Mon, 31 July 2006 20:47 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7eff-0000gB-TZ; Mon, 31 Jul 2006 16:47:27 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7efe-0000g0-PW for pwe3@ietf.org; Mon, 31 Jul 2006 16:47:26 -0400
Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7efd-00083v-Dv for pwe3@ietf.org; Mon, 31 Jul 2006 16:47:26 -0400
Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 31 Jul 2006 13:47:25 -0700
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
X-IronPort-AV: i="4.07,199,1151910000"; d="scan'208"; a="34015612:sNHT24497372"
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6VKlO0s000821; Mon, 31 Jul 2006 16:47:24 -0400
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k6VKlOdU003553; Mon, 31 Jul 2006 16:47:24 -0400 (EDT)
Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 31 Jul 2006 16:47:24 -0400
Received: from [10.83.15.50] ([10.83.15.50]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 31 Jul 2006 16:47:23 -0400
In-Reply-To: <20060731131439.P26800@sapphire.juniper.net>
References: <457D36D9D89B5B47BC06DA869B1C815D014D047B@exrad3.ad.rad.co.il> <31F3F31C-4EBD-4378-A413-C719CB6ED540@cisco.com> <20060731131439.P26800@sapphire.juniper.net>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <2C00CBF3-6993-4C0F-B318-C0CAF9C11C83@cisco.com>
Content-Transfer-Encoding: 7bit
From: "Thomas D. Nadeau" <tnadeau@cisco.com>
Subject: Re: [PWE3] BFD for MPLS PWs
Date: Mon, 31 Jul 2006 16:47:42 -0400
To: Rahul Aggarwal <rahul@juniper.net>
X-Mailer: Apple Mail (2.752.2)
X-OriginalArrivalTime: 31 Jul 2006 20:47:23.0265 (UTC) FILETIME=[86226F10:01C6B4E2]
DKIM-Signature: a=rsa-sha1; q=dns; l=3844; t=1154378844; x=1155242844; 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:Rahul=20Aggarwal=20<rahul@juniper.net>; X=v=3Dcisco.com=3B=20h=3D153EeqHWM4NHFdhgQ0ntvaSrNJM=3D; b=rHwOB9cm785rsfAe6nXnu9kjvrU9ZPpoDP7834hkvA9Dt4gmc0So/QqnJihaupeEXhOa7881 JgtupC7FpVRWn7EObCTZxhdeD+2fWKuGClCzvQZOJBmwGycG+z7q2aWa;
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: 825e642946eda55cd9bc654a36dab8c2
Cc: Yaakov Stein <yaakov_s@rad.com>, pwe3@ietf.org
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

> Hi Tom,
>
> On Mon, 31 Jul 2006, Thomas D. Nadeau wrote:
>
>>
>> On Jul 31, 2006, at 12:02 PM, Yaakov Stein wrote:
>>
>>> Rahul,
>>>
>>> At the PWE session you stated that the MPLS BFD draft
>>> described the use of BFD for PWs, and that the VCCV draft
>>> and the BFD MPLS draft need to remain aligned.
>>>
>>> The only mention I find in draft draft-ietf-bfd-mpls-03.txt of PWs
>>> is the following motivational text:
>>>
>>>    2. MPLS Pseudo Wires (PW). Fast detection may be desired for MPLS
>>>    PWs depending on i) the model used to layer the MPLS network
>>> with the
>>>    layer 2 network. and ii) the service that the PW is emulating.
>>> For a
>>>    non-overlay model between the layer 2 network and the MPLS  
>>> network
>>>    the provider may rely on PW fault detection to provide service
>>> status
>>>    to the end-systems. Also in that case interworking scenarios
>>> such as
>>>    ATM/Frame Relay interworking may force periodic PW fault  
>>> detection
>>>    messages. Depending on the requirements of the service that the
>>> MPLS
>>>    PW is emulating, fast failure detection may be desirable. Use of
>>> BFD
>>>    for PWs is further described in [VCCV] and [OAM-MAP].
>>>
>>> I don't see any normative text here, and certainly nothing  
>>> describing
>>> whether or not UDP is used. What I do see is a pointer to VCCV,
>>> so that any changes in VCCV should reflect here.
>>>
>>> Section 4 on "theory of operation" seems to be silent on PW issues.
>>>
>>> Am I missing something?
>>
>> 	It was my assumption that the text in VCCV would
>> stipulate the encapsulation (this is the new text that
>> was proposed during and modified later based on comments
>> from those who objected after the meeting).
>
> Can you please send a pointer to this new text ?
>> VCCV also
>> stipulates how to use this mode and or makes references
>> where necessary.
>>
>> 	I do agree with Yaakov in that I think that
>> the text in the BFD/MPLS draft referencing PWE3
>> should be stripped altogether.
>>
>
> BFD-MPLS spells out the generic procedures for various FECs  
> including the
> PW FEC. Why should these procedures not apply to the PW FEC ?

	The reasons that were explained during the meeting:

	1) sending the IP/UDP header is redundant
		for SH PWs because the labels or outer l2tpv3 header
		ID the VCCV payload.

	2) If you include the 127/ dest. address, then it is useless other
		than it prevents errant routing if the PW header
		is inadvertently stripped.  However, skipping the
		IP header altogether obviates both problems. It
		also makes each VCCV/BFD packet shorter.

	2) sending the IP/UDP header is useless for MH PWs because
		the MH PW addressing scheme will not fit into
		an IPv4 address.  Instead, the outer PW encapsulation
		identifies the destination.

	3) the secondary routing header lookup/processing is
		a waste of processing cycles since it should
		always result in the receiving PE. The outer
		header identifies the PW packet already.

	Conversations with everyone except yourself (I couldn't
find you after PWE3) that objected to the removal of the UDP/IP
header at the meeting, all agreed that this was okay assuming that
we add two new CV types to explicitly identify when the header
is and is not included for BFD messages so that we can support
older implementations. I will have the text for this shortly
and will send it out.

	--Tom



> rahul
>
>> 	--Tom
>>
>>
>>
>>> Y(J)S
>>>
>>>
>>> _______________________________________________
>>> pwe3 mailing list
>>> pwe3@ietf.org
>>> https://www1.ietf.org/mailman/listinfo/pwe3
>>
>
> _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www1.ietf.org/mailman/listinfo/pwe3

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