Framework for Loop-Free Convergence Using the Ordered Forwarding Information Base (oFIB) Approach
draft-ietf-rtgwg-ordered-fib-12

Moving this document to revised I-D needed. I really don't see why the author's unresponsiveness should be counted in the statistics as the AD's poor performance.

[Ballot discuss]
I'd like to at least spend a few minutes during the telechat diving into Brian's comment in his ballot: Why are these being published as WG items? Was the WG working on something that they thought was going to end up as a standards track document but ended up with a lot of output and nothing they could standardize? Is that worth publishing? The writeup is exceedingly thin on this point. I'm not at all sure what the "subtleties involved" have to do with the desire to publish.

[Ballot comment]
-

the mechanism -> the mechanisms

-
  It is assumed in the description that follows that all routers in the
  routing domain are oFIB capable.  This can be verified in an
  operation network by the routers reporting oFIB capability using the
  IGP in use.  Where non-oFIB capable routers exist in the network,
  normal convergence would be used.

I guess you mean
  Where non-oFIB capable routers exist in the network,
  normal convergence would be used in all routers.

Otherwise, it contradicts the first sentence

[Ballot comment]
It seems interesting, but I'm confused why if it works so well in simulations, that nobody seems interested in going further with this.  What's the value of an IETF RFC versus other types of publication, given that there's IPR attached to this as an Informational document?  It's clearly informative, but I get the feeling that there's more information that must not be clear in the writing at the moment about what the ultimate goal is.

[Ballot discuss]
I have no objection to the publication of this document.
However, there are two issues (easy to fix)
1.

  This mechanism can be used in the case of non-urgent (management
  action) link or node shutdowns and restarts or link metric changes.

You added "management action" based on the OPS-DIR feedback.  Thanks.

Also you mentioned

3.1.1. Link Down / Metric Increase
  First consider the non-urgent failure of a link (i.e. where an
  operator or a network management system (NMS) shuts down a link
  thereby removing it from the currently active topology) or the
  increase of a link metric by the operator or NMS .

Also, later on:

  This mechanism may be applied to the case of
  managed link-state changes, i.e. link metric change, manual link
  down/up, manual router down/up, and managed state changes of a set of
  links attached to one router.

  ...
  The mechanisms that are used in
  the failure case are exactly the same as those used for managed
  changes.

This document is missing consistency in the terms used: non-urgent (management action) versus manual XXX, versus managed changes.
On top of the that, clarification is required: In this world of SDN/OpenFlow/Controllers/etc... (pick you prefer buzzword), would for example an I2RS change be considered management action (managed change) or not? It was not clear from reading the draft.
In other words, this draft misses either a definition and/or an applicability section (somewhere near the intro).
After some inquiries with one of the authors, I understand that this draft applies to all changes that are NOT dynamic routing changes. Maybe you want to clearly mention this instead of using a list of terms: non-urgent (management action), manual XXX, managed changes, etc...

- I would stress one key point in the management considerations section.
Based on the following text, which is somewhere in the draft:

    It is assumed in the description that follows that all routers in the routing domain are oFIB capable. This can be verified in an operation network by the routers reporting oFIB capability using the IGP in use. Where non-oFIB capable routers exist in the network, normal convergence would be used. The operation of mixed-mode networks is for further study.

I would add something around:
          For the mechanism in this document to work, all routers in the routing domain must be oFIB capable.
          Therefore a mechanism must be in place to advertise this router capability in the routing domain.

[Ballot comment]
- However the mechanism described
  in this document are purely illustrative of the general approach and
  do not constitute a protocol specification.

the mechanism -> the mechanisms

-
  It is assumed in the description that follows that all routers in the
  routing domain are oFIB capable.  This can be verified in an
  operation network by the routers reporting oFIB capability using the
  IGP in use.  Where non-oFIB capable routers exist in the network,
  normal convergence would be used.

I guess you mean
  Where non-oFIB capable routers exist in the network,
  normal convergence would be used in all routers.

Otherwise, it contradicts the first sentence

[Ballot discuss]
Dan Romascanu performed a review during IETF last call. All of his points need to be addressed.

1. The document uses in the abstract, and then a couple of times in the document the term non-urgent to characterize topology changes that would fall within the scope of the document. However what means a non-urgent topology change is not defined or referred anywhere, and in the absence of such a definition it is difficult to assess the applicability of the document, and also to discuss aspects related to scalability.

2. Although the document is targeting informational status an Operational and Manageability Considerations section would be very useful, at least at a similar level with the IANA Considerations and Security Considerations sections which are already part of the document. This would help the authors of further documents developped based on this one with a list of critical issues that need to be taken into considerations from an operational perspective. One is for example the need for all routers to support the mechanisms described here in order to be applicable - what are the deployment and transition aspects that network operators need to take into account? Another aspect is related to the performance impact - section 4.2 mentions that network reconvergence under ordered FIB takes longer that the normal reconvergence process, but if failure protection mechanisms are in place no packets are lost. What about delays, what is the potential impact of oFIB on applications? Not all answers need to be here, but a list of items to be described in the Operational Considerations sections in future documents could help.

