Re: [PWE3] Auth48 comments on draft-ietf-pwe3-static-pw-status-10

"Bocci, Matthew (Matthew)" <matthew.bocci@alcatel-lucent.com> Thu, 16 February 2012 10:05 UTC

Return-Path: <matthew.bocci@alcatel-lucent.com>
X-Original-To: pwe3@ietfa.amsl.com
Delivered-To: pwe3@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5573F21F86F2; Thu, 16 Feb 2012 02:05:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.802
X-Spam-Level:
X-Spam-Status: No, score=-105.802 tagged_above=-999 required=5 tests=[AWL=-1.854, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MANGLED_LIST=2.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Deso07Afb70X; Thu, 16 Feb 2012 02:05:23 -0800 (PST)
Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by ietfa.amsl.com (Postfix) with ESMTP id AEE7F21F871D; Thu, 16 Feb 2012 02:05:10 -0800 (PST)
Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q1G9xrAL005020 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 16 Feb 2012 11:03:20 +0100
Received: from FRMRSSXCHMBSA3.dc-m.alcatel-lucent.com ([135.120.45.34]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Thu, 16 Feb 2012 11:02:53 +0100
From: "Bocci, Matthew (Matthew)" <matthew.bocci@alcatel-lucent.com>
To: Gregory Mirsky <gregory.mirsky@ericsson.com>, "pwe3@ietf.org" <pwe3@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>
Date: Thu, 16 Feb 2012 11:02:51 +0100
Thread-Topic: Auth48 comments on draft-ietf-pwe3-static-pw-status-10
Thread-Index: AczskiYGRqS0mn8KS3+tOKP48PqizA==
Message-ID: <CB6284AB.23A4E%matthew.bocci@alcatel-lucent.com>
In-Reply-To: <FE60A4E52763E84B935532D7D9294FF1322B42FE15@EUSAACMS0715.eamcs.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.14.0.111121
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_CB6284AB23A4Ematthewboccialcatellucentcom_"
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80
Cc: "pwe3-chairs@tools.ietf.org" <pwe3-chairs@tools.ietf.org>, Stewart Bryant <stbryant@cisco.com>
Subject: Re: [PWE3] Auth48 comments on draft-ietf-pwe3-static-pw-status-10
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pwe3>, <mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:pwe3-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Feb 2012 10:05:25 -0000

Greg,

That is fine with me.

Best regards

Matthew

On 15/02/2012 22:14, "Gregory Mirsky" <gregory.mirsky@ericsson.com<mailto:gregory.mirsky@ericsson.com>> wrote:

Dear Matthew, Authors, et al.,
I think that new text of fourth para in Section 5.3 adds some confusion. If intension is to stop sending 'all clear' after three one-second intervals went unacknowledged but before refresh timer expires then perhpas new text can be more explicit:
NEW:
To clear a particular status fault, the PE need only send an
updated message with the corresponding bit cleared.  If the PW status
code is zero, the PW OAM message will be sent like any other PW OAM
status message using the procedures described above; however,
transmission will cease after 3 PW status messages have been sent at one second intervals and before refresh timer expires. A PW
status message of zero MAY be acknowledged as per the procedures described
in Section 5.3.1. If it is acknowledged, then a timer
value of zero MUST be used.  This SHOULD cause the PE sending the PW status
notification message with a PW status code equal to zero to stop sending
 and to continue normal operation.

    Regards,
        Greg

________________________________
From: pwe3-bounces@ietf.org<mailto:pwe3-bounces@ietf.org> [mailto:pwe3-bounces@ietf.org] On Behalf Of Bocci, Matthew (Matthew)
Sent: Wednesday, February 15, 2012 7:10 AM
To: pwe3@ietf.org<mailto:pwe3@ietf.org>; ietf@ietf.org<mailto:ietf@ietf.org>
Cc: pwe3-chairs@tools.ietf.org<mailto:pwe3-chairs@tools.ietf.org>; Stewart Bryant
Subject: [PWE3] Auth48 comments on draft-ietf-pwe3-static-pw-status-10

During Auth 48, the authors of draft-ietf-pwe3-static-pw-status found some issues with the acknowledgement procedures in Section 5.3 of the draft that we feel should be addressed before publication. Since the draft has already been through WG and IETF last call, we would like to highlight the proposed changes to the working group and solicit feedback.

Best regards,

Matthew

Section 5.3, 3rd paragraph:
Reason for change:
The current suggested default refresh timer value is too short to allow scaling
to very large numbers of PWs while minimising the overhead. It is also inconsistent
with the suggested default requested in an ACK packet. Therefore we suggest increasing
the default to 600secs.

OLD: The suggested default value for the refresh timer is 30 seconds.

NEW: The suggested default value for the refresh timer is 600 seconds.



Section 5.3, 4th paragraph:
Reason for change:
The current text requires that a receiving PE must acknowledge a PW status message
of 'clear all faults' in order to force a transmitter to stop sending PW status
messages at 1 second intervals.  We are concerned that a mandatory acknowledgement
adds an unnecessary complexity to the protocol which is inconsistent with
the use of the acknowledgement as per the following section (5.3.1). Additionally,
we are also concerned that this may cause problems if a transmitter
is flapping between 'clear all faults' and a non-zero value, and if the
acknowledgement is lost. We therefore suggest that the acknowledgement to
'clear all faults' be made optional, and that  the transmitter behavior be changed so
that it sends up to 3 status messages of zero in a row, and then goes silent.

OLD:
To clear a particular status fault, the PE need only send an
updated message with the corresponding bit cleared.  If the PW status
code is zero, the PW OAM message will be sent like any other PW OAM
status message using the procedures described above; however, it MUST be
acknowledged with a packet with a timer value of zero.  This will cause
the PE sending the PW status notification message with a PW status code
equal to zero to stop sending and to continue normal operation.


NEW:
To clear a particular status fault, the PE need only send an
updated message with the corresponding bit cleared.  If the PW status
code is zero, the PW OAM message will be sent like any other PW OAM
status message using the procedures described above; however,
transmission will cease after 3 PW status messages have been sent. A PW
status message of zero MAY be acknowledged as per the procedures described
in Section 5.3.1. If it is acknowledged, then a timer
value of zero MUST be used.  This SHOULD cause the PE sending the PW status
notification message with a PW status code equal to zero to stop sending
 and to continue normal operation.


Section 5.3.1, 1st paragraph:
Reason for change:
The procedures currently defined in this paragraph can lead to a receiver
of the static status message timing out if it requests, throught the use of the
ACK mechanism, a longer refresh timer from the transmitter. This is because the
current text implies that the transmitter change its referesh timer immediately
on receipt of the ack packet from the receiver. The new text clarifies that
the refresh timer be updated at the end of the current refresh interval, as
well as making some other editorial clarifications.

OLD:
The PE receiving a PW OAM message containing a PW status message
can acknowledge the PW status message by simply building an almost
identical reply packet with the A bit set, and transmitting it on the PW
ACH back to the source of the PW status message.  The timer value set in
the reply packet SHOULD then be used by the PE as the new transmit
interval.  If the transmitting PE does not want to use the new timer
value (for local policy reasons, or because it simply cannot support
it), it MUST refresh the PW OAM message with the timer value it desires.
The receiving PE will then set its timeout timer according to the timer
value that is in the packet received, regardless of what timer value it
sent.  The receiving PE MUST NOT retry to set the timer value more than
once per timer value.

NEW:
A PE receiving a PW OAM message containing a PW status message MAY
acknowledge the PW status message by simply building a reply packet
with the same format and status code as the received PW OAM message,
but with the A bit set, and transmitting it on the PW ACh back
to the source of the PW OAM message.  The receiving PE MAY use the
refresh timer field in the acknowledgement packet to request a new
refresh interval from the originator of the PW OAM message. The timer
value set in the reply packet SHOULD then be used by the originator of
the PW OAM message as the new transmit interval.  If the requested
refresh timer value is used, the PW OAM message transmission interval is
only set to the new value and the new value sent in the next PW OAM
message, when the current timer expires. If the transmitting PE does not
want to use the new timer value (for local policy reasons, or because it
simply cannot support it), it MUST refresh the PW OAM message with the
timer value it desires. The receiving PE will then set its timeout timer
according to the new refresh timer value that is in the packet received,
regardless of what timer value it requested.  The receiving PE MUST NOT
request a new refresh timer value more than once per refresh interval.