Subject: [Fwd: FW: Poll / Final in draft-cc-cv-rdi]

From: [email-masked]
Date: Tue, 26 Apr 2011 19:38:27 +0200

BFD Working Group,

this is a discussion just starting on the mpls working group
mailing list, that might be of interest for you.

/Loa

---------------------------- Original Message ----------------------------
Subject: FW: Poll / Final in draft-cc-cv-rdi
From:    "David Allan I" <[email-masked]>
Date:    Wed, April 20, 2011 5:29 pm
To:      "[email-masked]" <[email-masked]>
Cc:      "Loa Andersson" <[email-masked]>
         "Ross Callon" <[email-masked]>
         "George Swallow" <[email-masked]>
         "John E Drake" <[email-masked]>
--------------------------------------------------------------------------

Hi Folks:

We've received a number of comments both formally and informally that the
current draft has deviated too far from the base BFD spec and thus loses
backward compatibility with existing code bases.  Further, discussions with
the BFD WG have indicated we have a potential race condition in the current
startup procedures described in draft-cc-cv-rdi.

The issue is the transition to UP state requires confirmation by the peer
MEP prior to changing the detection time to the rx-interval x detect mult in
order to avoid potential flapping. This can result in an implementation
effectively needing two UP states (UP forward, UP reverse direction).
Otherwise the MEP may time out the reverse direction before seeing an UP
state from the peer MEP.

So we can make this implicit in the specification and require BFD changes or
we can use poll/final discipline on startup as defined in the base
specification and make the transition to fully UP and the desired rate both
explicit and exposed in the protocol exchange. This would reduce the deltas
between the base spec (RFC 5880) and draft CC-CV-RDI.

We would also observe that it is permissable in the specification to respond
to a poll with a final reply with the session parameters unchanged. So once
a session is up a compliant implementation does not actually have to
implement on the fly changes to session paramters. The processing of the
poll bit can simply be reduced to setting the final bit in the next message.
This would permit implementations to optimize the UP processing loop.

This is a change of direction from what has been in the draft to date, hence
we'd look to the WG for comment on this change...

the editors
Dave, John and George...