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