Skip to main content

Shortest Path First (SPF) Back-Off Delay Algorithm for Link-State IGPs
draft-ietf-rtgwg-backoff-algo-10

Revision differences

Document history

Date Rev. By Action
2018-06-25
10 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2018-06-05
10 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2018-05-30
10 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2018-03-22
10 (System) IANA Action state changed to No IC
2018-03-21
10 (System) RFC Editor state changed to EDIT
2018-03-21
10 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2018-03-21
10 (System) Announcement was received by RFC Editor
2018-03-21
10 Cindy Morgan IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2018-03-21
10 Cindy Morgan IESG has approved the document
2018-03-21
10 Cindy Morgan Closed "Approve" ballot
2018-03-21
10 Cindy Morgan Ballot approval text was generated
2018-03-21
10 Alia Atlas IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2018-03-19
10 Alvaro Retana [Ballot Position Update] Position for Alvaro Retana has been changed to No Objection from Discuss
2018-03-19
10 Bruno Decraene New version available: draft-ietf-rtgwg-backoff-algo-10.txt
2018-03-19
10 (System) New version approved
2018-03-19
10 (System) Request for posting confirmation emailed to previous authors: Pierre Francois , Bruno Decraene , Acee Lindem , Hannes Gredler , Chris Bowers , Stephane Litkowski
2018-03-19
10 Bruno Decraene Uploaded new revision
2018-03-13
09 Deborah Brungard [Ballot comment]
Thanks for addressing my comments.
2018-03-13
09 Deborah Brungard [Ballot Position Update] Position for Deborah Brungard has been changed to No Objection from Discuss
2018-02-28
09 Bruno Decraene New version available: draft-ietf-rtgwg-backoff-algo-09.txt
2018-02-28
09 (System) New version approved
2018-02-28
09 (System) Request for posting confirmation emailed to previous authors: Pierre Francois , Bruno Decraene , Acee Lindem , Hannes Gredler , Chris Bowers , Stephane Litkowski
2018-02-28
09 Bruno Decraene Uploaded new revision
2018-02-27
08 (System) Sub state has been changed to AD Followup from Revised ID Needed
2018-02-27
08 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2018-02-27
08 Bruno Decraene New version available: draft-ietf-rtgwg-backoff-algo-08.txt
2018-02-27
08 (System) New version approved
2018-02-27
08 (System) Request for posting confirmation emailed to previous authors: Pierre Francois , Bruno Decraene , Acee Lindem , Hannes Gredler , Chris Bowers , Stephane Litkowski
2018-02-27
08 Bruno Decraene Uploaded new revision
2018-02-22
07 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2018-02-22
07 Mehmet Ersue Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Mehmet Ersue.
2018-02-21
07 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2018-02-21
07 Suresh Krishnan [Ballot comment]
Agree with Alvaro's DISCUSS regarding specifying reasonable defaults.
2018-02-21
07 Suresh Krishnan [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan
2018-02-21
07 Adam Roach
[Ballot comment]
Six authors seems excessive for a 13-page document. See RFC 7322 §4.1.1 for
guidance. If justified, I would expect to see a request …
[Ballot comment]
Six authors seems excessive for a 13-page document. See RFC 7322 §4.1.1 for
guidance. If justified, I would expect to see a request for an exception to
the five-author rule in the ballot, or at least in the shepherd's write-up.

I support Deborah's DISCUSS.

I find a minor editorial nit in §7:

>  In general, the SPF delay algorithm is only effective in mitigating
>  micro-loops if it is deployed, with the same parameters, on all
>  routers, in the IGP domain or, at least, all routers in an IGP area/

"...on all routers in the IGP domain..." (remove comma)
2018-02-21
07 Adam Roach [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach
2018-02-21
07 Ben Campbell [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell
2018-02-21
07 Terry Manderson [Ballot comment]
I think Alvaro and Deborah have covered the situation well.
2018-02-21
07 Terry Manderson [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson
2018-02-21
07 Benoît Claise [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise
2018-02-21
07 Warren Kumari [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari
2018-02-21
07 Spencer Dawkins
[Ballot comment]
I really like that you've produced this document. It was clear to someone with a minimal routing background. Thanks for that, too.

I …
[Ballot comment]
I really like that you've produced this document. It was clear to someone with a minimal routing background. Thanks for that, too.

I would support either Alvaro's Discuss or Deborah's Discuss, and maybe both.

- I think the document would still be useful if it was Informational, as an example of the kind of thing that could be done.

- If you really want stuff in the same network, or the same level/area, to use the same timers, putting safe-ish default values in the document would be more likely to make that happen.

I did notice one piece of text that wasn't clear to me. I found this confusing -

  In general, when the network is stable, there is a desire to compute
  a new Shortest Path First (SPF) as soon as a failure is detected in
  order to quickly route around the failure.  However, when the network
  is experiencing multiple temporally close failures over a short
  period of time, there is a conflicting desire to limit the frequency
  of SPF computations.  Indeed, this allows a reduction in control
  plane resources used by IGPs and all protocols/subsystems reacting on
  the attendant route change, such as ...

"this allows" seemed as likely to refer to the desire to limit, as anything else. Perhaps

  ... limit the frequency
  of SPF computations, which would allow a reduction in control
  plane resources used by IGPs and all protocols/subsystems reacting on
  the attendant route change, such as ...

might be clearer.
2018-02-21
07 Spencer Dawkins [Ballot Position Update] New position, Yes, has been recorded for Spencer Dawkins
2018-02-21
07 Kathleen Moriarty
[Ballot comment]
Thanks for addressing Ben's SecDir review.  It appears that the changes are queued up and it would be appreciated to ensure they are …
[Ballot comment]
Thanks for addressing Ben's SecDir review.  It appears that the changes are queued up and it would be appreciated to ensure they are in the approved version.
https://mailarchive.ietf.org/arch/msg/secdir/x9QCq2kZTmcP0_ZFeZrv_rs5Mmw
2018-02-21
07 Kathleen Moriarty [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty
2018-02-20
07 Eric Rescorla [Ballot comment]
I see other people have noted Ben's secdir review. That deserves addressing.
2018-02-20
07 Eric Rescorla [Ballot Position Update] New position, No Objection, has been recorded for Eric Rescorla
2018-02-20
07 Deborah Brungard
[Ballot discuss]
While I agree with Alvaro's concerns, my concern is the appropriateness of this document as PS.
This document should have a similar status …
[Ballot discuss]
While I agree with Alvaro's concerns, my concern is the appropriateness of this document as PS.
This document should have a similar status as RFC6976 (Informational) which also provided a
mechanism that prevented transient loops saying "the mechanisms described in this
document are purely illustrative of the general approach and do not constitute a protocol
specification". Especially as this document compares itself to RFC6976, saying RFC6976 is a
"full solution".

With a change of status to Informational, this document would be better
scoped as providing guidance vs. a specification.
2018-02-20
07 Deborah Brungard [Ballot Position Update] New position, Discuss, has been recorded for Deborah Brungard
2018-02-19
07 Alvaro Retana
[Ballot discuss]
I am balloting DISCUSS because I believe that this document presents an incomplete and vague description of a specification, which (as is) won't …
[Ballot discuss]
I am balloting DISCUSS because I believe that this document presents an incomplete and vague description of a specification, which (as is) won't result in consistent implementations.  Consistency, through the specification of a standard algorithm is used as the basis to justify this work:  "To allow multi-vendor networks to have all routers delay their SPF computations for the same duration, this document specifies a standard algorithm." 

I am specifically and specially concerned about the fact that there are no defaults or even suggested values:

  This document does not propose default values for the parameters because
  these values are expected to be context dependent. Implementations are free
  to propose their own default values.

If the whole purpose of standardizing an algorithm is for different implementation to behave the same way and (specifically) "to have all routers delay their SPF computations for the same duration", then not defining defaults (and not being clear in the recommendations -- more on this below) makes the specification incomplete and vague!

Section 6 tries to provide guidelines about defaults, but it falls short!

  In order to satisfy the goals stated in Section 2, operators are
  RECOMMENDED to configure delay intervals such that SPF_INITIAL_DELAY
  <= SPF_SHORT_DELAY and SPF_SHORT_DELAY <= SPF_LONG_DELAY.

Why are the operators not REQUIRED to meet that relationship?  Are there cases when it is ok not to follow those guidelines?  Would (for example) the SPF_LONG_DELAY ever be less than SPF_INITIAL_DELAY?

The other Normative Language in this section can't really be enforced, and provide (at best) very weak guidance. 

  When setting (default) values, one SHOULD consider the customers and
  their application requirements, the computational power of the
  routers, the size of the network, and, in particular, the number of
  IP prefixes advertised in the IGP, the frequency and number of IGP
  events, the number of protocols reactions/computations triggered by
  IGP SPF (e.g., BGP, PCEP, Traffic Engineering CSPF, Fast ReRoute
  computations).

"SHOULD consider..."  How can this statement be Normatively enforced?  Using "SHOULD" implies that it is ok to only partially consider the list you provided, or even a different set of criteria. 

Based on the suggestions above, I can't imagine how a vendor can set default values (even if "free to propose their own")...or how the average network operator could configure anything beyond the numbers that you mentioned as examples in the text.  For example, the average network operator might ask: under the same circumstances, should my bigger routers (ones with presumably more computational power) have lower or higher delays with respect to my smaller routers?  ...

  Note that some or all of these factors may change over the life of
  the network.  In case of doubt, it's RECOMMENDED to play it safe and
  start with safe, i.e., longer timers.

How can "playing it safe" be Normatively enforced?

  For the standard algorithm to be effective in mitigating micro-loops,
  it is RECOMMENDED that all routers in the IGP domain, or at least all
  the routers in the same area/level, have exactly the same configured
  values.

[A similar statement is made in Section 7.]

If it is so important, why is consistency not mandatory?  IOW, why is it only "RECOMMENDED" and not "REQUIRED"?  When is it ok to not do it?

Back to the point of this DISCUSS, the importance of consistent values is clear!  Based on the experience of existing implementations, please specify "safe" default values.
2018-02-19
07 Alvaro Retana
[Ballot comment]
[I know that some of these comments have been brought up in the SecDir and GenArt reviews, but I have not seen an …
[Ballot comment]
[I know that some of these comments have been brought up in the SecDir and GenArt reviews, but I have not seen an update yet.]

(1) Besides the lack of guidance (see above), there are several other inconsistencies throughout the document:

(1.1) Section 3: "The HOLDDOWN_INTERVAL MUST be defaulted or configured to be longer than the TIME_TO_LEARN_INTERVAL."  Which one, defaulted OR configured?  Is it ok for the implementation to provide a default value that doesn't comply with the expectation that the operator will configure the correct value?  It seems to me that the definition of MUST doesn't fit with an option. 

(1.2) Section 4: "If subsequent IGP events are received in a short period of time (TIME_TO_LEARN_INTERVAL)...In this situation, we delay the routing computation by SHORT_SPF_DELAY."  Note that Section 3 provided example values for TIME_TO_LEARN_INTERVAL and SHORT_SPF_DELAY as 1 sec and 50-100 ms, respectively.  If IGP events are received within the TIME_TO_LEARN_INTERVAL window, then the SPF_DELAY ("delay between the first IGP event...and the start of that routing table computation") set to SHORT_SPF_DELAY will be triggered before TIME_TO_LEARN_INTERVAL...which means that the SPF run after SHORT_SPF_DELAY won't cover all the changes.  Is that what you meant, or are you assuming that the SPF_DELAY will start *after* the TIME_TO_LEARN_INTERVAL?

(1.3) Section 5.1: "LONG_WAIT: State reached after TIME_TO_LEARN_INTERVAL.  In other words, state reached after TIME_TO_LEARN_INTERVAL in state SHORT_WAIT."  But Section 3 defines TIME_TO_LEARN_INTERVAL as "the maximum duration typically needed to learn all the IGP events related to a single component failure" -- why don't the events from that single failure start while in QUIET state?  OR are you saying (in 5.1) that the TIME_TO_LEARN_INTERVAL is not measured from the initial IGP Event?

(1.4) What is the relationship between HOLDDOWN_INTERVAL and the *_SPF_DELAY?  I would assume that *_SPF_DELAY is always less than HOLDDOWN_INTERVAL, but the document doesn't specify that relationship anywhere.

(1.5) Section 6: "All the parameters MUST be configurable [I-D.ietf-isis-yang-isis-cfg] [I-D.ietf-ospf-yang] at the protocol instance granularity."  Given that the references to the YANG models are listed as Informative, what does that statement mean?  Is it a directive to what must be included in the models?  What about implementations that don't use YANG (yet)?

(2) Section 5.4 (FSM Events)

(2.1) When will "Transition 7: SPF_TIMER expiration, while in QUIET" happen?  Because when an IGP Event occurs in QUIET state, the FSM moves to SHORT_WAIT, the SPF_TIMER should never expire in QUIET state.

(2.2) "Transition 3: LEARN_TIMER expiration." is defined between SHORT_WAIT and LONG_WAIT, which (at first glance) seems to match how 5.1 defines "LONG_WAIT:...state reached after TIME_TO_LEARN_INTERVAL in state SHORT_WAIT."  However, the LEARN_TIMER in only started when an IGP event happens in QUIET_STATE (transition 1).

(2.3) For completeness, the HOLDDOWN_TIMER expiration events (5 and 6) should include resetting all the timers, just in case...and to be consistent with the initialization description.


(3) From Section 3: "Routing table computation: Computation of the routing table..."  This is a circular definition [1].  I'm sure the authors can figure out a clear way to explain the meaning without using the terms being defined...

(4) "Note that previously implemented SPF delay algorithms counted the number of SPF computations."  References?  Knowing that the references may not be stable (pointing to a vendor's website), you might want to simply remove this sentence and simply make the point in the paragraph as to why a time interval is used.  Note that the point of this document is not to compare the specification to "previously implemented algorithms".

(5) I am surprised that no other documents "must be read to understand or implement the technology" [2] resulting in no Normative References (beyond rfc2119).  I would think that at least the OSPF and ISIS specs should be Normative.

(6) For the rtgwg-chairs/Shepherd: A quick scan of the mail archive shows that this document wasn't reviewed by the ospf/isis WGs.  Given that what is specified here affects the protocols directly, I would think that formal review is needed.  [I note that a couple of the Chairs of the ospf/isis WGs are co-authors of this document, and that a note was indeed sent when the -00 version of the individual draft was published -- still, it would have been nice to at least explicitly inform of the progress.]

(7) Nit: "(e.g.  Loop Free Alternates..."  The closing parenthesis is missing.

(8) Nit: Please put a forward reference to 5.1 when the QUIET state is mentioned in Section 4.

(9) Nit: s/QUIET_STATE/QUIET state.



[1] https://en.wikipedia.org/wiki/Circular_definition 
[2] https://www.ietf.org/iesg/statement/normative-informative.html
2018-02-19
07 Alvaro Retana [Ballot Position Update] New position, Discuss, has been recorded for Alvaro Retana
2018-02-19
07 Alvaro Retana This document now replaces draft-decraene-rtgwg-backoff-algo instead of None
2018-02-19
07 Mirja Kühlewind
[Ballot comment]
1) Probably an editorial issue: "... SPF_DELAY to be restored to INITIAL_SPF_DELAY. e.g., 3 seconds."
3 seconds? The previous text says INITIAL_SPF_DELAY should …
[Ballot comment]
1) Probably an editorial issue: "... SPF_DELAY to be restored to INITIAL_SPF_DELAY. e.g., 3 seconds."
3 seconds? The previous text says INITIAL_SPF_DELAY should be very short, e.g. 0 milliseconds...?

2) Also editorial: it would be helpful to show the state diagram right at the beginning.
2018-02-19
07 Mirja Kühlewind [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind
2018-02-19
07 Alia Atlas IESG state changed to IESG Evaluation from Waiting for Writeup
2018-02-19
07 Alia Atlas Ballot has been issued
2018-02-19
07 Alia Atlas [Ballot Position Update] New position, Yes, has been recorded for Alia Atlas
2018-02-19
07 Alia Atlas Created "Approve" ballot
2018-02-19
07 Alia Atlas Ballot writeup was changed
2018-02-15
07 Elwyn Davies Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Elwyn Davies. Sent review to list.
2018-02-14
07 Benjamin Kaduk Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Benjamin Kaduk.
2018-02-14
07 (System) IESG state changed to Waiting for Writeup from In Last Call
2018-02-05
07 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed
2018-02-05
07 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has reviewed draft-ietf-rtgwg-backoff-algo-07, which is currently in Last Call, and has the following comments:

We …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has reviewed draft-ietf-rtgwg-backoff-algo-07, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist
2018-02-05
07 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Mehmet Ersue
2018-02-05
07 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Mehmet Ersue
2018-02-01
07 Jean Mahoney Request for Last Call review by GENART is assigned to Elwyn Davies
2018-02-01
07 Jean Mahoney Request for Last Call review by GENART is assigned to Elwyn Davies
2018-01-31
07 Tero Kivinen Request for Last Call review by SECDIR is assigned to Benjamin Kaduk
2018-01-31
07 Tero Kivinen Request for Last Call review by SECDIR is assigned to Benjamin Kaduk
2018-01-31
07 Alia Atlas Telechat date has been changed to 2018-02-22 from 2018-02-08
2018-01-31
07 Cindy Morgan IANA Review state changed to IANA - Review Needed
2018-01-31
07 Cindy Morgan
The following Last Call announcement was sent out (ends 2018-02-14):

From: The IESG
To: IETF-Announce
CC: draft-ietf-rtgwg-backoff-algo@ietf.org, rtgwg-chairs@ietf.org, Uma Chunduri , uma.chunduri@huawei.com, …
The following Last Call announcement was sent out (ends 2018-02-14):

From: The IESG
To: IETF-Announce
CC: draft-ietf-rtgwg-backoff-algo@ietf.org, rtgwg-chairs@ietf.org, Uma Chunduri , uma.chunduri@huawei.com, akatlas@gmail.com, rtgwg@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (SPF Back-off algorithm for link state IGPs) to Proposed Standard


The IESG has received a request from the Routing Area Working Group WG
(rtgwg) to consider the following document: - 'SPF Back-off algorithm for
link state IGPs'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-02-14. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This document defines a standard algorithm to back-off link-state IGP
  Shortest Path First (SPF) computations.

  Having one standard algorithm improves interoperability by reducing
  the probability and/or duration of transient forwarding loops during
  the IGP convergence when the IGP reacts to multiple temporally close
  IGP events.





The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-backoff-algo/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-backoff-algo/ballot/


No IPR declarations have been submitted directly on this I-D.




2018-01-31
07 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2018-01-31
07 Alia Atlas Placed on agenda for telechat - 2018-02-08
2018-01-31
07 Alia Atlas Last call was requested
2018-01-31
07 Alia Atlas Last call announcement was generated
2018-01-31
07 Alia Atlas Ballot approval text was generated
2018-01-31
07 Alia Atlas Ballot writeup was generated
2018-01-31
07 Alia Atlas IESG state changed to Last Call Requested from AD Evaluation
2018-01-30
07 Alia Atlas IESG state changed to AD Evaluation from Publication Requested
2018-01-23
07 Jeff Tantsura
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)?  Why is this the proper type of RFC?  …
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)?  Why is this the proper type of RFC?  Is this type of RFC indicated in the title page header?

The Intended Status is 'Proposed Standard'. 
The type of RFC is properly indicated in the title page header.
This document describes the describes a standard SPF backoff algorithm with common configurable parameters to be implemented by all the nodes in a network to mitigates the microloops problem.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary
This document describes a route computation back-off algorithm (not SPF computation algorithm itself!) to most widely used IGPs (OSPF/ISIS). Because lack of standard algorithm in this area various implementations choose to implement different back-off procedures today and this is one of the main contributors to the micro-loops seen today during network re-convergence. This document also defines the key configurable parameters for the standard algorithm defined here, so that same set of values can be provisioned in all nodes in a particular deployment. Other sources of micro loops are hinted in section 8 with some references.

Working Group Summary
This draft has been thoroughly discussed in the WG.
The draft adoption and progress has received full support from the WG.

All major comments have been addressed.  The draft is ready for publication.
Version 07 addresses my comments.

Document Quality
The draft went through routing directorate review and comments were taken care.
Proposed algorithm  has been prototyped/implemented by 3 vendors-os/implementations

– JunOS prototype
– Quagga (Free Range Routing)
– RtBrick


Personnel
Uma Chunduri is the Document Shepherd.
Alia Atlas is the Responsible Area Director.

(3) Briefly describe the review of this document that was performed by the Document Shepherd.  If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The draft has been thoroughly reviewed by the Shepherd and all comments were addressed in published 07 version.


(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No concerns.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

N/A

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

  N/A

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why.

  Yes.  Every author has confirmed.

(8) Has an IPR disclosure been filed that references this document?

If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

Yes.  The authors have been asked (and they answered) on the WG list about IPR at every step of the process.  There haven't been any concerns raised on the list.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? 

The draft adoption and progress had received full support from the WG.
 
(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)
No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.
There are still some editorial comments that need to be addressed.
From idnits:
  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

    No issues found here.

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  -- The document date (October 22, 2017) is 47 days in the past.  Is this
    intentional?


  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

    (See RFCs 3967 and 4897 for information about using normative references
    to lower-maturity documents in RFCs)

  == Outdated reference: A later version (-19) exists of
    draft-ietf-isis-yang-isis-cfg-18

  == Outdated reference: A later version (-09) exists of
    draft-ietf-ospf-yang-08

  == Outdated reference: A later version (-05) exists of
    draft-ietf-rtgwg-spf-uloop-pb-statement-04


    Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--).

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

Parameters defined in this document should be configured from respective IGP yang model. This has been clearly described in Section 6 "Parameters" - of the document.
ietf-isis-yang-isis-cfg, ietf-ospf-yang informative refernces have been added to that effect. No need for such formal review.


(13) Have all references within this document been identified as either normative or informative?

Yes

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.
The state of other documents remains unchanged.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

N/A

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.
N/A

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.
N/A
2018-01-23
07 Jeff Tantsura Responsible AD changed to Alia Atlas
2018-01-23
07 Jeff Tantsura IETF WG state changed to Submitted to IESG for Publication from Waiting for WG Chair Go-Ahead
2018-01-23
07 Jeff Tantsura IESG state changed to Publication Requested
2018-01-23
07 Jeff Tantsura IESG process started in state Publication Requested
2018-01-23
07 Jeff Tantsura Tag Doc Shepherd Follow-up Underway cleared.
2018-01-23
07 Jeff Tantsura IETF WG state changed to Waiting for WG Chair Go-Ahead from In WG Last Call
2018-01-23
07 Jeff Tantsura Changed consensus to Yes from Unknown
2018-01-23
07 Jeff Tantsura Intended Status changed to Proposed Standard from None
2018-01-22
07 Uma Chunduri Changed document writeup
2018-01-17
07 Uma Chunduri Changed document writeup
2017-12-11
07 Bruno Decraene New version available: draft-ietf-rtgwg-backoff-algo-07.txt
2017-12-11
07 (System) New version approved
2017-12-11
07 (System) Request for posting confirmation emailed to previous authors: Pierre Francois , Bruno Decraene , Acee Lindem , Hannes Gredler , Chris Bowers , Stephane Litkowski
2017-12-11
07 Bruno Decraene Uploaded new revision
2017-12-08
06 Uma Chunduri Changed document writeup
2017-11-29
06 Jeff Tantsura IETF WG state changed to In WG Last Call from WG Document
2017-10-23
06 Bruno Decraene New version available: draft-ietf-rtgwg-backoff-algo-06.txt
2017-10-23
06 (System) New version approved
2017-10-23
06 (System) Request for posting confirmation emailed to previous authors: Pierre Francois , Bruno Decraene , Acee Lindem , Hannes Gredler , Chris Bowers , Stephane Litkowski
2017-10-23
06 Bruno Decraene Uploaded new revision
2017-10-16
05 Jeff Tantsura Tag Doc Shepherd Follow-up Underway set.
2017-09-28
05 Jeff Tantsura Notification list changed to Uma Chunduri <uma.chunduri@huawei.com>
2017-09-28
05 Jeff Tantsura Document shepherd changed to Uma Chunduri
2017-05-02
05 Bruno Decraene New version available: draft-ietf-rtgwg-backoff-algo-05.txt
2017-05-02
05 (System) New version approved
2017-05-02
05 (System) Request for posting confirmation emailed to previous authors: Pierre Francois , Bruno Decraene , Acee Lindem , Hannes Gredler , Chris Bowers , Stephane Litkowski
2017-05-02
05 Bruno Decraene Uploaded new revision
2017-04-27
04 Min Ye Request for Early review by RTGDIR Completed: Has Issues. Reviewer: Sasha Vainshtein.
2017-03-31
04 Jonathan Hardwick Request for Early review by RTGDIR is assigned to Sasha Vainshtein
2017-03-31
04 Jonathan Hardwick Request for Early review by RTGDIR is assigned to Sasha Vainshtein
2017-03-31
04 Jeff Tantsura Requested Early review by RTGDIR
2017-03-24
04 Jeff Tantsura Added to session: IETF-98: rtgwg  Thu-1520
2017-01-09
04 Bruno Decraene New version available: draft-ietf-rtgwg-backoff-algo-04.txt
2017-01-09
04 (System) New version approved
2017-01-09
04 (System)
Request for posting confirmation emailed to previous authors: rtgwg-chairs@ietf.org, "Hannes Gredler" , "Stephane Litkowski" , "Chris Bowers" , "Bruno Decraene" , "Acee Lindem" , …
Request for posting confirmation emailed to previous authors: rtgwg-chairs@ietf.org, "Hannes Gredler" , "Stephane Litkowski" , "Chris Bowers" , "Bruno Decraene" , "Acee Lindem" , "Pierre Francois"
2017-01-09
04 Bruno Decraene Uploaded new revision
2017-01-05
03 (System) Document has expired
2016-07-04
03 Bruno Decraene New version available: draft-ietf-rtgwg-backoff-algo-03.txt
2015-12-17
02 Bruno Decraene New version available: draft-ietf-rtgwg-backoff-algo-02.txt
2015-06-19
01 Bruno Decraene New version available: draft-ietf-rtgwg-backoff-algo-01.txt
2015-05-04
00 Bruno Decraene New version available: draft-ietf-rtgwg-backoff-algo-00.txt