Subject: [Pals] Alia Atlas' Discuss on draft-ietf-pals-mpls-tp-mac-wd-02: (with DISCUSS)

From: "Alia Atlas" <[email-masked]>
Date: Mon, 19 Oct 2015 13:21:50 -0700

Alia Atlas has entered the following ballot position for
draft-ietf-pals-mpls-tp-mac-wd-02: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-pals-mpls-tp-mac-wd/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I expect that this is a very simple and quick Discuss to deal with.

1) In Sec 4.1, it first says "The retransmission MUST be
   ceased anytime when ACK is received or after three retries." which is
fine but
then - "For instance, 1 second 
   retransmission with three retries in absence of ACK response is 
   suggested in this document.  However, incremental backoff with higher
   number of retries is also feasible and may be worth consideration to 
   address the scale issues.  This document does not mandate a strict 
   guideline since there are no interoperability implications."

CLEARLY, using MUST is more than a gentle suggestion - but is exactly
mandating a strict guideline.

Please fix either the MUST or the remaining text.

---

From: "Shah, Himanshu" <[email-masked]>
Date: Thu, 22 Oct 2015 15:17:04 -0400

Sorry I missed this email earlier.. Deborah reminded me.

Thanks for your review.

You raise good point and we have agonized over this before.
I will tell you why we did not choose "MUST" and you can then provide further guidance.

As the time passes, sending and receiving of the MAC withdraw has diminishing return
and may be even harmful. The traffic in nodes present in new path have already started
building MAC database. If MAC flush arrives way later (after exponential backoff), the new
database would get flushed resulting in another broadcast (due to unknown DMAC).

So going back to the original text and your comment:
Original text: "The retransmission MUST be ceased anytime when ACK is received or after three retries."

Here MUST applies to -
- when ACK is received
- when 3 retries are done

The intervals between each retries are -
- suggested as 1 second
- but incremental backoff is also a consideration. 
   This text is from our experience on the implementation. For example if you have 1000 PWs that failover to backup PWs
   Due to primary/backup LSP going down, the sender and receiver would both become busy processing large number of WD
   Signals. A little pacing may help. However, longer backoff (as discussed above) period is not good either.
   In either case, there is no interoperability issue - so the topic is not discussed further..

Hope this clears up, at least the thinking behind it.
Please do provide guidance...

Thanks,
Himanshu

-----Original Message-----
From: Alia Atlas [mailto:[email-masked]] 
Sent: Monday, October 19, 2015 4:22 PM
To: The IESG
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Alia Atlas' Discuss on draft-ietf-pals-mpls-tp-mac-wd-02: (with DISCUSS)

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)

   ceased anytime when ACK is received or after three retries." which is fine but then - "For instance, 1 second 

CLEARLY, using MUST is more than a gentle suggestion - but is exactly mandating a strict guideline.

---

From: "Shah, Himanshu" <[email-masked]>
Date: Thu, 22 Oct 2015 17:33:56 -0400

Hi Alias -
I missed the crux of your comment.
Deborah pointed out the discrepancy.

So I agree with your comment.
Let me fix the text and reduce the scope of MUST to ACK only.

So the revised text would be -

In Sec 4.1,

Original Text: 
"The retransmission MUST be ceased anytime when ACK is received or after three retries."

Revised Text:
"The retransmission MUST be ceased anytime when ACK is received."

The rest of the text can remain same.

Does this change address your concern?

Thanks,
Himanshu

-----Original Message-----
From: Shah, Himanshu 
Sent: Thursday, October 22, 2015 3:17 PM
To: 'Alia Atlas'; The IESG
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: Alia Atlas' Discuss on draft-ietf-pals-mpls-tp-mac-wd-02: (with DISCUSS)

Thanks for your review.

As the time passes, sending and receiving of the MAC withdraw has diminishing return and may be even harmful. The traffic in nodes present in new path have already started building MAC database. If MAC flush arrives way later (after exponential backoff), the new database would get flushed resulting in another broadcast (due to unknown DMAC).

Here MUST applies to -
- when ACK is received

Thanks,
Himanshu

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 23 Oct 2015 10:50:21 +0100

In part Alia's concern is a Lynn Truss problem

https://en.wikipedia.org/wiki/Eats,_Shoots_%26_Leaves

Let's see if we can report this to cover the intent of the authors
whilst addressing Alia's concern, and at the same time making
sure we don't introduce a congestion concern.

Original text:

    The retransmission MUST be
    ceased anytime when ACK is received or after three retries.  This
    avoids unended retransmissions in the absence of acknowledgements.
    Since retransmission time interval and the maximum number of retries
    is local configuration of the sender node, it is up to the
    implementers to pick a discipline.  For instance, 1 second
    retransmission with three retries in absence of ACK response is
    suggested in this document.  However, incremental backoff with higher
    number of retries is also feasible and may be worth consideration to
    address the scale issues.  This document does not mandate a strict
    guideline since there are no interoperability implications.  However,
    implementers must consider the decaying value of delayed MAC withdraw
    signaling against possible relearning due to bidirectional traffic or
    MAC age timeout.

How about we say:

    The retransmission MUST be ceased when an ACK is received. In order
    to avoid continuous retransmissions in the absence of acknowledgements
    a method of suppressing retransmission in the absence of an acknowledgement
    MUST be implemented. A simple and well used approach is to cease
    retransmission after a small number of transmissions. A one second
    retransmission with two retries in absence of an ACK response is
    RECOMMENDED. However both the interval and the number of retries are
    a local matter which present no interworking issues and thus the operator
    MAY configure different values. Alternatively an increasing backoff delay
    with a larger number of retries MAY be implemented to
    improve scaling issues. Whilst that are no interworking issues with
    any of these methods the implementer must be mindful of not introducing
    network congestion and must take into account the decaying value of
    delayed MAC withdraw signaling against possible relearning due to
    bidirectional traffic or MAC age timeout.

- Stewart

---

From: Alia Atlas <[email-masked]>
Date: Fri, 23 Oct 2015 14:29:33 -0400

Stewart,

Your text is great.

Thanks,
Alia

---

From: "Shah, Himanshu" <[email-masked]>
Date: Fri, 23 Oct 2015 14:32:09 -0400

I agree as well.
I will incorporate the changes.

Thanks,
Himanshu

From: Alia Atlas [mailto:[email-masked]]
Sent: Friday, October 23, 2015 2:30 PM
To: Stewart Bryant
Cc: Shah, Himanshu; The IESG; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Alia Atlas' Discuss on draft-ietf-pals-mpls-tp-mac-wd-02: (with DISCUSS)

Stewart,

Your text is great.

Thanks,
Alia

On Fri, Oct 23, 2015 at 5:50 AM, Stewart Bryant <[email-masked]<mailto:[email-masked]>> wrote:

Original text:

   MAC age timeout.

How about we say:

- Stewart