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

From: "AISSAOUI Mustapha" <[email-masked]>
Date: Tue, 5 May 2009 17:00:06 -0500

All,
I had a discussion with Peter regarding my comment (1) below and he is
right that the behaviour I quoted from Section 3.1 of this draft is
actually supported in the BFD base draft. However, the two directions
are not completly independent from a state machine perspective. Although
the session failure detection is always performed by the egress PE in
the receive direction and it then notifies the ingress PE using the
Diagnostic Code 1 (Control Detection Time Expired), the egress PE cannot
transition BFD session back to the UP state unless the ingress PE
signaled back a Diagnostic code 3 (Neighbor signaled session down) or an
Init value in the Sta flags. I think it would be useful to add this
detail in Section 3.1.
 
I appreciate if the authors also updated the terminology for the
"forward defect"  and "reverse defect" PW states to match the new
terminology used in draft-ietf-pwe3-oam-msg-map.
 
My comment on draft-ietf-pwe3-oam-msg-map still holds since there is no
such a thing as "ingress PE detection of failure" with BFD. Peter
already updated this in version 10 of the draft. Thanks.
 
Also, please ignore my comment (2) regarding the reply mode. Each PE
encapsulates the BFD packets according to one of the two encapsulation
methods as per the negotiated CV type. There is no need for sending BFD
messages out-of-band.
 
I have not seen a response to the other comments below.
 
Regards,
Mustapha.

________________________________

	From: Busschbach, Peter B (Peter)
[mailto:[email-masked]] 
	Sent: Wednesday, April 08, 2009 3:23 PM
	To: AISSAOUI Mustapha; BOCCI Matthew; [email-masked]
	Subject: RE: [PWE3] draft-ietf-pwe3-vccv-bfd-03.txt WG last call

	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.
		---------------------------------------------------
		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: Carlos Pignataro <[email-masked]>
Date: Tue, 05 May 2009 20:41:02 -0400

Hello Mustapha,

Many thanks for your review and comments, and sorry for the much belated
reply. Please see inline responses to the 4 issues you raised, I hope
these help.

On 4/8/2009 10:21 AM, AISSAOUI Mustapha wrote:
> 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.
> 

1. I believe Peter already addressed this comment (thanks, Peter !). In
addition to the independent flows argument, see the usage of the Diag code.

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

2. These are MPLS Echo reply modes from
<http://tools.ietf.org/html/rfc4379#section-3> and not BFD. RE OOB, for
all cases, vccv-bfd S3.1 says:

   The BFD control packets are sent on the VCCV control channel.
...
   The operation of BFD VCCV for PWs is therefore symmetrical.  Both
   endpoints of the bidirectional pseudowire MUST send BFD messages on
   the VCCV control channel.

I don't think this comment applies.

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

Yes, it is a bit of a long para, however the issue is that the ordered
list is hierarchical and not plain. I mean, "A" and "B" are subordinates
to "3". Stewart already mentioned this in his review, and we'll be
changing this to "3.1" instead of "A".

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

Yes, it is implicit by virtue of inheritance from RFC5085, but I agree
it would help to add it explicitly. We can add it, thanks for bringing
it up.

Thanks,

-- Carlos.

>     ------------------------------------------------------------------------
>     *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
> 
>     _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
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pwe3

---

From: Carlos Pignataro <[email-masked]>
Date: Tue, 05 May 2009 20:41:30 -0400

Mustapha,

On 5/5/2009 6:00 PM, AISSAOUI Mustapha wrote:
> actually supported in the BFD base draft.

Delayed Ack -- thanks again, Peter.

> However, the two directions

I'd be a bit hesitant to keep adding to that description in S3.1, as I
fear it will make it more confusing. Note that the last sentence of that
paragraph also points to pwe3-oam-msg-map for "how it further processes
...", and I think that more detailed description might belong there.

> terminology used in draft-ietf-pwe3-oam-msg-map.

OK, there is one instance of "forward defect", and two instances of
"reverse defect" in the document. What should they be changed to?

> already updated this in version 10 of the draft. Thanks.

For my clarification, this is already resolved in pwe3-oam-msg-map-10,
correct?

> methods as per the negotiated CV type. There is no need for sending BFD

OK.

> I have not seen a response to the other comments below.

Sorry again for the delay, please let me know if there's concerns
unadressed.

Thanks,

-- Carlos.

>     *From:* Busschbach, Peter B (Peter)
>     *Sent:* Wednesday, April 08, 2009 3:23 PM
>     *To:* AISSAOUI Mustapha; BOCCI Matthew; [email-masked]
>     *Subject:* RE: [PWE3] draft-ietf-pwe3-vccv-bfd-03.txt WG last call
> 
>     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
>     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.
>      
>         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,
>         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].
> 
>         "
> 
>         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
>         Given that, the sender cannot tell which direction of the PW is
>         down, it must enter the PW receive defect state as explained in
>         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
>         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
>         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
>         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.
> 
>         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.
> 
>         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
>         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
>             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: "Annamaria Fulignoli" <[email-masked]>
Date: Wed, 6 May 2009 16:51:19 +0200

Hi all,
I have a comment on the following statement below 

> are not completly independent from a state machine perspective. 
> Although the session failure detection is always performed by the 
> egress PE in the receive direction and it then notifies the ingress PE 
> using the Diagnostic Code 1 (Control Detection Time Expired), the 
> egress PE cannot transition BFD session back to the UP state unless 
> the ingress PE signaled back a Diagnostic code 3 (Neighbor signaled 
> session down) or an Init value in the Sta flags. I think it would be 
> useful to add this detail in Section 3.1.

Looking at the State Machine reported in draft-ietf-bfd-base-09.txt, at section 6.2, at section 6.8.6 ( updated by section 4.16.1 of draft-katz-ward-bfd-multipoint-02) the state transition occurs for defect ( in this case for expiration of the Detection Timer ) event and on the received BFD's State field (Sta field) and not on the base of the Diagnostic code (Diag field). 

Thank you.
Best regards, Annamaria

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Carlos Pignataro
Sent: mercoledì 6 maggio 2009 2.42
To: AISSAOUI Mustapha
Cc: BOCCI Matthew; BUSSCHBACH Peter; [email-masked]
Subject: Re: [PWE3] draft-ietf-pwe3-vccv-bfd-03.txt WG last call

Mustapha,

> are not completly independent from a state machine perspective. 
> Although the session failure detection is always performed by the 
> egress PE in the receive direction and it then notifies the ingress PE 
> using the Diagnostic Code 1 (Control Detection Time Expired), the 
> egress PE cannot transition BFD session back to the UP state unless 
> the ingress PE signaled back a Diagnostic code 3 (Neighbor signaled 
> session down) or an Init value in the Sta flags. I think it would be 
> useful to add this detail in Section 3.1.

I'd be a bit hesitant to keep adding to that description in S3.1, as I fear it will make it more confusing. Note that the last sentence of that paragraph also points to pwe3-oam-msg-map for "how it further processes ...", and I think that more detailed description might belong there.

> terminology used in draft-ietf-pwe3-oam-msg-map.

OK, there is one instance of "forward defect", and two instances of "reverse defect" in the document. What should they be changed to?

>  
> My comment on draft-ietf-pwe3-oam-msg-map still holds since there is 
> no such a thing as "ingress PE detection of failure" with BFD. Peter 

For my clarification, this is already resolved in pwe3-oam-msg-map-10, correct?

> methods as per the negotiated CV type. There is no need for sending 
> BFD messages out-of-band.

OK.

> I have not seen a response to the other comments below.

Sorry again for the delay, please let me know if there's concerns unadressed.

Thanks,

-- Carlos.

---

From: "AISSAOUI Mustapha" <[email-masked]>
Date: Wed, 6 May 2009 14:14:19 -0500

Annamaria,
That is correct. The state change is always indicated in the (Sta) field and the reason for the state change is indicated in the Diag codes. This is what the draft-ietf-pwe3-vccv-bfd-03.txt stated. I just omitted that in my description below.

Mustapha.

> From: Annamaria Fulignoli [mailto:[email-masked]] 
> Sent: Wednesday, May 06, 2009 10:51 AM
> To: Carlos Pignataro; AISSAOUI Mustapha
> Looking at the State Machine reported in 
> draft-ietf-bfd-base-09.txt, at section 6.2, at section 6.8.6 
> ( updated by section 4.16.1 of 
> draft-katz-ward-bfd-multipoint-02) the state transition 
> occurs for defect ( in this case for expiration of the 
> Detection Timer ) event and on the received BFD's State field 
> (Sta field) and not on the base of the Diagnostic code (Diag field). 
> 
> Thank you.
> Best regards, Annamaria
> 
> 
> I'd be a bit hesitant to keep adding to that description in 
> S3.1, as I fear it will make it more confusing. Note that the 
> last sentence of that paragraph also points to 
> pwe3-oam-msg-map for "how it further processes ...", and I 
> think that more detailed description might belong there.
> 
> >  
> OK, there is one instance of "forward defect", and two 
> instances of "reverse defect" in the document. What should 
> they be changed to?
> 
> >  
> this mode of
> >         *Subject:* Re: [PWE3] 
> draft-ietf-pwe3-vccv-bfd-03.txt WG last 
> > call
> > 
> >         Dear all,
> >         BFD CV Type, a node MUST NOT use any of the other 
> three BFD CV
> >         Types.
> > 
> >         "
> > 
> negotiation
> >             *Subject:* [PWE3] 
> draft-ietf-pwe3-vccv-bfd-03.txt WG last 
> > call
> > 
> kindly agreed to

---

From: "AISSAOUI Mustapha" <[email-masked]>
Date: Wed, 6 May 2009 14:25:05 -0500

Hi Carlos,
Thanks for the reply. I added a few elements of response below.

Mustapha. 

> From: Carlos Pignataro [mailto:[email-masked]] 
> Sent: Tuesday, May 05, 2009 8:42 PM
> To: AISSAOUI Mustapha
> Cc: BUSSCHBACH Peter; BOCCI Matthew; [email-masked]
MA> draft-ietf-pwe3-oam-msg-map does not describe the state machine for
BFD over a PW. It only states the actions once the PW changes state
which can be the result of the BFD session changing state.

Maybe you can add a sentence at the beginning of this paragraph to say
that the details of the BFD state machine are exactly as per Section 6.2
of the BFD based draft. 

> instances of "reverse defect" in the document. What should 
MA>  "PW forward defect state" was changed to "PW receive defect state".
"PW reverse defect state" was changed to "PW transmit defect state".
 
> pwe3-oam-msg-map-10, correct?
MA> Yes.

---

From: Carlos Pignataro <[email-masked]>
Date: Thu, 07 May 2009 13:16:36 -0400

Hi Mustapha,

> that the details of the BFD state machine are exactly as per Section 6.2

Good point. This seems helpful for the doc and makes sense to me.

Thanks,

-- Carlos.