Re: WGLC comments on bfd-mpls-05

[Carlos Pignataro <[e-mail]>]

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

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

Please note that I'm not referring to signaling the BFD procedures on 
this document. But these BFD procedures, for PWs, start with a control 
channel and LSP-Ping (signaled or configured), both defined in RFC5085.

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

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:

    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.

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

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

Thanks,

--Carlos.


> And let
> that be an informative reference ?
> 
> rahul
> 

-- 
--Carlos Pignataro.
Escalation RTP - cisco Systems