Subject: [PWE3] BFD for MPLS PWs

From: "Yaakov Stein" <[email-masked]>
Date: Mon, 31 Jul 2006 18:02:01 +0200

Rahul, 
 
At the PWE session you stated that the MPLS BFD draft
described the use of BFD for PWs, and that the VCCV draft
and the BFD MPLS draft need to remain aligned.
 
The only mention I find in draft draft-ietf-bfd-mpls-03.txt of PWs
is the following motivational text:
 
   2. MPLS Pseudo Wires (PW). Fast detection may be desired for MPLS
   PWs depending on i) the model used to layer the MPLS network with the
   layer 2 network. and ii) the service that the PW is emulating. For a
   non-overlay model between the layer 2 network and the MPLS network
   the provider may rely on PW fault detection to provide service status
   to the end-systems. Also in that case interworking scenarios such as
   ATM/Frame Relay interworking may force periodic PW fault detection
   messages. Depending on the requirements of the service that the MPLS
   PW is emulating, fast failure detection may be desirable. Use of BFD
   for PWs is further described in [VCCV] and [OAM-MAP].

I don't see any normative text here, and certainly nothing describing
whether or not UDP is used. What I do see is a pointer to VCCV,
so that any changes in VCCV should reflect here.

Section 4 on "theory of operation" seems to be silent on PW issues.

Am I missing something?

Y(J)S

_______________________________________________
pwe3 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pwe3

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Mon, 31 Jul 2006 15:28:36 -0400

> Section 4 on "theory of operation" seems to be silent on PW issues.

	It was my assumption that the text in VCCV would
stipulate the encapsulation (this is the new text that
was proposed during and modified later based on comments
from those who objected after the meeting). VCCV also
stipulates how to use this mode and or makes references
where necessary.

	I do agree with Yaakov in that I think that
the text in the BFD/MPLS draft referencing PWE3
should be stripped altogether.

	--Tom

---

From: Rahul Aggarwal <[email-masked]>
Date: Mon, 31 Jul 2006 13:07:30 -0700 (PDT)

Hi Yaakov,

> Section 4 on "theory of operation" seems to be silent on PW issues.

a) Section 3.1.

"The LSP may be  associated with any of the following FECs:
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]"

Note (e). This implies that the procedures in this draft apply to all of
the above FECs, including PWs.

b) Section 7.

"BFD control packets sent by the ingress LSR MUST be encapsulated in
   the MPLS label stack that corresponds to the FEC for which fault
   detection is being performed. If the label stack has a depth greater
   than one, the TTL of the inner MPLS label MAY be set to 1. This may
   be necessary for certain FECs to enable the egress LSR's control
   plane to receive the packet [LSP-Ping]. For MPLS PWs, alternatively,
   the presence of a fault detection message may be indicated by setting
   a bit in the control word [VCCV]."

The above describes the encapsulation from the ingress to the egress LSR
and applies to PWs as well. It allows for VCCV procedures for indicating
whether a message is a fault detection message.

Further, the following para completes the encapsulation description:

"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]. The source
   IP address is a routable address of the sender. The destination IP
   address is randomly chosen from the 127/8 range, with the following
   exception. If the FEC is a LDP IP FEC the ingress LSR may discover
   multiple alternate paths to the egress LSR for this FEC using LSP-
   ping traceroute. 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."

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

The BFD control packet sent by the egress LSR to the ingress LSR MAY
   be routed based on the destination IP address as per the procedures
   in [BFD-MHOP]. Or the BFD control packet sent by the egress LSR to
   the ingress LSR MAY be encapsulated in a MPLS label stack. If this is
   the case the presence of  the fault detection message is indicated as
   described above.  This may be the case if the FEC for which the fault
   detection is being perfomed corresponds to a bi-directional LSP or a
   MPLS PW. This may also be the case when there is a return LSP from
   the egress LSR to the ingress LSR."

This describes the encapsulation from egress to ingress and states that
for a MPLS PW, the return epackets are UDP packets encapsulated in a MPLS
label stack of the FEC.

The above, (a), (b) and (c) spell out the encapsulation procedures for BFD
for MPLS PWs. Further they point to VCCV for defining how the fault
detection messages are indicated, other than using the TTL.

To put it differently, the BFD-MPLS spec, applies to all FECs in section
3.1. Where there are additional details, eg. PWs, the spec spells out
these details or points to specs that spell out the details, eg. VCCV.

Hope this helps.

rahul

---

From: Rahul Aggarwal <[email-masked]>
Date: Mon, 31 Jul 2006 13:19:52 -0700 (PDT)

Hi Tom,

On Mon, 31 Jul 2006, Thomas D. Nadeau wrote:

> from those who objected after the meeting).

Can you please send a pointer to this new text ?

> VCCV also

BFD-MPLS spells out the generic procedures for various FECs including the
PW FEC. Why should these procedures not apply to the PW FEC ?

rahul

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Mon, 31 Jul 2006 16:47:42 -0400

> PW FEC. Why should these procedures not apply to the PW FEC ?

	The reasons that were explained during the meeting:

	1) sending the IP/UDP header is redundant
		for SH PWs because the labels or outer l2tpv3 header
		ID the VCCV payload.

	2) If you include the 127/ dest. address, then it is useless other
		than it prevents errant routing if the PW header
		is inadvertently stripped.  However, skipping the
		IP header altogether obviates both problems. It
		also makes each VCCV/BFD packet shorter.

	2) sending the IP/UDP header is useless for MH PWs because
		the MH PW addressing scheme will not fit into
		an IPv4 address.  Instead, the outer PW encapsulation
		identifies the destination.

	3) the secondary routing header lookup/processing is
		a waste of processing cycles since it should
		always result in the receiving PE. The outer
		header identifies the PW packet already.

	Conversations with everyone except yourself (I couldn't
find you after PWE3) that objected to the removal of the UDP/IP
header at the meeting, all agreed that this was okay assuming that
we add two new CV types to explicitly identify when the header
is and is not included for BFD messages so that we can support
older implementations. I will have the text for this shortly
and will send it out.

	--Tom