RE: Genart last call review of draft-ietf-rtgwg-backoff-algo-07

[<[e-mail]>]

Hi Elwyn

> I'll await the new version.


https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-backoff-algo-08



Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtgwg-backoff-algo-08

Thanks again for your review and comments.

--Bruno

From: Elwyn Davies [mailto:[e-mail]]
Sent: Tuesday, February 20, 2018 2:29 PM
To: Acee Lindem (acee); [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: Re: Genart last call review of draft-ietf-rtgwg-backoff-algo-07

Hi.

Thanks for the response.

Couple of points:
- Where I have suggested lower case 'recommended' it is because they are not normatively enforceable - they are operational decisions that don't affect the bits on the wire.  There are a couple of others I missed (see recent DISCUSS).
- s1, para 2: Try 'happening' instead of 'eventuating'.

s1, para 2:' Jargon 'removal':  BTW I wasn't suggesting removing the rest of the sentence (after 'and') - the comment on micro-loops is definitely helpful.

s8: I wasn't trying to suggest that the algorithms described using the other terms would be replaced, but merely that the document  provides an alternative way of implementing the concepts but with different names.

I'll await the new version.

Cheers,
Elwyn


Sent from Samsung tablet.

-------- Original message --------
From: "Acee Lindem (acee)" <[e-mail]<mailto:[e-mail]>>
Date: 16/02/2018 18:39 (GMT+00:00)
To: Elwyn Davies <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>, [e-mail]<mailto:[e-mail]>, [e-mail]<mailto:[e-mail]>
Subject: Re: Genart last call review of draft-ietf-rtgwg-backoff-algo-07

Hi Elwyn,

Also thank you much for your editorial comments. I must say I'm surprised that we didn’t catch some of these before. We will adopt most of them. One thing I'm not clear on is why you believe we should change RECOMMENDED to lowercase in the deployment recommendations. Unless convinced otherwise, we'll leave this for the IESG to decide. See inline.

On 2/15/18, 2:12 PM, "Elwyn Davies" <[e-mail]<mailto:[e-mail]>> wrote:

    Nits/editorial comments:
    General: The term 'back-off' may not be familiar to non-Emglish mother tongue
    speakers and on first occurrence needs a little explanation for naive readers
    to indicate what it means and to what the back-off is being applied.  I have
    suggested some additional text to this end for the abstract and s1.

    Abstract:
    OLD:
       This document defines a standard algorithm to back-off link-state IGP
       Shortest Path First (SPF) computations.
    NEW:
       This document defines a standard algorithm to temporararily postpone or
       'back-off' link-state IGP Shortest Path First (SPF) computations to reduce
       the computational load on IGP nodes if network events occurring at closely
       spaced times would otherwise lead to multiple, essentially redundant
       recalculations of the routing tables.
    ENDS

This is a rather long sentence. I don't have a problem with adding "to temporarily postpone or".  However, I'd split the second clause into a new sentence and shorten it.

       This reduces the computational load on IGP nodes when multiple network events trigger multiple SPF computations over a short time interval.

Or simply:

            This reduces the computational load on IGP nodes when multiple temporally close network events trigger multiple SPF computations.


    s1, para 1: s/at the same time/essentially at the same time/

Ok,


    s1, para 2: s/new Shortest Path First (SPF)/new Shortest Path First (SPF)
    routing table/

We already changed this as per Benjamin's comment.

    s1, para 2:
    OLD:
       experiencing multiple temporally close failures over a short
       period of time
    NEW:
       experiencing multiple temporally close failures (that is, eventuating over a
       short period of time)
    ENDS

I'm not sure "eventuating" is any clearer than "temporally" and the latter is more precise.


    s1, para 2: There is a right bracket missing in the following and starting a
    clause with 'such as' and ending it with an ellipsis ('...') is redundant. >
    such as LDP [RFC5036], RSVP-TE [RFC3209], >    BGP [RFC4271], Fast ReRoute
    computations (e.g.  Loop Free Alternates >    (LFA) [RFC5286], FIB updates...
    It is unclear to me where the bracket should go: maybe after [RFC5286] or at
    the end. Please clarify.

This should be
(e.g.,  Loop Free Alternates   (LFA) [RFC5286], FIB updates, etc.).


    s1, para 2: the phrase
    > This also reduces the churn on
    >    routers and in the network and.
    is useless, vague jargon.  The previous sentence expresses what I suspect is
    meant by 'churn'. so this is redundant and can be omitted.

We definitely want the explicitly reference to microloops and this clause sets the correct context. Perhaps, we could shortend to "This also reduces network churn and".


    s1, para 3:
    OLD:
    To allow for this, IGPs implement an SPF back-off algorithm.
    NEW:
    To allow for this, IGPs usually implement an SPF back-off algorithm that
    postpones or backs-off the running of the SPF calculation when the algorithm
    predicts that a run would be essentially redundant or even counter-productive
    because it appears that multiple closely timed routing-affecting events can be
    expected. ENDS

I think if you have read paragraph 2, the motivation is clear. However, I'd be okay with:

     To allow for this, IGPs usually implement an SPF back-off algorithm that
     postpones or backs-off the SPF computation.

    s1, para 3: s/choosen/chosen/

Ok.

    s2, last bullet: SPF_DELAY is not defined at this point:
    s/SPF_DELAY timers values/values for any timers used to back-off SPF
    calculations/

Lets do a reference to section 3 instead "SPF_DELAY [Section 3]"

    s2, last bullet:  s/Even though/This is important even though/

Ok. As you noticed, this wasn't really a complete sentence.

    s3, para 1: Undesirable ellipsis:
    s/a metric change on a link or prefix.../and a metric change on a link or
    prefix./

Ok.

    s3:Need to expand SRLG on first use - it isn't deemed to be well-known.

Already handled in Benjamin's comments.


    s3, INITIAL_SPF_DELAY bullet: s/A very small delay to quickly handle link
    failure/A very small delay to quickly handle a single isolated link failure/

Ok.

    s3, SHORT_SPF_DELAY bullet:
    OLD:
        SHORT_SPF_DELAY: A small delay to have a fast convergence in case of
        a single failure (node, SRLG..), e.g., 50-100 milliseconds.
    NEW:
        SHORT_SPF_DELAY: A small delay to provide fast convergence in the case of
        a single component failure (node, SRLG..) that leads to multiple IGP events,
        e.g., 50-100 milliseconds.
    ENDS

Ok.

    s5/s5.1: There is currently no text in s5: this is generally considered
    inappropriate.  Suggest removing the first sentence in s5.1 ("This section
    describes the state machine.") and adding to s5: NEW: This section describes
    the abstract finite state machine (FSM) intended to control the timing of the
    running of SPF calculations in response to IGP events.

Ok - I'd replace "running" with "execution" or "scheduling".

    s5.1, QUIET bullet: s/occured/occurred/

Ok.

    s5.2:  There is no need for 3 expansions of FSM - the expansion can be moved to
    s5 as suggested above.

Ok.

    s5.3 title: s/States/State/

Ok.

    s6, next to last para: s/it's RECOMMENDED to play it safe/it is recommended
    that timer intervals should be chosen conservatively/ (this is an operational
    recommendation).

Ok with the rewording but why not uppercase "RECOMMENDED".

    s6, last para: s/RECOMMENDED/recommended/ (ditto).

Same question on uppercase.

    s7, para 1: s/is based on/is dependent on/, s/RECOMMENDED/recommended/
    (operational again)

Ok with wording but same question on uppercase.

    s8: Other documents (e.g., from vendors) have used the terms SPF wait time and
    SPF hold time.  It might be useful to mention that this document essentially
    provides ways to implement these settings.

No. I can you tell you with a fair amount of certainty that vendors will not change their existing SPF delay/backoff configuration definitions (at least not vendors with large deployments). Rather, this algorithm will be added as a new configuration options and, hopefully, become the default after some period of adoption and operational experience. Configuration of this standard algorithm is reflected as  a separate container in the OSPF and IS-IS YANG models.

Thanks,
Acee




_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.