Authors and shepherd, Are there any plans to move this document forward?
Thanks, Adrian > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Adrian Farrel > Sent: 01 October 2012 22:51 > To: [email protected] > Cc: [email protected] > Subject: AD review of draft-ietf-rtgwg-ordered-fib > > 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 _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
