ietf
[Top] [All Lists]

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

2012-02-16 05:49:28
Having spoken to a number of the authors at length
I think  the text changes that Matthew has proposed
are correct (with Greg's change) and thank the authors
for picking this up.

I propose to let this sit until a week tomorrow (23/Feb)
and provided that there are no technical issues with the
proposed changes I will ask the RFC Editor to make
the changes and to publish the RFC.

- Stewart


On 16/02/2012 10:02, Bocci, Matthew (Matthew) wrote:
Greg,

That is fine with me.

Best regards

Matthew

On 15/02/2012 22:14, "Gregory Mirsky" <gregory(_dot_)mirsky(_at_)ericsson(_dot_)com <mailto:gregory(_dot_)mirsky(_at_)ericsson(_dot_)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(_at_)ietf(_dot_)org 
<mailto:pwe3-bounces(_at_)ietf(_dot_)org>
    [mailto:pwe3-bounces(_at_)ietf(_dot_)org] *On Behalf Of *Bocci, Matthew 
(Matthew)
    *Sent:* Wednesday, February 15, 2012 7:10 AM
    *To:* pwe3(_at_)ietf(_dot_)org <mailto:pwe3(_at_)ietf(_dot_)org>; 
ietf(_at_)ietf(_dot_)org
    <mailto:ietf(_at_)ietf(_dot_)org>
    *Cc:* pwe3-chairs(_at_)tools(_dot_)ietf(_dot_)org
    <mailto:pwe3-chairs(_at_)tools(_dot_)ietf(_dot_)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.



--
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html


_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
<Prev in Thread] Current Thread [Next in Thread>