Re: WGLC comments on bfd-mpls-05
Nadeau Thomas <tnadeau@lucidvision.com> Wed, 07 May 2008 21:02 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 1750C3A6B0B; Wed, 7 May 2008 14:02:50 -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 98D9E28C6B2 for <rtg-bfd@core3.amsl.com>; Wed, 7 May 2008 14:02:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, J_BACKHAIR_35=1]
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 G1K4NAj19yZh for <rtg-bfd@core3.amsl.com>; Wed, 7 May 2008 14:02:46 -0700 (PDT)
Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by core3.amsl.com (Postfix) with ESMTP id 541693A714E for <rtg-bfd@ietf.org>; Wed, 7 May 2008 14:02:44 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by lucidvision.com (Postfix) with ESMTP id AC06E35B687; Wed, 7 May 2008 17:03:38 -0400 (EDT)
Received: from lucidvision.com ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22833-08; Wed, 7 May 2008 17:03:05 -0400 (EDT)
Received: from Novi-Jablko.lucidvision.dyndns.org (static-72-71-250-36.cncdnh.fios.verizon.net [72.71.250.36]) by lucidvision.com (Postfix) with ESMTP id 2390E35B666; Wed, 7 May 2008 17:03:05 -0400 (EDT)
Message-Id: <CE94F791-D78C-48C4-8C61-A847212D6E4F@lucidvision.com>
From: Nadeau Thomas <tnadeau@lucidvision.com>
To: Rahul Aggarwal <rahul@juniper.net>
In-Reply-To: <20080507121818.R82170@sapphire.juniper.net>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v919.2)
Subject: Re: WGLC comments on bfd-mpls-05
Date: Wed, 07 May 2008 17:02:07 -0400
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>
X-Mailer: Apple Mail (2.919.2)
X-Virus-Scanned: by amavisd-new at lucidvision.com
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
On May 7, 2008:4:00 PM, at 4:00 PM, Rahul Aggarwal wrote: > > 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. I agree for the static case things are explicitly configured. However, I think the confusion here lies in the fact that we could configure the capability, and then advertise the BFD/VCCV capability, right? 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. --Tom >>> 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 > >
- WGLC comments on bfd-mpls-05 Carlos Pignataro
- [BFD] bfd-mpls-05 Damodharan SP - TLS , Chennai
- Re: [BFD] bfd-mpls-05 Carlos Pignataro
- Re: WGLC comments on bfd-mpls-05 Rahul Aggarwal
- Re: WGLC comments on bfd-mpls-05 Carlos Pignataro
- Re: WGLC comments on bfd-mpls-05 Rahul Aggarwal
- Re: WGLC comments on bfd-mpls-05 Carlos Pignataro
- Re: WGLC comments on bfd-mpls-05 Rahul Aggarwal
- Re: WGLC comments on bfd-mpls-05 Carlos Pignataro
- Re: WGLC comments on bfd-mpls-05 Rahul Aggarwal
- Re: WGLC comments on bfd-mpls-05 Nadeau Thomas
- Re: WGLC comments on bfd-mpls-05 Rahul Aggarwal
- Re: WGLC comments on bfd-mpls-05 Carlos Pignataro
- Re: WGLC comments on bfd-mpls-05 Rahul Aggarwal