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

From: "AISSAOUI Mustapha" <[email-masked]>
Date: Wed, 8 Apr 2009 09:21:08 -0500

Dear all,
as requested by Matthew, I reviewed this draft and I have compiled my
comments below.
 
Regards,
Mustapha.
---------------------------------------------------
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.

---------------------------------------------------

________________________________

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of BOCCI Matthew
	Sent: Monday, March 09, 2009 11:09 AM
	To: [email-masked]
	Subject: [PWE3] draft-ietf-pwe3-vccv-bfd-03.txt WG last call

	This is the start of working group last call on
draft-ietf-pwe3-vccv-bfd-03.txt 

	This draft can be found at: 

http://www.ietf.org/internet-drafts/draft-ietf-pwe3-vccv-bfd-03.txt
<http://www.ietf.org/internet-drafts/draft-ietf-pwe3-vccv-bfd-03.txt>  

	The last call will close on Monday 6th April 2009. 

	Please read the document and provide feedback to the PWE3 list. 

	Many thanks to the following, who have also kindly agreed to
review the draft and provide comments to the list: 
	Ben Niven-Jenkins 
	Mustapha Aissaoui 
	Luca Martini 
	Yaakov Stein 

	Best regards 

	Matthew

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Wed, 8 Apr 2009 14:22:39 -0500

MA> I do not believe that BFD as defined today supports this mode of
operation. This mode requires that each
MA> PE be able to declare the PW to be down in the receive direction
independently based on not receiving a
MA> number of BFD control messages during a number of time intervals.
This mode would be similar to the way
MA> ATM and Ethernet CC work. 
 
Mustapha,
 
I had a different interpretation of the way BFD works. In the
asynchornous mode, which the vccv-bfd draft prescribes, each end point
checks for the arrival of control messages sent by the remote end. If it
does not receive control messages, it enters the DOWN state. This is
specified in section 6.2.
 
Since the flow of control messages consists of two independent,
uni-directional flows, isn't it true that the downstream PE can
autonomously declare a receive defect?
 
Peter

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of AISSAOUI Mustapha
	Sent: Wednesday, April 08, 2009 10:21 AM
	To: Bocci, Matthew (Matthew); [email-masked]
	Subject: Re: [PWE3] draft-ietf-pwe3-vccv-bfd-03.txt WG last call

	Dear all,
	as requested by Matthew, I reviewed this draft and I have
compiled my comments below.
	 
	Regards,
	Mustapha.

	"

	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: 

	....

	"

	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. 

	"

	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.

	"

	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. 

		From: [email-masked]
[mailto:[email-masked]] On Behalf Of BOCCI Matthew
		Sent: Monday, March 09, 2009 11:09 AM
		To: [email-masked]
		Subject: [PWE3] draft-ietf-pwe3-vccv-bfd-03.txt WG last
call

		Please read the document and provide feedback to the
PWE3 list. 

		Many thanks to the following, who have also kindly
agreed to review the draft and provide comments to the list: 
		Ben Niven-Jenkins 
		Mustapha Aissaoui 
		Luca Martini 
		Yaakov Stein 

		Best regards 

		Matthew