3. The reference [refs.PFOB07] leads to the general catalog of the 'Transactions in Networking' and obliges the reader who wants to read the original paper to browse back several pages (and years) in order to retrieve the article. I suggest to provide the full and exact reference which is http://inl.info.ucl.ac.be/system/files/pfr-obo-ofib-ton.pdf.

4. I did not follow the logic of capitalization in the sentences like in 3.1.2, 3.2.2:

>  In the case of link up events or metric decreases, a router R must
  update its FIB BEFORE all other routers that WILL use R to reach the
  affected link.

If capitalizing BEFORE still makes some sense, the capitalizing of WILL is unclear to me.

5. In Section 3.2: '  The following sections describe the required ordering for single events which may be manifest as multiple link events.' s/may be manifest/may manifest/

6. some of the acronyms are not expanded at the first occurrence (FRR) or not expanded at all (ECMP)

7. The formulation in Section 7 is unclear:

> A number of possible fall back mechanisms are
  described in Appendix A.  This mechanism is referred to as
  "Abandoning All Hope (AAH).

What is 'This mechanism'? Appendix A describes a number of different mechanisms in which reverting to fast convergence is needed and AAH seems to apply to all, so it's actually not the name of one mechanism but of a category that comprises several mechanisms.

IANA has reviewed draft-ietf-rtgwg-ordered-fib-08, which is currently
in Last Call, and has the following comments:

We understand that, upon approval of this document, there are no IANA
Actions that need completion.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Framework for Loop-free convergence using oFIB) to Informational RFC

The IESG has received a request from the Routing Area Working Group WG
(rtgwg) to consider the following document:
- 'Framework for Loop-free convergence using oFIB'
  as Informational RFC

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 2013-01-31. 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 describes the framework of a mechanism for use in
  conjunction with link state routing protocols which prevents the
  transient loops which would otherwise occur during topology changes.
  It does this by correctly sequencing the forwarding information base
  (FIB) updates on the routers.

  This mechanism can be used in the case of non-urgent link or node
  shutdowns and restarts or link metric changes.  It can also be used
  in conjunction with a fast re-route mechanism which converts a sudden
  link or node failure into a non-urgent topology change.  This is
  possible where a complete repair path is provided for all affected
  destinations.

  After a non-urgent topology change, each router computes a rank that
  defines the time at which it can safely update its FIB.  A method for
  accelerating this loop-free convergence process by the use of
  completion messages is also described.

  The technology described in this document has been subject to
  extensive simulation using real network topologies and costs, and
  pathological convergence behaviour.  However mechanism described in
  this document are purely illustrative of the general approach and do
  not constitute a protocol specification.  The document represents a
  snapshot of the work of the Routing Area Working Group at the time of
  publication and is published as a document of record.  Further work
  is needed before implementation or deployment.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-rtgwg-ordered-fib/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-rtgwg-ordered-fib/ballot/


The following IPR Declarations may be related to this I-D:

  http://datatracker.ietf.org/ipr/875/

Email sent 5th Jan 2013

===

Hi,

I am ready to move ahead with this document (thanks to Stewart for working through the issues and updating the text).

However, I need some tweaks to the Shepherd write-up. Firstly in response to my old email about the authors list (i.e., it may be OK to ask for 6 authors, but please supply me with the ammunition). Secondly to capture the results of the discussions wrt direction and intention of the document.

Thanks,
Adrian

AD review

Hi,

I've done my usual AD review of your draft prior to issuing IETF last
call and passing the I-D for IESG evaluation. The main purpose of the
review is to catch issues that might come up in later reviews and to
ensure that the document is ready for publication as and RFC.

I have a number of concerns that I believe will necessitate a new
revision of the document, so I will put it into "Revised I-D Needed"
state in the data tracker and wait to hear from you.

As always, all my comments are up for discussion and negotiation.

Thanks for the work,
Adrian

====

Purpose and direction of the document....

It's all very interesting, but why are we publishing it? What is it
adding? What is the purpose?

If this is intended to be simply a record of discussions:
1. It should say so
2. It should say that more work is needed to examine the mechanism
  before any attempt is made to convert it to a protocol
3. I don't need to review it for technical accuracy
4. I don't understand why the working group wants to publish it
5. I can't decide on the value of improving the document to make it more
  easy to read.

The document doesn't seem to have any *use*.

What does WG consensus mean for this document? That there is consensus
to publish it, or that there is consensus behind the content? If the
former, why? If the latter, what does this mean?

