[RTG-DIR] RtgDir review: draft-palanivelan-bfd-v2-gr-10.txt

[Ben Niven-Jenkins <[e-mail]>]

Hello,
I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html

As this is an Independent submission via the ISE these comments are primarily for the use of the Routing ADs.

Document: draft-palanivelan-bfd-v2-gr-10.txt
Reviewer: Ben Niven-Jenkins
Review Date: 12 April 2011
IETF LC End Date: N/A
Intended Status: Historic

Summary: I have significant concerns about this document and recommend that the Routing ADs discuss these issues further with the authors.

Comments: In places the text of the document is extremely hard to parse and I had to read some sections multiple times to try to understand what was written.

Major Issues:
Although I note that this is a Independent submission with an Intended Status of Historic that documents a proposal that was rejected by the BFD WG and that RFC5742 section 5 states "In general, the IESG has no problem with rejected alternatives being made available to the community;" in my opinion the document extends an IETF protocol in a way that requires further review by the Routing ADs and/or the BFD WG before being considered for publication, because:

1) The document introduces two new sections/fields into the Generic BFD Control Packet format specified in RFC5880 section 4.1 without any discussion or details of:

A) Whether such a change would constitute or require a new version of the BFD protocol, or

B) Whether such a change is backwards compatible and/or interoperable with existing BFD protocol version and implementations. 

2) The document introduces a new BFD state machine that differs from the existing state machine specified in RFC5880 in three ways:

A) It expects implementations to transition between states based on the value of the received Diag field whereas the existing BFD state machine does not rely on the value of the Diag field to initiate state changes. [Section 6.2 Paragraph 9]

B) It removes the ability to transition out of the DOWN state. As RFC5880 specifies that newly created BFD sessions start in the DOWN state it would appear that the new state machine proposed in the document removes the ability for a BFD session between neighbours to bootstrap itself. [State diagram in Section 5]

C) It introduces a new state "NEIGHBORRESTART" which appears (to me) to be backwards compatible but given (A) and (B) above it would seem prudent to be cautious and request a review from the BFD WG in order to be certain. [State diagram in Section 5]

3) The document states in the abstract:

   This document is a historical record of some work and discussions in
   the bfd working group on a possible solution to the Graceful Restart
   issues with BFD.  To keep the protocol simple, it was decided not to
   include this extension in the BFD standard.

However from perusing the BFD mailing list archive it would appear IMO that the above is not an accurate characterisation of the discussion which appears to me have been reasonably hostile towards the proposal with more than one participant expressing the view that the proposed solution does not in fact solve the problem that it purports to. 

As the document is claiming to record the outcome of discussions in the BFD WG it would seem appropriate for the BFD WG to formally review the document to ensure that the document is an accurate record of those discussions.

Minor Issues: 
1) The document states that it addresses Graceful Restart issues with BFD but its description of those issues in Section 2 paragraph 2 is not particularly well explained and the text is extremely hard to parse.


Ben