Re: [Gen-art] Genart last call review of draft-ietf-homenet-babel-profile-05

[Juliusz Chroboczek]

> I am the assigned Gen-ART reviewer for this draft.

Thanks for your comments, Stewart.

>   if implementations use conflicting route selection policies,
>   persistent oscillations might occur.
SB> Is this consistent with the statement earlier in the para that
SB> " Distinct
SB> implementations of RFC 6126bis Babel will interoperate, in the
SB> sense that they will maintain a set of loop-free forwarding paths"?

Yes, it is consistent.  Please see Section 3.6 of rfc6126bis.

In short, Babel guarantees that the forwarding graph remains loop-free
at all times (which is somewhat weaker than what you'd expect -- in
particular, it does not entail that a packet will never pass the same
router more than once).  It does not make any guarantees about the
stability of the forwarding graph if the route selection policy is
completely crazy.

As far as I am aware, the problem of defining the class of non-crazy route
selection policies is an open research problem.  The best we can do, to
the best of my knowledge, is give examples of policies that do not cause
oscillations.

This is not unlike BGP, which does an excellent job avoiding loops, but
does not prevent persisten oscillations in the presence of crazy policies.
Interestingly enough, a numbre of papers indicate that this is not
a problem in the Internet, and that router operators are pretty good at
defining reasonable BGP policies.  I believe the same is true of Babel.

>  Since IPv6 has some
>   features that make implementations somewhat simpler and more
>   reliable (notably link-local addresses), we require carrying
>   control data over IPv6.
SB> Earlier you said that IPv4 also had Link Local addresses, so how
SB> can link local addresses be the deciding selection criteria? Is there
SB> something technically better about IPv6 LL?

No, I didn't -- I'm trying to be consistent, and use LL to mean fe80::/64.
I believe the issue is in Section 1, where I say

   traffic is carried over either link-local IPv6 or IPv4

where what I mean is

   either link-local IPv6 carries traffic, or IPv4 carries traffic.

I'm not a native speaker, and I'll be grateful if you can suggest a better
formulation.

> Minor issues:

>   Rationale: support for wireless transit links is a "killer
>   feature" of Homenet, something that is requested by our users and
>   easy to explain to our bosses.  In the absence of dynamically

SB> Not sure explicability to your boss counts for much as a basis for
SB> a feature an international standard.

I think this paragraph is helpful for implementors -- it helps people
explain to their bosses why we're bothering with link-quality estimation
when we've done routing protocols with no link-quality estimation for the
last fifty years or so.  (The Fuzzball LSI-11 router had link-quality
estimation, but that was in the 1980s.)  Still, if you find the tone too
informal, I'm open to reformulating.

> Abstract

>This document defines the subset of the Babel routing protocol and
>its extensions that a Homenet router must implement, as well as the
>interactions between HNCP and Babel.

SB> HNCP needs to be expanded Both need a reference, but the reference
SB> needs to be expanded i.e. RFC7788 not [RFC7788]

Is this consistent with the last sentence of RFC 7322 Section 4.3?

-- Juliusz

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] review of draft-ietf-bess-fat-pw-bgp-03.txt

[Keyur Patel]

Hi Francis,

Thanks for the review. We will update the draft with your comments(nits) in 
next revision.

Regards,
Keyur

On 2/14/18, 7:58 AM, "Francis Dupont"  wrote:

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-bess-fat-pw-bgp-03.txt
Reviewer: Francis Dupont
Review Date: 2018/02/07
IETF LC End Date: 20180209
IESG Telechat date: unknown

Summary: Ready

Major issues: None

Minor issues: None

Nits/editorial comments: 
 - Abstract page 1: please expand PE abbrev

 - PoC page 2 and 4 page 7: Acknowledgements -> Acknowledgments

 - 1 page 3: please introduce PE abbrev (it is not marked as well known
  in https://www.rfc-editor.org/materials/abbrev.expansion.txt, and
  Abstract and body are independent so an abbrev introduced in the Abstract
  should be introduced again in the body).

 - 1 page 3: ECMP is introduced twice (better than none :-).

 - 1 page 3: This draft -> This document (or specification ot ...).
  The RFC Editor should update this prior to the publication but
  making its job harder is not a good idea. So if you have another
  reason to update the document please fix this...

 -  1.1 page 4: RFC 2119 was updated by RFC 8174

 - 3 page 6: e.g. -> e.g.,

 - 3 page 7: i.e. -> i.e., (at end of line)

