Re: [PWE3] draft-ietf-pwe3-vccv-bfd-03.txt WG last call

Comments on draft-ietf-pwe3-vccv-bfd-03

1. Section 3.1, last paragraph states:

When the downstream PE (D-PE) does not receive BFD control messages from its upstream peer PE (U-PE) during a certain number of transmission intervals (a number provisioned by the operator as Detect Mult), D-PE declares that the PW in its receive direction is down. In other words, D-PE enters the "forward defect" state for this PW. After this calculated Detection Time, D-PE declares the session Down, and signals this to the remote end via the State (Sta) with Diagnostic code 1 (Control Detection Time Expired). In turn, U-PE declares the PW is down in its transmit direction setting the State to Down, and it using Diagnostic code 3 (Neighbor signaled session down) in its control messages to D-PE. U-PE enters the "reverse defect" state for this PW. If needed, how it further processes this error condition, and conveys this status to the attachment circuits is out of the scope of this specification, and is instead defined in [I-D.ietf-pwe3-oam-msg-map].

MA> I do not believe that BFD as defined today supports this mode of operation. This mode requires that each PE be able to declare the PW to be down in the receive direction independently based on not receiving a number of BFD control messages during a number of time intervals. This mode would be similar to the way ATM and Ethernet CC work.

However, BFD requires that the sender of the messages declares the state of the PW to be down if replies to its own BFD messages were not received for a number of time intervals.

Given that, the sender cannot tell which direction of the PW is down, it must enter the PW receive defect state as explained in draft-ietf-pwe3-oam-msg-map-09.txt. However, the receiver of the messages can send a BFD status change asynchronously and in this case the sender can be sure the defect is in the forward direction, which means it must enter the PW trasmit defect state.

I believe Appendix B of draft-ietf-pwe3-oam-msg-map-09.txt must also be corrected as it states:

Furthermore, the detection of a fault could occur at different points in the network and there are several ways the observing PE determines a fault exists:

a. egress or ingress PE detection of failure (e.g. BFD)

….

2. Section 3.2 - BFD Encapsulation

MA> We need to document how the reply to the BFD packet is encapsulated. The following reply modes of "2- Reply via an IPv4/IPv6 UDP packet", "3 - Reply via an IPv4/IPv6 UDP packet with Router Alert", and "4 - Reply via application level control channel" must be documented for the UDP/IP encapsulation. The PW-ACH necapsulation can only support reply mode 4 since it cannot be routed. I believe the relevant text for this is covered in draft-ietf-bfd-mpls-07.txt.

3. Section 3.3, item (3) reads:

4. Pseudowires that do not use a CW or L2SS using the PW Associated Channel Header MUST NOT use the BFD CV Types 0x10 or 0x20 (i.e., PW-ACH encapsulation of BFD, without IP/UDP headers).

A. PWs that use a PW-ACH include CC Type 1 (for both MPLS and L2TPv3 as defined in Sections 5.1.1 and 6.1 of [RFC5085]), and MPLS CC Types 2 and 3 when using a Control Word (as specified in Sections 5.1.2 and 5.1.3 of [RFC5085]). This restriction stems from the fact that the PW-ACH contains a Protocol Identification (PID) field, the Channel Type.

B. PWs that do not use a PW-ACH can use the VCCV BFD encapsulation with IP/UDP headers, including its concurrent use along with another CV Type that uses an encapsulation with IP headers (e.g., ICMP Ping or LSP Ping). For example, as specified in Section 7 of [RFC4385], a Pseudowire operating without CW MUST NOT use the PW-ACH.

MA> This paragraph is trying to convey too many things and is confusing. I propose we split it into the case of PW with ACH and PW with no ACH. Here is a proposal which I believe covers all the intended points:

4. A PW that uses the PW-ACH must signal CC Type 1 only in the VCCV parameter included in the interface parameter field of the PW ID FEC TLV or the sub-TLV interface parameter of the Generalized PW ID FEC TLV as described in [RFC 5085].

5. A PW that does not use a PW-ACH must signal CC Types 2 and/or 3 in the VCCV parameter included in the interface parameter field of the PW ID FEC TLV or the sub-TLV interface parameter of the Generalized PW ID FEC TLV as described in [RFC 5085]. For example, this can be a PW which is configured not to use the CW on the user packets. As specified in Section 7 of [RFC4385], this PW MUST NOT use the PW-ACH.

6. A PW that does not use the PW-ACH MUST NOT use the BFD CV Types 0x10 or 0x20 (i.e., PW-ACH encapsulation of BFD, without IP/UDP headers). This restriction stems from the fact that the PW-ACH contains a Protocol Identification (PID) field, the Channel Type, which is the only way to identify BFD messages with these CV types.

7. A PW can use the VCCV BFD encapsulation with IP/UDP headers, including its concurrent use along with another CV type that uses an encapsulation with IP headers (e.g., ICMP Ping or LSP Ping), regardless if it is configured to use PW-ACH or not.

5. Section 3.3, item (4)

4. Only a single BFD CV Type can be selected and used. All BFD CV Types are mutually exclusive with the rest, after selecting a BFD CV Type, a node MUST NOT use any of the other three BFD CV Types.

MA> It must be stated that in order to change the negotiation and selection of the BFD CV types, the PW must be torn down and re-signaled.