Re: ietf Digest, Vol 117, Issue 126

[Batuke Mandinga <[e-mail]>]

Am 27.02.2018 12:00 nachm. schrieb <[e-mail]>:

> Send ietf mailing list submissions to
>         [e-mail]
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://www.ietf.org/mailman/listinfo/ietf
> or, via email, send a message with subject or body 'help' to
>         [e-mail]
>
> You can reach the person managing the list at
>         [e-mail]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of ietf digest..."
>
>
> Today's Topics:
>
>    1. RE: Genart last call review of
>       draft-ietf-rtgwg-backoff-algo-07 ([e-mail])
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 27 Feb 2018 10:59:18 +0000
> From: <[e-mail]>
> To: Elwyn Davies <[e-mail]>
> Cc: "[e-mail]"
>         <[e-mail]>, "[e-mail]"
>         <[e-mail]>, "[e-mail]" <[e-mail]>, "Acee Lindem
>         (acee)" <[e-mail]>, "[e-mail]" <[e-mail]>
> Subject: RE: Genart last call review of
>         draft-ietf-rtgwg-backoff-algo-07
> Message-ID:
>         <14119_1519729158_5A953A06_14119_275_1_
> 53C29892C857584299CBF5D05346208A479AF926@OPEXCLILM21.
> corporate.adroot.infra.ftgroup>
>
> Content-Type: text/plain; charset="utf-8"
>
> 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:draft-
> [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.
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <https://mailarchive.ietf.org/arch/browse/ietf/attachments/
> 20180227/0b2ba9be/attachment.html>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> ietf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ietf
>
>
> ------------------------------
>
> End of ietf Digest, Vol 117, Issue 126
> **************************************
>