Re: WGLC comments on bfd-mpls-05

Rahul Aggarwal <rahul@juniper.net> Wed, 07 May 2008 23:49 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 core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCCD728C3C5; Wed, 7 May 2008 16:49:54 -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 355403A6D4E for <rtg-bfd@core3.amsl.com>; Wed, 7 May 2008 16:49:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.377
X-Spam-Level:
X-Spam-Status: No, score=-6.377 tagged_above=-999 required=5 tests=[AWL=0.222, 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 8juzGQxEa4Tx for <rtg-bfd@core3.amsl.com>; Wed, 7 May 2008 16:49:51 -0700 (PDT)
Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by core3.amsl.com (Postfix) with ESMTP id 5F1463A6AE6 for <rtg-bfd@ietf.org>; Wed, 7 May 2008 16:49:51 -0700 (PDT)
Received: from source ([66.129.224.36]) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP; Wed, 07 May 2008 16:49:42 PDT
Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 May 2008 16:49:23 -0700
Received: from sapphire.juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m47NnNx74081; Wed, 7 May 2008 16:49:23 -0700 (PDT) (envelope-from rahul@juniper.net)
Date: Wed, 7 May 2008 16:49:23 -0700 (PDT)
From: Rahul Aggarwal <rahul@juniper.net>
To: Nadeau Thomas <tnadeau@lucidvision.com>
Subject: Re: WGLC comments on bfd-mpls-05
In-Reply-To: <CE94F791-D78C-48C4-8C61-A847212D6E4F@lucidvision.com>
Message-ID: <20080507163742.U82170@sapphire.juniper.net>
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>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-OriginalArrivalTime: 07 May 2008 23:49:23.0663 (UTC) FILETIME=[FA0D6DF0:01C8B09C]
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 Tom,

Please see below:

<snipped>

<rahul>
> I don't think that makes sense as this document relies on
> > configuration.
> > 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.

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.

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 ? And let
that be an informative reference ?

rahul