Regards

francis.dup...@fdupont.fr


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] review of draft-ietf-bess-fat-pw-bgp-03.txt

[Alissa Cooper]

Francis, thank you for your review. I have entered a No Objection ballot.

Alissa

> On Feb 14, 2018, at 7:58 AM, Francis Dupont  wrote:
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document: draft-ietf-bess-fat-pw-bgp-03.txt
> Reviewer: Francis Dupont
> Review Date: 2018/02/07
> IETF LC End Date: 20180209
> IESG Telechat date: unknown
> 
> Summary: Ready
> 
> Major issues: None
> 
> Minor issues: None
> 
> Nits/editorial comments: 
> - Abstract page 1: please expand PE abbrev
> 
> - PoC page 2 and 4 page 7: Acknowledgements -> Acknowledgments
> 
> - 1 page 3: please introduce PE abbrev (it is not marked as well known
>  in https://www.rfc-editor.org/materials/abbrev.expansion.txt, and
>  Abstract and body are independent so an abbrev introduced in the Abstract
>  should be introduced again in the body).
> 
> - 1 page 3: ECMP is introduced twice (better than none :-).
> 
> - 1 page 3: This draft -> This document (or specification ot ...).
>  The RFC Editor should update this prior to the publication but
>  making its job harder is not a good idea. So if you have another
>  reason to update the document please fix this...
> 
> -  1.1 page 4: RFC 2119 was updated by RFC 8174
> 
> - 3 page 6: e.g. -> e.g.,
> 
> - 3 page 7: i.e. -> i.e., (at end of line)
> 
> Regards
> 
> francis.dup...@fdupont.fr
> 
> ___
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Genart last call review of draft-ietf-tls-iana-registry-updates-04

[Stewart Bryant]

Reviewer: Stewart Bryant
Review result: Ready with Issues

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-tls-iana-registry-updates-05
Reviewer: Stewart Bryant
Review Date: 2018-02-20
IETF LC End Date: 2018-03-01
IESG Telechat date: 2018-03-08

Summary: A well written document that is difficult to check and easy to make a
mistake with. There are a tiny number of editorial matters. The matter of the
semantics of Recommended = no may need to further thought and clarification.

Major issues: None

Minor issues:

I think convention is to list the documents being updated in the Abstract, but
cannot find any formal guidance.

==

  If an item is marked as not recommended it does not necessarily mean
SB> Do you mean "marked as not recommended" or "not marked as recommended".

===
SB>  I am worried about the semantics of Recommended = no.
SB> Presumably there are three states: recommended, not recommended,
SB> and silent/don't know/don't care/not yet. Which of these
SB> states does Recommended = no represent?

Nits/editorial comments:
Abstract

   This document describes a number of changes to (D)TLS IANA registries

SB> TLS is not a well known abbreviation and so needs expanding



   This document instructs IANA to make changes to a number of (D)TLS-

SB> TLS needs expanding


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Genart telechat review of draft-ietf-ice-rfc5245bis-17

[Alissa Cooper]

Stewart, thanks for your review. I have entered a No Objection ballot.

Alissa


> On Feb 16, 2018, at 5:45 AM, Stewart Bryant  wrote:
> 
> Reviewer: Stewart Bryant
> Review result: Ready
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair. Please wait for direction from your
> document shepherd or AD before posting a new version of the draft.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document: draft-ietf-ice-rfc5245bis-17
> Reviewer: Stewart Bryant
> Review Date: 2018-02-16
> IETF LC End Date: 2018-01-26
> IESG Telechat date: 2018-02-22
> 
> Summary: A well written document ready for publication.
> 
> Major issues: None
> 
> Minor issues: None
> 
> Nits/editorial comments: None
> 
> 
> ___
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Genart last call review of draft-ietf-homenet-babel-profile-05

[Stewart Bryant]

Reviewer: Stewart Bryant
Review result: Ready with Issues

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-homenet-babel-profile-05
Reviewer: Stewart Bryant
Review Date: 2018-02-20
IETF LC End Date: 2018-02-26
IESG Telechat date: Not scheduled for a telechat

