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. _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
