A Framework for Loop-Free Convergence
RFC 5715

Received changes through RFC Editor sync (changed abstract to 'A micro-loop is a packet forwarding loop that may occur transiently among two or more routers in a hop-by-hop packet forwarding paradigm.

This framework provides a summary of the causes and consequences of micro-loops and enables the reader to form a judgement on whether micro-looping is an issue that needs to be addressed in specific networks. It also provides a survey of the currently proposed mechanisms that may be used to prevent or to suppress the formation of micro-loops when an IP or MPLS network undergoes topology change due to failure, repair, or management action. When sufficiently fast convergence is not available and the topology is susceptible to micro-loops, use of one or more of these mechanisms may be desirable. This document is not an Internet Standards Track specification; it is published for informational purposes.')

[Ballot comment]
Section 3 has

  Throughout this document we use the term SRLG to describe
  the procedure to be followed when multiple failures have occurred
  whether or not they are members of an explicit SRLG.

s/to describe/when describing/

---

Echo the point on the the ToS byte.
Suggest to completely remove the sentence.

---

I think it is unfortunate that section 12 is so skinny. I presume that
if I am able to induce micro loops (perhaps by flapping a resource) I
could cause considerable network disruption and so using loop prevention
or mitigation is a protection.

[Ballot comment]
Very nice document overall!

Section 6.5., paragraph 5:
>    This
>    could, for example, be achieved by allocating a Type of Service bit
>    to the task[RFC0791].  This mechanism works identically for both
>    "bad-news" and "good-news" events.  It also works identically for
>    SRLG failure.  There are three problems with this solution:

  There is no "ToS byte" anymore since DiffServ was published. Using a
  DSCP for that purpose is also not really in tune with the DiffServ
  architecture. Suggest to remove this example or point out in the list
  following this paragraph that that's also a drawback.

PROTO writeup by John Scudder:

draft-ietf-rtgwg-lf-conv-frmwk

    (1.a) Who is the Document Shepherd for this document? Has the
          Document Shepherd personally reviewed this version of the
          document and, in particular, does he or she believe this
          version is ready for forwarding to the IESG for publication?

John Scudder.  Yes.

    (1.b) Has the document had adequate review both from key WG members
          and from key non-WG members? Does the Document Shepherd have
          any concerns about the depth or breadth of the reviews that
          have been performed?

The document has been published for some time and has received substantive comments which indicates to me that at least some WG members have read it carefully.

    (1.c) Does the Document Shepherd have concerns that the document
          needs more review from a particular or broader perspective,
          e.g., security, operational complexity, someone familiar with
          AAA, internationalization or XML?

No.

    (1.d) Does the Document Shepherd have any specific concerns or
          issues 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. Has an IPR disclosure related to this document
          been filed? If so, please include a reference to the
          disclosure and summarize the WG discussion and conclusion on
          this issue.

I generally take a somewhat skeptical view of framework documents but this one seems worthwhile and I think it should be published.

    (1.e) 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?

I would describe the consensus as "silence gives assent".  Since this is a framework and a very mature one at that, it's somewhat difficult to generate enthusiasm.

    (1.f) Has anyone threatened an appeal or otherwise indicated extreme
          discontent? If so, please summarise the areas of conflict in
          separate email messages to the Responsible Area Director. (It
          should be in a separate email because this questionnaire is
          entered into the ID Tracker.) No.

    (1.g) Has the Document Shepherd personally verified that the
          document satisfies all ID nits? (See
          http://www.ietf.org/ID-Checklist.html and
          http://tools.ietf.org/tools/idnits/). Boilerplate checks are
          not enough; this check needs to be thorough. Has the document
          met all formal review criteria it needs to, such as the MIB
          Doctor, media type and URI type reviews?

IDNits throws a warnings for pre-RFC5378.  I don't think there's a problem and have verified with the authors that they don't either.

IDNits throws an outdated reference warning, but the warning is erroneous.  (I double-checked; the latest version of draft-ietf-rtgwg-ordered-fib is -02.)

    (1.h) Has the document split its references into normative and
          informative? 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
          strategy for their completion? Are there normative references
          that are downward references, as described in [RFC3967]? If
          so, list these downward references to support the Area
          Director in the Last Call procedure for them [RFC3967].

Refs are fine.

    (1.i) Has the Document Shepherd verified that the document IANA
          consideration section exists and is consistent with the body
          of the document? If the document specifies protocol
          extensions, are reservations requested in appropriate IANA
          registries? Are the IANA registries clearly identified? If
          the document creates a new registry, does it define the
          proposed initial contents of the registry and an allocation
          procedure for future registrations? Does it suggest a
          reasonable name for the new registry? See [RFC5226]. If the
          document describes an Expert Review process has Shepherd
          conferred with the Responsible Area Director so that the IESG
          can appoint the needed Expert during the IESG Evaluation?

This is fine too.

    (1.j) Has the Document Shepherd verified that sections of the
          document that are written in a formal language, such as XML
          code, BNF rules, MIB definitions, etc., validate correctly in
          an automated checker?

N/A.

    (1.k) 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
              Relevant content can frequently be found in the abstract
              and/or introduction of the document. If not, this may be
              an indication that there are deficiencies in the abstract
              or introduction.
          Working Group Summary
              Was there anything in WG process that is worth noting? For
              example, was there controversy about particular points or
              were there decisions where the consensus was particularly
              rough?
          Document Quality
              Are there existing implementations of the protocol? Have a
              significant number of vendors indicated their plan to
              implement the specification? Are there any reviewers that
              merit special mention as having done a thorough review,
              e.g., one that resulted in important changes or a
              conclusion that the document had no substantive issues? If
              there was a MIB Doctor, Media Type or other expert review,
              what was its course (briefly)? In the case of a Media Type
              review, on what date was the request posted?

Technical Summary
    This draft describes mechanisms that may be used to prevent or to
    suppress the formation of micro-loops when an IP or MPLS network
    undergoes topology change due to failure, repair or management
    action.

Working Group Summary
    This document has been evolving since 2006 and reflects a good
    summary of the approaches explored by the WG.  The document is
    non-controversial.

Document Quality
    The document is a framework intended as an Informational RFC and
    does not specify a protocol.  It has received reasonable review from
    WG members.