After discussion of this point with a WG chair and with one of the
authors, it seems that it would be reasonable to add a significant note
to the Abstract and the Introduction about the purpose. This would say
something along the lines of...

  The idea is to capture the current state of discussions in the WG so
  that they are not lost, can be referenced, and might be picked up again
  later. The WG currently has no interest in pursuing these ideas
  further.

---

Notwithstanding the discussion of scope in the point above, the Abstract
should state the scope and purpose of the document and the mechanism. If
this is a framework of a guidance for actual protocol mechanisms, it
should say that clearly and should indicate that:
- the mechanisms described need to be equally and conformantly
  implemented by every node in the "network" (is that OSPF area or
  IS-IS level?)
- this document only describes the principles, but does not specify the
  protocol details for exchange of information and synchronization of
  actions between routers in the network.

---

I am a little bothered by the use of 2119 language in this document. Do
you believe you are using it to define a conformant implementation, and
how is conformance measured if the mechanism is not for implementation?
Or are you trying to use it to set requirements for the protocol
specification that might follow? Wouldn't normal English usage be just
as good?

---

In email on the WG list you said:

> The expected use of this technology in the failure case
> is in conjunction with IPFRR where following a protected
> failure, and in the absence of a convergence control
> technology, microloops may form and/or the repair
> may be staved.

But this *really* is not apparent in this document until at the end of
Section 4.2 you have:

  The sudden failure of a link or a set of links that are not protected
  using a FRR mechanism must be processed using the conventional mode
  of operation.

Thus, reading the document, very many questions arise and there is a lot
of confusion which has to be unpicked in the light of this fact.

Indeed, the example in Figure 1 doesn't mention the FRR protection, and
the discussion seems to assume no such protection.

Furthermore, in the Abstract it says:
  This mechanism can be used in the case of non-urgent link or node
  shutdowns and restarts or link metric changes.  It can also be used
  in conjunction with a fast re-route mechanism which converts a sudden
  link or node failure into a non-urgent topology change.  This is
  possible where a complete repair path is provided for all affected
  destinations.
implying that FRR is only one of the options.

---

The fact that the oFIB process operates on a timer could possibly be
drawn out a little sooner.

---

It is pretty well hidden that this mechanism only applies in a network
where all routers apply the mechanism. In fact, I suspect that that
limitation isn't quite true, and there are fringe conditions where
routers would not need to be upgraded. But, anyway, what you clearly
need to indicate is that the mechanism depends on a way to detect that
all routers operate the mechanism. And you should probably discuss a
little what happens if one or more routers in the network do not
participate.

---

While I would agree that Section 8 describes a state machine that
produces the desired black-box behavior of an oFIB capable router, I
would suggest that it is not a requirement that oFIB capable routers
directly implement this state machine.

You might change the section to say that the state machine describes the
behavior that an oFIB capable router must demonstrate.

---

Section 8.4 suddenly introduces "LSP" and "AAH"

AAH finally shows in Appendix A.

---

Transitions to Abandoned and the text in Section 8.5 don't seem to
describe normal FIB updates (i.e. non-oFIB) but surely they have to be
done. Maybe that is what AAH stands for, but Appendix A seems to suggest
that AAH is an unknown (needing more research) and it is very unclear
what "Trigger AAH" actually means across the whole of Section 8. Yet
that line item appears a lot and is clearly an essential part of the
mechanism.

---

Section 10 should at least point at B.4.

(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?

Informational; it documents a valuable mechanism developed by the WG to prevent transient loops.

Yes, the title page indicates the correct type.

(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 mechanism for use in conjunction with link state routing protocols which prevents the transient loops which would otherwise occur during topology changes. It does this by correctly sequencing the FIB updates on the routers.

Working Group Summary:

No issues. There is consensus in the WG to proceed with publication.

Document Quality:

This document presents the general mechanism and operation of oFIB, it doesn't define routing protocol-specific extensions — which means that there are no implementations possible, but also no further work is planned at this time. The document has no substantive issues.

Personnel:

Alvaro Retana is the Document Shepherd.

Adrian Farrel is the Responsible Area Director. [Stewart Bryant is the AD assigned to the WG, but he is an author.]

(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 document (currently in it's 7th iteration) has been thoroughly reviewed. Comments have been made by the Document Shepherd related to clarity, form and content. All comments have been addressed. The document is ready for publication.

(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. The question has been raised throughout the process.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

Yes, document has an IPR disclosure attached from the authors. No concerns have been raised in the WG.

(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?

This document has been a WG item for about 6 years. During this time the mechanism (application and potential implementations) have been discussed in depth. There is strong consensus to publish this document as an Informational RFC.

(10) 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 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.

Only nit to point out is that 6 authors are listed. The authors have been made aware and are prepared to request an exception before publication.

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

N/A

(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?

None exist.

(15) Are there downward normative references 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.

No.

(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).

There are no IANA considerations which arise from this document.

(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