Re: WGLC comments on bfd-mpls-05

Rahul Aggarwal <rahul@juniper.net> Wed, 07 May 2008 20:01 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 F3F3F3A6E64; Wed, 7 May 2008 13:01:02 -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 144D43A6C2B for <rtg-bfd@core3.amsl.com>; Wed, 7 May 2008 13:01:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.885
X-Spam-Level:
X-Spam-Status: No, score=-5.885 tagged_above=-999 required=5 tests=[AWL=-0.286, BAYES_00=-2.599, J_BACKHAIR_35=1, 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 2cO-vRE3u9mg for <rtg-bfd@core3.amsl.com>; Wed, 7 May 2008 13:01:00 -0700 (PDT)
Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by core3.amsl.com (Postfix) with ESMTP id 7D3383A67F5 for <rtg-bfd@ietf.org>; Wed, 7 May 2008 13:00:59 -0700 (PDT)
Received: from source ([66.129.224.36]) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP; Wed, 07 May 2008 13:00:55 PDT
Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 7 May 2008 13:00:07 -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 m47K05x96201; Wed, 7 May 2008 13:00:05 -0700 (PDT) (envelope-from rahul@juniper.net)
Date: Wed, 7 May 2008 13:00:05 -0700 (PDT)
From: Rahul Aggarwal <rahul@juniper.net>
To: Carlos Pignataro <cpignata@cisco.com>
Subject: Re: WGLC comments on bfd-mpls-05
In-Reply-To: <4821FB01.90209@cisco.com>
Message-ID: <20080507121818.R82170@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>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-OriginalArrivalTime: 07 May 2008 20:00:07.0804 (UTC) FILETIME=[F2EBEBC0:01C8B07C]
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,

<snipped>

> >
> >> If so, could the Security Considerations mention
> >> that the GTSM is not in effect in that direction,
> >> and with a routed
> >> multi-hop reply? Or should it be set to 255 and GTSM-checked on receipt?
> >> And in the egress -> ingress direction, should the TTL be set to 255
> >> (and checked for GTSM if the dest port if 3784, but not if the dest port
> >> is 4784)?
> >>
> >
> > The revised text will make it clear that for a routed reply
> > [BFD-MHOP] applies and otherwise [BFD-IP] applies. I don't think
> > there is any need to state the above here.
>
> Thanks. Would this apply only to encapsulation (since the text is within
> the Encapsulation section), or also to the GTSM procedures from
> [BFD-IP]? Could that be clarified as well, since it might not be
> directly apparent?
>

I will clarify this.

<snipped>

> >>
> >>     On receipt of the LSP-Ping echo request message, the egress LSR MUST
> >>     send a BFD control packet to the ingress LSR.  This BFD control
> >>     packet MUST set the Your Discriminator field to the discriminator
> >>     received from the ingress LSR in the LSP-Ping echo request message.
> >>
> >> I think this should additionally require successful FEC Validation
> >> ("Validate FEC Stack" flag in the MPLS echo request) before sending a
> >> BFD control packet back, or at least a successful (return-code 3) label
> >> operation check on receipt of the MPLS Echo request.
> >>
> >
> > This is normal LSP-Ping procedure.
>
> The normal LSP-Ping procedure generates an LSP-Ping reply with a result
> code that could differ from "AOK", and could for example be "Replying
> router has no mapping for the FEC at stack-depth <RSC>" or "No label
> entry at stack-depth <RSC>"; in these cases, in the new procedures, I
> think that the egress LSR should not send a BFD control packet (as there
> is a FEC<->Label mismatch detected, and the feature of using LSP-Ping
> with BFD so that "the presence of the FEC in the echo request message
> makes is possible to verify the control plane against the data plane at
> the egress LSR" would become a NOOP). Shouldn't the BFD session be
> bootstrapped only after a successful control-plane checking (and ideally
> including FEC Validation)?
>

I see there is value in clarifying this. Will do.

<snipped>

> >
> > How about inserting the following text to clarify this:
>
> I think this clarifies, with two small comments inline, thanks:
>
> >
> > "To enable fault detection procedures specified in this document, for a
> > particular MPLS LSP, this document requires the ingress and
> > egress LSRs to be configured. This includes configuration for supporting
> > BFD and LSP-Ping as specified in this document. It also includes
> > configuration that enables to the ingress LSR to determine the
>                 ^
>                 or signaling
>

The whole point is that this document does not specify any signaling to
discover the ingress/egress capabilities. It relies on configuration.

> > method used by the egress LSR to identify OAM packets e.g. whether the TTL
> > of the innermost MPLS label needs to be set to 1 to enable the egress LSR
> > to identify the OAM packet. This applies to fault detection for MPLS PWs
> > as well.
>
> "For fault detection for MPLS PWs, this document also assume that a PW
> control channel (e.g., a PW-ACH) and support for LSP-Ping are provided
> prior to initializing the procedures specified in this document, as
> specified in [RFC5085]. "
>
> or something along those lines.
>

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.

> > Extending [RFC5085] procedures to signal BFD capability
> > between PW endpoints is outside the scope of this document."
> >
>
> Should this pointer to [RFC5085] be normative, and the one to
> pwe3-vccv-bfd in "The use of BFD for PWs is further described in [VCCV]
> and [OAM-MAP]." be informative?
>

Both should be informative pointers.

rahul