Summary: This is understandable, and close to completion. There are a few minor
points that need attention, and couple of major points that may just need
clarification.

Major issues:

 In addition,
  if implementations use conflicting route selection policies,
  persistent oscillations might occur.
SB> Is this consistent with the statement earlier in the para that
SB> " Distinct
SB>   implementations of RFC 6126bis Babel will interoperate, in the
SB>   sense that they will maintain a set of loop-free forwarding paths"?

===

 Since IPv6 has some
  features that make implementations somewhat simpler and more
  reliable (notably link-local addresses), we require carrying
  control data over IPv6.
SB> Earlier you said that IPv4 also had Link Local addresses, so how
SB> can link local addresses be the deciding selection criteria? Is there
SB> something technically better about IPv6 LL?

Minor issues:

  Rationale: support for wireless transit links is a "killer
  feature" of Homenet, something that is requested by our users and
  easy to explain to our bosses.  In the absence of dynamically

SB> Not sure explicability to your boss counts for much as a basis for
SB> a feature an international standard.

==

Nits/editorial comments:

Abstract

   This document defines the subset of the Babel routing protocol and
   its extensions that a Homenet router must implement, as well as the
   interactions between HNCP and Babel.

SB> HNCP needs to be expanded
SB> Both need a reference, but the reference needs to be expanded
SB> i.e. RFC7788 not [RFC7788]

=

   The core of the Homenet protocol suite consists of HNCP [RFC7788], a
SB> HNCP needs to be expanded on first use

=


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Genart last call review of draft-ietf-rtgwg-backoff-algo-07

[Elwyn Davies]

Hi.
Thanks for the quick response.
I think the message I just sent to Acee covers most of this.  I'll await the 
final text on HOLDDOWN_INTERVAL etc.
I would just say that making it even clearer that the example values for timer 
intervals are not defaults.. implementers may understand the language but they 
can be lazy.
Cheers,Elwyn


Sent from Samsung tablet.
 Original message From: bruno.decra...@orange.com Date: 
16/02/2018  14:00  (GMT+00:00) To: "Acee Lindem (acee)" , Elwyn 
Davies  Cc: draft-ietf-rtgwg-backoff-algo@ietf.org, 
i...@ietf.org, rt...@ietf.org, gen-art@ietf.org Subject: RE: Genart last call 
review of draft-ietf-rtgwg-backoff-algo-07 
Hi Elwyn, Acee,

Thanks for your review and comments.
Please see inline [Bruno]

 > -Original Message-
 > From: Acee Lindem (acee) [mailto:a...@cisco.com]
 > Sent: Friday, February 16, 2018 1:31 AM
 > To: Elwyn Davies; gen-art@ietf.org
 > Cc: draft-ietf-rtgwg-backoff-algo@ietf.org; i...@ietf.org; rt...@ietf.org
 > Subject: Re: Genart last call review of draft-ietf-rtgwg-backoff-algo-07
 > 
 > Hi Elwyn,
 > 
 > On 2/15/18, 2:12 PM, "Elwyn Davies"  wrote:
 > 
 > Reviewer: Elwyn Davies
 > Review result: Ready with Nits
 > 
 > I am the assigned Gen-ART reviewer for this draft. The General Area
 > Review Team (Gen-ART) reviews all IETF documents being processed
 > by the IESG for the IETF Chair.  Please treat these comments just
 > like any other last call comments.
 > 
 > For more information, please see the FAQ at
 > 
 > .
 > 
 > Document: draft-ietf-rtgwg-backoff-algo-07.txt
 > Reviewer: Elwyn Davies
 > Review Date: 2018/02/15
 > IETF LC End Date: 2018/02/14
 > IESG Telechat date: 2016/02/22
 > 
 > Summary: Ready with nits. The draft does not refer to OSPFv3 - i am not 
 >sure if
 > this is an oversight or because ODSPFv3 already has this mechanism - 
 >either way
 > it should be mentioned.

[Bruno] This is an oversight and has been added.

 >   One question that occurred to me is whether the draft
 > could be considered as updating the OSPFv2/v3 and ISIS standards (not 
 >that IETF
 > has any control over ISIS).
 
