Re: WGLC comments on bfd-mpls-05

[Carlos Pignataro <[e-mail]>]

Hi Rahul,

Thank you for your answers, please find some follow-ups below.

On 4/30/2008 11:41 PM, Rahul Aggarwal said the following:
> Hi Carlos,
> 
> Thanks for the comments. Please see below:
> 
>> Please find a couple of comments regarding bfd-mpls-05. I realize this
>> is way past end of WGLC, but I hope the comments are useful and can be
>> given consideration.
>>
>>
>> 3.1. BFD for MPLS LSPs: Motivation
>>
>>        The LSP may be  associated with any of the following FECs:
>>          a) RSVP IPv4/IPv6 Session [RFC3209]
>>          b) LDP IPv4/IPv6 prefix [RFC3036]
>>          c) VPN IPv4/IPv6 prefix [RFC4364]
>>          d) Layer 2 VPN [L2-VPN]
>>          e) Layer 2 Circuit ID [RFC4447]
>>
>> Does item e) refer to both the PWid FEC and the Generalized PWid FEC
>> (128 and 129)?
>>
> 
> Yes. I will clarify this.
> 
>> Are BGP Labeled IPv4/IPv6 prefixes [RFC3107] excluded for a reason?
>>
> 
> Will add BGP labeled prefixes to the list.
> 
>> Also, for the e) FECs, there is the VCCV signaling aspects to be
>> considered, from RFC4447 / RFC5085 to provide the VCCV control channel
>> associated with the PW before BFD could be sent. Please also see last
>> comment.
>>
> 
> More on this below.

Thanks, please see below as well.

> 
>> ---
>>
>> 3.2. Using BFD in Conjunction with LSP-Ping
>>
>>         a) Association of a LSP-Ping echo request message with a FEC. In
>>       the case of Penultimate Hop Popping (PHP), for a single label stack
>>       LSP, the only way to associate a fault detection message with a FEC
>>       is by carrying the FEC in the message.
>>
>> Is this the case not only for PHP but also for UHP with exp-null?
> 
> Correct. Will clarify this.
> 
>> Additionally for aggregated FECs in general (e.g., in the case of
>> per-VRF label vs. per-VPNv4-FEC label, etc) the same applies but OTOH
>> there would need to be only one BFD session per "vrf aggregated fec"
>> (since it's the same label stack for different VPNv4 FECs, and the LSP
>> being tested is identical), correct? Could this be clarified in the
>> document?
>>
> 
> The spec is clear on this subject in section 4:
> 
> "If the LSP
>    is associated with multiple FECs, a BFD session SHOULD established
>    for each FEC. For instance this may happen in the case of next-hop
>    label allocation. Hence the operation is conceptually similar to the
>    data plane fault detection procedures of LSP-Ping."
> 
> 

OK, Thanks, that's clear (sorry I missed it when reading the previous 
part). And implicit-ack on the responses I skip over.

> 
>>       LSP-Ping provides this
>>       functionality. Next-hop label allocation also makes it necessary to
>>       carry the FEC in the fault detection message as the label alone is
>>       not sufficient to identify the LSP being verified.
>> ...
>>       i) LSP-Ping is used for boot-strapping the BFD session as described
>>       later in this document.
>>
>> There seem to be cases where there is no need for boot-strapping the BFD
>> session with LSP-Ping. For example, for PWs, both ends can start sending
>> BFD Control messages with Your Discr value of zero in an Active role, as
>> the PW Label provides the context to bootstrap the session.
>>
> 
> Please see below.
> 
>> ---
>>
>> 4. Theory of Operation
>>
>>       If there are multiple alternate paths from an ingress LSR to an
>>       egress LSR for a LDP IP FEC, LSP-Ping traceroute MAY be used to
>>       determine each of these alternate paths. A BFD session SHOULD be
>>       established for each alternate path that is discovered.
>>
>> There may also be multiple ECMPs for other FECs, like VPNv4/VPNv6
>> prefixes. Does this SHOULD apply to those as well?
> 
> No. As in those cases the ingress LSR knows the multiple paths and there
> is no need to use the LSP-traceroute mechanism.
> 
>> For other FECs, there
>> wouldn't be ECMPs (e.g., PWs RFC 4928), should that be explicitly mentioned?
>>
> 
> No. The above text applies only to the LDP ECMP case.

I meant for VPNv4 stacked over LDP FECs. Testing a VPNv4 FEC may result 
in multipaths from the underlying LDP ECMPs. Does the SHOULD apply in 
that case as well?

