Re: WGLC comments on bfd-mpls-05

[Nadeau Thomas <[e-mail]>]

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