Re: draft-palanivelan-bfd-v2-gr-08

[Dave Katz <[e-mail]>]

On Oct 28, 2010, at 7:01 AM, Palanivelan A (apvelan) wrote:

>  
> We see BFD to be serving what it is meant to and the wide implementations of this technology points to its acceptance.
> If we have to pick at the areas that are little grey, BFD for routing protocols with GR comes as one of them.

If there is a need to describe how to do GR more explicitly, a BCP would be the ideal vehicle, as an implementation that follows it would continue to be interoperable with other implementations that don't do the function.  If an implementor is looking for a solution, one that does not require modification of the protocol is actually a feasible option, whereas modifying the protocol is not (at least not if interoperability is a requirement, at least for a significant time.)

But it appears that the proposed change simply doesn't work for the primary interesting case (unscheduled restart with short detection times) because, as far as I can tell, *nothing* can solve that problem, and it also doesn't fix the issue with poor scheduling, which in any case is an implementation problem that cannot be fixed by the protocol.

>  
> Though the success of BFd with GR depend on the system design and that there can be different ways of addressing the issue in line with the design,
> This draft intended to provide a common solution that can be adopted. This was originally intended for “standards track”.

But as far as I can tell, it doesn't actually do what it purports to do, and thus modifies the protocol to no useful end.

>  
> But this working group, within its rights felt that BFD would not look for such an extension and that this need not be considered for a standards track and
> I am certainly not debating on that. The independent reviewers however proposed that this draft can be recorded for future and hence were willing to
> consider this draft for  a “Historic” status.The revisions to this draft were all based on these review comments.

I don't think that there is any mechanism for an ID to achieve Historic status (which is a misnomer in this case), though I'm not an IETF process expert;  IDs are purged after six months.  If I understand correctly, Historic status is used to classify older RFCs whose technology has been abandoned or otherwise overtaken by events.  I don't believe there is any mechanism by which this draft can be archived within the IETF.

As far as I can tell, the draft was last discussed in public in July of 2009 (which I suppose is why I was confused about how it came to have six more revisions since then) and the only comments boiled down to "this isn't necessary".  When it popped up again on the list yesterday, I took a harder look and came to the conclusion that it is not only unnecessary, but won't solve any problems that aren't already solvable by the RFCs.

I appreciate the fact that you're interested enough in the problem to take the time to write and edit a draft, and I certainly don't want to dissuade you.  But I would urge you to put that energy into a draft that clarifies the functional and implementation issues with GR in a way that operates within the existing standards track documents;  such a draft could end up as an RFC and suitably recorded.

--Dave