> 
>> ---
>>
>> 5. Initialization and Demultiplexing
>>
>>
>>     A BFD session may be established for a FEC associated with a MPLS
>>     LSP. As desribed above in the case of PHP and next-hop label
>>     allocation the BFD control packet received by the egress LSR does not
>>     contain sufficient information to associate it with a BFD session.
>>     Hence the demultiplexing MUST be done using the remote discriminator
>>     field in the received BFD control packet. The exchange of BFD
>>     discriminators for this purpose is described in the next section.
>>
>> 6. Session Establishment
>>
>>     To establish a BFD session a LSP-Ping echo
>>     request message MUST carry the local discriminator assigned by the
>>     ingress LSR for the BFD session. This MUST subsequently be used as
>>     the My Discriminator field in the BFD session packets sent by the
>>     ingress LSR.
>>
>> There seem to be other additional cases besides PHP where discriminators
>> need to be exchanged/boot-strapped (e.g., UHP and single label),
> 
> UHP is a valid case and I will mention it.
> 
>> but
>> situations where it's not needed (e.g., PWs). Should these cases be
>> enumerated/framed or clarified? Is this "MUST" (the first one in Section
>> 6) too strong considering cases where bootstrapping with LSP-Ping is not
>> needed (e.g., PWs) or should the MUST be conditioned to the cases where
>> is needed?
>>
> 
> For consistant operation of the BFD MPLS state machine the procedures in
> this document require LSP-Ping bootstrapping to all types of LSPs.
> Hence the text should stay as is.

But this adds a dependency on LSP-Ping that is not "required". Section 
3.2 of the document lists three functions for which LSP-Ping is used, 
that are not directly applicable to the PW case (a. and b. do not apply 
to PW LSPs, and c. is optionally applicable, but orthogonal/not tied to 
the BFD procedures).

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

> 
> 
>> Should the port be also included in the LSP-Ping
>> message? Or should the UDP port be allowed to change in the first packet
>> from the ingress->egress?
>> If the egress uses 3784 as dest UDP port, these two requirements from
>> [BFD-IP] seem to end up contradicting on this case:
>>
>>     The same UDP
>>     source port number MUST be used for all BFD Control packets
>>     associated with a particular session.  The source port number SHOULD
>>     be unique among all BFD sessions on the system.
>>     ...
>>     but the number of distinct uses of
>>     the same UDP source port number SHOULD be minimize
>>
>> So that would seem to leave the other two options (send the UDP Port in
>> the LSP-Ping, or allow for the UDP Port to change during the handshake.
>>
> 
> Specifying the dest port as 3784 or 4784 for the egress to ingress BFD
> packets addresses this.

 From ingress to egress, the spec says in Section 7:

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

And from egress to ingress, the spec says in Section 7:

    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.

If from egress -> ingress the dest port is 3784 or 4784, it could end up 
with both fixed src and dst ports (in which it seems it does not address 
the two requirements from [BFD-IP]). Or how would the flow be in this case?

Should the egress instead send his own MyDisc in an LSP-Ping echo reply, 
and have the ingress send the first BFD Control message? Or the ingress 
communicate also its source port in the LSP-Ping echo?

> 
>> ---
>>
>> 7. Encapsulation
>>
>>     For MPLS PWs, alternatively,
>>     the presence of a fault detection message may be indicated by setting
>>     a bit in the control word [VCCV].
>>
>> This procedure needs signaling or static configuration to create the
>> VCCV control channel before BFD packets could be exchanged over the
>> control channel (with the bit in the CW). Are more details needed?
> 
> I will specify that the two ends in this case are assumed to be configured
> to use this control channel. And signaling this capability is outside the
> scope of this document.

That would address the CC Type, but not the CV Type.


> 
>> See
>> below as well.
>>
>> ---
>>
>> 7. Encapsulation
>>
>>       In this case the destination IP address, used in a
>>       BFD session established for one such alternate path, is the address
>>       in the 127/8 range discovered by LSP-ping traceroute [RFC4379] to
>>       exercise that particular alternate path.
>>
>> A nit, where it says "is the address", there may be (and typically will
>> be) multiple addresses from 127/8 to exercise a particular ECMP. Should
>> that say "is one address from the 127/8 ... that exercises..."?
>>
> 
> No. It is a particular address discovered for that path. The current text
> is correct.

But multiple addresses can be discovered for that path in the Multipath 
Information field, "a particular address" is not "the address". Just a 
nit though.

> 
>> Also, there is no mention of BFD Echo adjunct function to the
>> asynchronous mode.
>>
> 
> I will specify that the echo function is out of scope.
> 
>> ---
>>
>> 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.

> 
> "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). 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), and the other limitation is 
regarding alternate encapsulations for BFD (PW-ACH mode, and functional 
modes specified as different CV Types as well).

Thanks again,

--Carlos.

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

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