Re: WGLC comments on bfd-mpls-05

Rahul Aggarwal <rahul@juniper.net> Thu, 08 May 2008 23:13 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 E5FA028C47D; Thu, 8 May 2008 16:13:34 -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 5404028C482 for <rtg-bfd@core3.amsl.com>; Thu, 8 May 2008 16:13:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.432
X-Spam-Level:
X-Spam-Status: No, score=-6.432 tagged_above=-999 required=5 tests=[AWL=0.167, 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 lbyi4VvlVDAp for <rtg-bfd@core3.amsl.com>; Thu, 8 May 2008 16:13:31 -0700 (PDT)
Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by core3.amsl.com (Postfix) with ESMTP id 93E0628C516 for <rtg-bfd@ietf.org>; Thu, 8 May 2008 16:13:30 -0700 (PDT)
Received: from source ([66.129.224.36]) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP; Thu, 08 May 2008 16:13:28 PDT
Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 May 2008 16:13:18 -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 m48NDHx86652; Thu, 8 May 2008 16:13:17 -0700 (PDT) (envelope-from rahul@juniper.net)
Date: Thu, 08 May 2008 16:13:17 -0700
From: Rahul Aggarwal <rahul@juniper.net>
To: Carlos Pignataro <cpignata@cisco.com>
Subject: Re: WGLC comments on bfd-mpls-05
In-Reply-To: <48234B87.9020805@cisco.com>
Message-ID: <20080508160658.L13067@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> <20080507163742.U82170@sapphire.juniper.net> <48234B87.9020805@cisco.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
X-OriginalArrivalTime: 08 May 2008 23:13:18.0031 (UTC) FILETIME=[19A5F5F0:01C8B161]
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 Carlos,

On Thu, 8 May 2008, Carlos Pignataro wrote:

> 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).
>

And those other means are out of scope. Seems like we are in agrement and
are saying the same thing. Let us not spin in wordsmithing.

> > 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:
>

And this spec requires configuration. That is it.

>     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.
>

And the revised text that I had sent makes it clear that this needs to be
configured.

> >
> > 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
>

See above note on configuration.

> 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].".
>

Based on Tom's comment, I am inclined to keep only RFC5085 as an
informative reference, unless I hear more opinions on this.

I will produce a revised ID. Thanks for the comments.

rahul

> Thanks,
>
> --Carlos.
>
>
> > And let
> > that be an informative reference ?
> >
> > rahul
> >
>
> --
> --Carlos Pignataro.
> Escalation RTP - cisco Systems
>