[Bruno] I personally don't think so. I'd leave this to OSPF/IS-IS/LSR chairs 
and routing AD.
 
 > Major issues:
 > None
 > 
 > Minor issues:
 > (Non-)Relation between HOLDDOWN_INTERVAL and *_SPF_DELAY values:  I 
 >notced that
 > Benjamin Kaduk's SECDIR review of this document
 > 
 >(https://datatracker.ietf.org/doc/review-ietf-rtgwg-backoff-algo-07-secdir-lc-kaduk-2018-02-14/)
 > was concerned that certain state transitions would never occur.  I 
 >loooked at
 > this and realized that his assumption that LONG_SPF_DELAY < 
 >HOLDDOWN_INTERVAL
 > is not required by the document and s6 explicitly resiles from offering
 > suggested default values.  Without this assumption, the state machine 
 >appears
 > to be correct. Not being familiar with the consequences of setting the
 > HOLDDOWN_INTERVAL relative to the *_SPF_DELAY, I am not sure if anything 
 >could
 > be said about such consequences, 

[Bruno] There is no "significant" bad consequence.
Thinking about this, I could see 2 consequences:
- There could be a SPF computation scheduled after the HOLDDOWN_INTERVAL. I 
don't see this as an issue as, as stated below by Acee, the HOLDDOWN_INTERVAL 
is defined as related to the period with no IGP events. It's not defined as the 
period with no SPF computations (not to mention further computations e.g., from 
BGP).
- Perhaps more  importantly, if an IGP event occurs at t1 in the interval 
[LONG_SPF_DELAY;HOLDDOWN_INTERVAL], then the SPF computation would be triggered 
HOLDDOWN_INTERVAL-t1 after the IGP event. While the intuition is that it should 
be triggered after INITIAL_SPF_DELAY.


 > but I think it would avoid other people making
 > the same assumption as the SECDIR reviewer if it was explicitly stated 
 >that
 > HOLDDOWN_INTERVAL is not necessarily bigger than any of the *_SPF_DELAY 
 >values
 > and adding any advice from experience about how to choose appropriate 
 >values.
 > This might also avoid naive implementers shortcutting the state machine
 > implementation if they made the same assumption.

[Bruno] ok, I would propose the following change:

OLD:  In order to satisfy the goals stated in Section 2, operators are 
RECOMMENDED to configure delay intervals such that INITIAL_SPF_DELAY = 
SHORT_SPF_DELAY and SHORT_SPF_DELAY = LONG_SPF_DELAY.
NEW: In order to satisfy the goals stated in Section 2, operators are 
RECOMMENDED to configure delay intervals such that INITIAL_SPF_DELAY = 
SHORT_SPF_DELAY, SHORT_SPF_DELAY = LONG_SPF_DELAY and HOLDDOWN_TIMER 
greater than INITIAL_SPF_DELAY, SHORT_SPF_DELAY, LONG_SPF_DELAY.
 

 
 > The definition of HOLDDOWN_INTERVAL 

Re: [Gen-art] Genart last call review of draft-ietf-rtgwg-backoff-algo-07

[Elwyn Davies]

Hi.
Thanks forthe quick response.
Some coments in line below (EBD==>).
Cheers,Elwyn


Sent from Samsung tablet.
 Original message From: "Acee Lindem (acee)"  
Date: 16/02/2018  00:30  (GMT+00:00) To: Elwyn Davies , 
gen-art@ietf.org Cc: draft-ietf-rtgwg-backoff-algo@ietf.org, i...@ietf.org, 
rt...@ietf.org Subject: Re: Genart last call review of 
draft-ietf-rtgwg-backoff-algo-07 
Hi Elwyn, 

On 2/15/18, 2:12 PM, "Elwyn Davies"  wrote:

    Reviewer: Elwyn Davies
    Review result: Ready with Nits
    
    I am the assigned Gen-ART reviewer for this draft. The General Area
    Review Team (Gen-ART) reviews all IETF documents being processed
    by the IESG for the IETF Chair.  Please treat these comments just
    like any other last call comments.
    
    For more information, please see the FAQ at
    
    .
    
    Document: draft-ietf-rtgwg-backoff-algo-07.txt
    Reviewer: Elwyn Davies
    Review Date: 2018/02/15
    IETF LC End Date: 2018/02/14
    IESG Telechat date: 2016/02/22
    
    Summary: Ready with nits. The draft does not refer to OSPFv3 - i am not 
sure if
    this is an oversight or because ODSPFv3 already has this mechanism - either 
way
    it should be mentioned.  One question that occurred to me is whether the 
draft
    could be considered as updating the OSPFv2/v3 and ISIS standards (not that 
IETF
    has any control over ISIS).
    
    Major issues:
    None
    
    Minor issues:
    (Non-)Relation between HOLDDOWN_INTERVAL and *_SPF_DELAY values:  I notced 
that
    Benjamin Kaduk's SECDIR review of this document
    
(https://datatracker.ietf.org/doc/review-ietf-rtgwg-backoff-algo-07-secdir-lc-kaduk-2018-02-14/)
    was concerned that certain state transitions would never occur.  I loooked 
at
    this and realized that his assumption that LONG_SPF_DELAY < 
HOLDDOWN_INTERVAL
    is not required by the document and s6 explicitly resiles from offering
    suggested default values.  Without this assumption, the state machine 
appears
    to be correct. Not being familiar with the consequences of setting the
    HOLDDOWN_INTERVAL relative to the *_SPF_DELAY, I am not sure if anything 
could
    be said about such consequences, but I think it would avoid other people 
making
    the same assumption as the SECDIR reviewer if it was explicitly stated that
    HOLDDOWN_INTERVAL is not necessarily bigger than any of the *_SPF_DELAY 
values
    and adding any advice from experience about how to choose appropriate 
values. 
    This might also avoid naive implementers shortcutting the state machine
    implementation if they made the same assumption.

The definition of HOLDDOWN_INTERVAL explicitly states: 

HOLDDOWN_INTERVAL: The time required with no received IGP events
   before considering the IGP to be stable again and allowing the
   SPF_DELAY to be restored to INITIAL_SPF_DELAY. e.g., 3 seconds.  The
   HOLDDOWN_INTERVAL MUST be defaulted or configured to be longer than
   the TIME_TO_LEARN_INTERVAL.

Perhaps, it should be restated in the third paragraph of section 6. 
EBD==>  The definition of HOLDDOWN_INTERVAL is fine. The issue is the 
relationship (or otherwise) between *_SPF_DELAY and HOLDDOWN_INTERVAL.  It is 
(presumably) deliberately not specified:  However it would be helpful to make 
this explicit and say something about whether there are any downsides to 
setting the HOLDDOWN_INTERVAL smaller or larger than the delays.    
    Requirements Language: Suggest s/RFC2119/RFC8174/ as there are uses of lower
    case versions of the reserved words.

I believe this was brought up before and we will make this change. If not, 
we'll change to the RFC 8174 language. 
    
    Default values for parameters:  There is a possible conflict between s3, 
where
    example values for the various interval parameters are given and s6 which
    states that no default values are specified in the document.  The 
difference in
    termnology maybe too subtle for some implementers.

I would expect those implementing IGPs to know the different between an 
"example" and a "default". 
    
    Aborting or otherwise of SPF calculation if an IGP event occurs while an SPF
    calculation is in progress.  A note about whether this should happen (if it 
is
    possible) would be desirable.

This is certainly out scope and I'm not sure why anyone would deduce from this 
draft that an implementation should or shouldn't do this. 
EBD==> I can't see that it is out of scope.  The whole point of the draft is to 
avoid wasting processor cycles on useless runs of the SPF algorithm.  If an IGP 
event occurs just after the SPF algorithm has started there might be some point 
to aborting it or at least avoiding loading the routing tables.  Along the 
lines of 'Consideration could be given ..."   

    
    OSPFv3: Does this (not) equally apply to OSPF v3 for IPv6?  If so it should 
be

Re: [Gen-art] Genart last call review of draft-ietf-rtgwg-backoff-algo-07

[Elwyn Davies]

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)"  
Date: 16/02/2018  18:39  (GMT+00:00) To: Elwyn Davies , 
gen-art@ietf.org Cc: draft-ietf-rtgwg-backoff-algo@ietf.org, i...@ietf.org, 
rt...@ietf.org 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"  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: