[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PWE3] draft-ietf-pwe3-vccv-bfd-03.txt WG last call
Hi all,
I have a comment on the following statement below
> 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.
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: pwe3-bounces at ietf.org [mailto:pwe3-bounces at ietf.org] On Behalf Of Carlos Pignataro
Sent: mercoledì 6 maggio 2009 2.42
To: AISSAOUI Mustapha
Cc: BOCCI Matthew; BUSSCHBACH Peter; pwe3 at ietf.org
Subject: Re: [PWE3] draft-ietf-pwe3-vccv-bfd-03.txt WG last call
Mustapha,
On 5/5/2009 6:00 PM, AISSAOUI Mustapha wrote:
> 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.
Delayed Ack -- thanks again, Peter.
> 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'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.
>
> 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.
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
> already updated this in version 10 of the draft. Thanks.
For my clarification, this is already resolved in pwe3-oam-msg-map-10, correct?
>
> 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.
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.
>
> Regards,
> Mustapha.
>
> ------------------------------------------------------------------------
> *From:* Busschbach, Peter B (Peter)
> [mailto:busschbach at alcatel-lucent.com]
> *Sent:* Wednesday, April 08, 2009 3:23 PM
> *To:* AISSAOUI Mustapha; BOCCI Matthew; pwe3 at ietf.org
> *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:* pwe3-bounces at ietf.org [mailto:pwe3-bounces at ietf.org] *On
> Behalf Of *AISSAOUI Mustapha
> *Sent:* Wednesday, April 08, 2009 10:21 AM
> *To:* Bocci, Matthew (Matthew); pwe3 at ietf.org
> *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:* pwe3-bounces at ietf.org [mailto:pwe3-bounces at ietf.org]
> *On Behalf Of *BOCCI Matthew
> *Sent:* Monday, March 09, 2009 11:09 AM
> *To:* pwe3 at ietf.org
> *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_
>
>
> 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
> pwe3 at ietf.org
> https://www.ietf.org/mailman/listinfo/pwe3
_______________________________________________
pwe3 mailing list
pwe3 at ietf.org
https://www.ietf.org/mailman/listinfo/pwe3