Re: [PWE3] BFD for MPLS PWs

"Thomas D. Nadeau" <tnadeau@cisco.com> Wed, 30 August 2006 21:51 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIXxp-0005GN-Ii; Wed, 30 Aug 2006 17:51:13 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIXxn-0005G6-Kh for pwe3@ietf.org; Wed, 30 Aug 2006 17:51:11 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIWLF-0002O1-17 for pwe3@ietf.org; Wed, 30 Aug 2006 16:07:17 -0400
Received: from sj-iport-4.cisco.com ([171.68.10.86]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GIViM-0000a7-Rl for pwe3@ietf.org; Wed, 30 Aug 2006 15:27:07 -0400
Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 30 Aug 2006 12:27:06 -0700
X-IronPort-AV: i="4.08,189,1154934000"; d="scan'208"; a="1851247968:sNHT33582716"
Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7UJR64B014465; Wed, 30 Aug 2006 12:27:06 -0700
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k7UJR86W005436; Wed, 30 Aug 2006 12:27:08 -0700 (PDT)
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); Wed, 30 Aug 2006 15:27:05 -0400
Received: from [161.44.71.206] ([161.44.71.206]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Aug 2006 15:27:04 -0400
In-Reply-To: <44F5DAFF.6070003@cisco.com>
References: <EAE1CBBD071180449FC50C37CFC7839401F19E48@xmb-rtp-202.amer.cisco.com> <ED2231E3-C036-4512-9698-1EF9FC33D44D@cisco.com> <44F5DAFF.6070003@cisco.com>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <105C2A40-98FC-47CA-8787-48DAE8C960E4@cisco.com>
Content-Transfer-Encoding: 7bit
From: "Thomas D. Nadeau" <tnadeau@cisco.com>
Subject: Re: [PWE3] BFD for MPLS PWs
Date: Wed, 30 Aug 2006 15:27:04 -0400
To: Luca Martini <lmartini@cisco.com>
X-Mailer: Apple Mail (2.752.2)
X-OriginalArrivalTime: 30 Aug 2006 19:27:04.0922 (UTC) FILETIME=[469223A0:01C6CC6A]
DKIM-Signature: a=rsa-sha1; q=dns; l=1945; t=1156966026; x=1157830026; c=relaxed/relaxed; s=sjdkim8002; 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; X=v=3Dcisco.com=3B=20h=3D153EeqHWM4NHFdhgQ0ntvaSrNJM=3D; b=Me4BfYSjxFRknBqCM0SiBaUtCNcGSBBdPuiE4mfGsYy6PiephknMfd4gJ+uIs0SV1Bf/8aPp mbgPgY8qNnHnAtX2p/X5XbAvPbjB81mFlY4o4aq01P5u+HQ8wYdoxmhN;
Authentication-Results: sj-dkim-8.cisco.com; header.From=tnadeau@cisco.com; dkim=pass ( sig from cisco.com verified; );
X-Spam-Score: -2.6 (--)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793
Cc: "George Swallow (swallow)" <swallow@cisco.com>, "Carlos Pignataro (cpignata)" <cpignata@cisco.com>, "Monique Morrow (mmorrow)" <mmorrow@cisco.com>, pwe3@ietf.org, danny@tcb.net, "Rahul Agarwal (rahagarw)" <rahagarw@cisco.com>, "Stewart Bryant (stbryant)" <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 30, 2006, at 2:37 PM, Luca Martini wrote:

> Thomas D. Nadeau wrote:
>>
>>> 4. The draft indicates that PWs should be torn down when the CV  
>>> or CC
>>> types change. IMO, we should only tear down when strictly  
>>> necessary. If
>>> a node has the LSP Ping feature disabled, but is then turned on,  
>>> there
>>> is no reason why the PWs need to be torn down.
>>
>>     We originally added this to simplify implementation, but
>> I now see why it is important to allow a change of this on the fly
>> without disrupting the data flow for the PW. Let me suggest that we
>> allow changes only after a subsequent transmission of the interface
>> parameters TLV with new capabilities advertisements. In this case,
>> the sending PE MAY choose to send a different payload type. But
>> as originally stated, once it starts sending it, it MUST continue
>> with that type.  We want to avoid having to entertain different
>> payload types on the fly, which I think does complicate the
>> implementations. Although we might want to relax the MUST to a
>> SHOULD.
>>
>>     --Tom
>>
> Actually quoting RFC4447:
> "
>  -  Interface Parameter Sub-TLV
>
>      This variable-length TLV is used to provide interface-specific
>      parameters, such as attachment circuit MTU.
>
>      Note that as the "interface parameter sub-TLV" is part of the  
> FEC,
>      the rules of LDP make it impossible to change the interface
>      parameters once the pseudowire has been set up.  Thus, the
>      interface parameters field must not be used to pass information,
>      such as status information, that may change during the life of  
> the
>      pseudowire.  Optional parameter TLVs should be used for that
>      purpose.
> "
>
> So the interface parameter sub-TLV cannot be "updated" without  
> issuing  a label withdraw message and re-advertising the FEC.

	Good point. We should leave the text as we originally
had it, which agreed with your reference.

	--Tom


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