Re: WGLC comments on bfd-mpls-05

[Rahul Aggarwal <[e-mail]>]

Hi Carlos,

<snipped>

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

No.

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

Section 3.2 states the following that applies to PWs:

"In addition to
   this presence of the FEC in the echo request message makes it
   possible to verify the control plane against the data plane at the
   egress LSR."


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

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

This is correct.

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

See above for the modified text. The intention was to use the source port
as in [BFD-IP].

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

This draft applies to *only* BFD for MPLS LSPs. Hence the CV type
discussion is simply not relevant.

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

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


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

rahul

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