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