Re: WGLC comments on bfd-mpls-05

Carlos Pignataro <cpignata@cisco.com> Thu, 08 May 2008 18:52 UTC

Return-Path: <rtg-bfd-bounces@ietf.org>
X-Original-To: rtg-bfd-archive@megatron.ietf.org
Delivered-To: ietfarch-rtg-bfd-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF9F63A6C44; Thu, 8 May 2008 11:52:24 -0700 (PDT)
X-Original-To: rtg-bfd@core3.amsl.com
Delivered-To: rtg-bfd@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 317A03A6B1B for <rtg-bfd@core3.amsl.com>; Thu, 8 May 2008 11:52:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.132
X-Spam-Level:
X-Spam-Status: No, score=-6.132 tagged_above=-999 required=5 tests=[AWL=0.467, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 0bgvBw73E0pi for <rtg-bfd@core3.amsl.com>; Thu, 8 May 2008 11:52:19 -0700 (PDT)
Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by core3.amsl.com (Postfix) with ESMTP id DE4D93A6B69 for <rtg-bfd@ietf.org>; Thu, 8 May 2008 11:51:01 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from rooster.cisco.com (localhost [127.0.0.1]) by av-tac-rtp.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m48IovA05786; Thu, 8 May 2008 14:50:57 -0400 (EDT)
Received: from [64.102.157.132] (dhcp-64-102-157-132.cisco.com [64.102.157.132]) by rooster.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m48Ipeu26593; Thu, 8 May 2008 14:51:40 -0400 (EDT)
Message-ID: <48234B87.9020805@cisco.com>
Date: Thu, 08 May 2008 14:50:47 -0400
From: Carlos Pignataro <cpignata@cisco.com>
Organization: cisco Systems, Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.14) Gecko/20080421 Thunderbird/2.0.0.14 Mnenhy/0.7.5.0
MIME-Version: 1.0
To: Rahul Aggarwal <rahul@juniper.net>
Subject: Re: WGLC comments on bfd-mpls-05
References: <20080430203803.K89520@sapphire.juniper.net> <481F69CA.1020406@cisco.com> <20080505154957.M81069@sapphire.juniper.net> <4820A894.2040608@cisco.com> <20080506130108.O46817@sapphire.juniper.net> <4821FB01.90209@cisco.com> <20080507121818.R82170@sapphire.juniper.net> <CE94F791-D78C-48C4-8C61-A847212D6E4F@lucidvision.com> <20080507163742.U82170@sapphire.juniper.net>
In-Reply-To: <20080507163742.U82170@sapphire.juniper.net>
X-Enigmail-Version: 0.95.6
X-Face: *3w8NvnQ|kS~V{&{U}$?G9U9EJQ8p9)O[1[1F'1i>XIc$5FR!hdAIf5}'Xu-3`^Z']h0J* ccB'fl/XJYR[+,Z+jj`4%06nd'y9[ln&ScJT5S+O18e^
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Ross Callon <rcallon@juniper.net>, rtg-bfd@ietf.org, dward@cisco.com
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
Sender: rtg-bfd-bounces@ietf.org
Errors-To: rtg-bfd-bounces@ietf.org

Hi Rahul, Tom,

Please find some comments inline on the last point (down to one).

On 5/7/2008 7:49 PM, Rahul Aggarwal said the following:
> Hi Tom,
> 
> Please see below:
> 
> <snipped>
> 
> <rahul>
>> I don't think that makes sense as this document relies on
>>> configuration.

That's fine, but my point is that instead of configuration, this 
document (for the PW case) relies on the existence of a control channel 
and capability/ability/agreement to run LSP-Ping, which in turn can be 
preformed by configuration (or other means equally).

>>> Further there is no point in signaling LSP-Ping capability if BFD
>>> capability cannot be signaled.
>>>
>>> I fail to see why it is not enough to spell out that this document
>>> requires configuration. It doesn't preclude capability signaling to be
>>> added by another document.
> 
> <tom> 	I agree for the static case things are explicitly configured.

Please note that I'm not referring to signaling the BFD procedures on 
this document. But these BFD procedures, for PWs, start with a control 
channel and LSP-Ping (signaled or configured), both defined in RFC5085.

> 
> We are in sync. This is the key point.
> 
> tom>
>> However, I think the confusion here lies in the fact that we could
>> configure the capability, and then advertise the BFD/VCCV capability,
>> right?
> 
> This spec requires configuration and should just say that signaling of
> capabilities is out of scope.

Note that RFC5085 says:

    Routers that implement VCCV create a Control Channel (CC) associated
    with a pseudowire.  This control channel can be signaled (e.g., using
    LDP or L2TPv3 depending on the PWE3) or statically configured.  Over
    this control channel, VCCV Connectivity Verification (CV) messages
    are sent.

I mean (and I may not have been clear), not to signal capabilities for 
the procedures in this spec, but the configuration or signaling 
pre-requisite (and hence Normative for PWs) to start those procedures in 
this document (with LSP-Ping over the PW control channel).

For the PW case specifically,  a control channel needs to exist prior to 
OAM messages. This dependency can be realized by configuration or 
signaling. For example, the text says as an example use TTL=1 or:

    For MPLS PWs, alternatively,
    the presence of a fault detection message may be indicated by setting
    a bit in the control word [VCCV].

But to use this method, it needs to be signaled or configured as per 
RFC5085, otherwise OAMs could potentially be not intercepted and 
forwarded to the CE. The TTL=1 listed is another control channel type 
from RFC5085.

> 
> tom>
>> But those are explicitly detailed in the vccv-bfd document
>> (draft-ietf-pwe3-vccv-bfd-01).  It might be most appropriate to simply
>> remove the forward reference to the vccv-bfd stuff from here, and only
>> refer to this document from there.
>>
> 
> How about removing the forward reference to draft-ietf-pwe3-vccv-bfd-01.
> But leaving the reference to RFC5085 to say that there could be
> other ways to identify OAM packets other than ttl=1, for PWs ? 

Note that TTL=1 for PWs is one of the RFC5085 control channels, so it 
seem that RFC5085 is needed to bootstrap:

          Bit 2 (0x04) - Type 3: MPLS PW Label with TTL == 1

But regarding this forward pointer, my preference would be to leave it 
in (for completeness and cross-reference) in the same context as the 
existing text:

	"Use of BFD for PWs is further described in [VCCV-BFD] and
	[OAM-MAP].".

Thanks,

--Carlos.


> And let
> that be an informative reference ?
> 
> rahul
> 

-- 
--Carlos Pignataro.
Escalation RTP - cisco Systems