Re: WGLC comments on bfd-mpls-05

[Carlos Pignataro <[e-mail]>]

Hi Rahul,

On 5/6/2008 8:40 PM, Rahul Aggarwal said the following:
> Hi Carlos,
> 
> We are down to a couple of points. Please see below:

Yes, thank you for your responses and revisions. Please see inline.

> 
> <snipped>
> 
>>>
>>>>>> ---
>>>>>>
>>>>>> 6. Session Establishment
>>>>>>
>>>>>>     On receipt of the LSP-Ping echo request message, the egress LSR MUST
>>>>>>     send a BFD control packet to the ingress LSR.
>>>>>> ...
>>>>>> 7. Encapsulation
>>>>>>
>>>>>>     BFD control packets sent by the egress LSR are UDP packets. The
>>>>>>     source IP address is a routable address of the replier; the source
>>>>>>     port is the well-known UDP port 3784.  The destination IP address and
>>>>>>     UDP port MUST be copied from the source IP address and UDP port of
>>>>>>     the control packet received from the ingress LSR.
>>>>>>
>>>>>> LSP-Ping (ingress->egress) is used to exchange the ingress My
>>>>>> Discriminator. And then a BFD Control packet (egress->ingress) is used
>>>>>> to exchange the egress My Discriminator. Section 6 says that the egress
>>>>>> replies with a BFD Control packet (before it has received a BFD Control
>>>>>> packet from ingress), and Section 7 says that the egress copies the dest
>>>>>> UDP port from the source's ingress.
>>>>>> Therefore it seems that the
>>>>>> destination UDP Port of the first BFD Control packet (from egress to
>>>>>> ingress) is unspecified, and could be anything in the [49152 .. 65535]
>>>>>> range since:
>>>>>>
>>>>>>     The BFD control packet sent by the ingress LSR MUST be a UDP packet
>>>>>>     with a well known destination port 3784 [BFD-IP] and a source port
>>>>>>     assigned by the sender as per the procedures in [BFD-IP].
>>>>>>
>>>>>> Should the egress use also 3784 as destination port in the first BFD
>>>>>> Control packet?
>>>>> Thanks for catching this bug. The egress should either use 3784 as the
>>>>> dest port if the return packet is being tunnelled. It should use 4784
>>>>> otherwise. I will clarify this.
>>>> Thanks. But in this case, if the packet is being tunneled, the BFD would
>>>> have both udp.src and udp.dst as 3784, right? And if not tunneled, the
>>>> pair 3794/4784, instead of using udp source from [49152 .. 65535].
>>>>
>>> No. The modified text will say the following:
>>>
>>> "The BFD control packet sent by the egress LSR MUST have a well known
>>> destination port 4784, if it is routed [BFD-MHOP], or it MUST have a
>>> well known destination port 3784 [BFD-IP] if it is encapsulated in a
>>> MPLS label stack. The source port MUST be assigned by the egress lSR
>>> as per the procedures in [BFD-IP]."
>>>
>> Thanks. That clarifies.
>>
>> Regarding IP addresses, that para would continue with something like
>> this, right?
>>
>>     The source IP address is a routable address of the replier.  The
>>     destination IP address MUST be copied from the source IP address of
>>     the LSP-Ping echo request message received from the ingress LSR.
>>
> 
> Something like that, yes.
> 
>> Also, I just noticed that the regarding the TTL, the text says (does it
>> apply to both directions since it's in a separate para?):
>>
>>     The IP TTL MUST be set to 1.
>>
>> Is this done intentionally to ensure intercepting the packet to the
>> control plane in the ingress -> egress direction (even with the
>> destination in 127/8)?
> 
> Look at section 4.4 of RFC4379. I will add a reference to that.
> 

OK, thanks. (I was asking because the IP TTL 1 processing exception does 
not apply to the e2e PW case, and there is the PW-ACH exception)

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

> 
> <snipped>
> 
>>>>>> 11.2. Informative References
>>>>>>
>>>>>>       [VCCV]     T. Nadeau, C. Pignataro, R. Aggarwal,
>>>>>>                  "Pseudo Wire (PW) Virtual Circuit Connection Verification
>>>>>>                  ((VCCV)", draft-ietf-pwe3-vccv-13.txt
>>>>>>
>>>>>> This reference points to rev 13 of this document. In the subsequent
>>>>>> revision, this document was split into what resulted in RFC 5085 and the
>>>>>> ID draft-ietf-pwe3-vccv-bfd. It seems that some citations refer to the
>>>>>> former, while others to the latter, and they appear to be made in a
>>>>>> Normative fashion (e.g., because the VCCV control channel needs to exist
>>>>>> in order to send BFD packets over it).
>>>>>> However, given that PWs need an associated VCCV control channel, do not
>>>>>> need LSP-Ping boot-strapping (as can get the context from the PW label),
>>>>>> should this document point to draft-ietf-pwe3-vccv-bfd (that goes into
>>>>>> different BFD functional modes) for the PW case instead of also defining
>>>>>> it here, since it has a number of specific unique issues?
>>>>>>
>>>>> This document simply needs to point to RFC 5085 for the control word based
>>>>> control channel.
>>>> Yes, for the control channel, but it would still lack the connectivity
>>>> verification (CV) types.
>>>>
>>> This draft specifies procedures for *only BFD*. Hence the entire
>>> CV type discussion is simply not relevant.
>>>
>>>>> "The use of BFD for PWs is further described in [VCCV] and [OAM-MAP]."
>>>>>
>>>>> It should point to draft-ietf-pwe3-vccv-bfd in the above statement
>>>>> in section 3.1
>>>> I think there's one problem and two limitations with that approach. The
>>>> issue is that, for BFD to be run over the control-channel, it would need
>>>> to define the CV Type(s)/payload type(s) for BFD (as a normative
>>>> procedure).
>>> As I said this draft specifies fully standalone procedures to run BFD over
>>> a MPLS LSP including PWs. For a bidrectional LSP both
>>> ends are supposed to be configured for BFD.
>>>
>>> Signaling BFD as a CV type is certainly not required for the procedures in
>>> this draft.
>> If this specification makes use of the control channel from RFC5085 for
>> PW LSPs, only fault detection message payload types that are signaled
>> and agreed as CV types can run over the control channel, from RFC5085.
>>
> 
> Please see below.
> 
>>>> The limitations are that, for the PW case there is no
>>>> requirement to use LSP-Ping to bootstrap the session (and can remove the
>>>> dependency on LSP-Ping for the PW case),
>>> For the procedures in this draft bootstrapping using LSP-Ping is a MUST.
>>> As for reasons for using LSP-Ping for PWs in conjunction with BFD see
>>> section 3.2:
>>>
>>> ""In addition to
>>>    this 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."
>>>
>> Yes. Agreed.
>>
> 
> Great.
> 
>> Along these lines, the Session Establishment procedures in Section 6 say:
>>
>>     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)?

> 
>>>> and the other limitation is
>>>> regarding alternate encapsulations for BFD (PW-ACH mode, and functional
>>>> modes specified as different CV Types as well).
>>>>
>>> The use of PW-ACH is spelled out in RFC5085. The use of other CV types is
>>> simply not relevant to this draft as it covers only BFD.
>> LSP-Ping over PW-ACH is defined in RFC5085, so the LSP-Ping CV Type is
>> relevant for the PW case, or it could not bootstrap the session. From
>> RFC5085, for other connectivity-verification/payload types (like BFD)
>> over the PW-ACH, a CV Type is needed.
>>
>> The procedures in this draft strictly seem to update these rules, with
>> an implicit CV Type "negotiation"/agreement by means of sending (at the
>> ingress LSR) and parsing/understanding (at the egress LSR) the BFD
>> Discriminator TLV in the MPLS Echo request. There is the bootstrapping
>> (and LSP-Ping as a CV Type over the PW-ACH should have been negotiated
>> before this can happen for the PW case from RFC5085) as a "negotiation",
>> so there wouldn't be unexpected CV Types/payloads received (if the BFD
>> TLV is not supported it would result in "TLV not understood" since it's
>> 15). But I think this would need to be spelled out.
>>
> 
> 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

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

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

Thanks,

--Carlos.

> rahul
> 
>> Thanks,
>>
>> --Carlos.
>>
>>> rahul
>>>
>>>> Thanks again,
>>>>
>>>> --Carlos.
>>>>
>>>>> rahul
>>>>>
>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> --
>>>>>> --Carlos Pignataro.
>>>>>> Escalation RTP - cisco Systems
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>> --
>>>> --Carlos Pignataro.
>>>> Escalation RTP - cisco Systems
>>>>
>> --
>> --Carlos Pignataro.
>> Escalation RTP - cisco Systems
>>
> 

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