Subject: AD review of draft-ietf-rtgwg-ordered-fib

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 1 Oct 2012 22:51:13 +0100

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.