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

["Adrian Farrel" <[e-mail]>]

Authors and shepherd,

Are there any plans to move this document forward?

Thanks,
Adrian

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Adrian Farrel
> Sent: 01 October 2012 22:51
> To: [e-mail]
> Cc: [e-mail]
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtgwg