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

From: David Allan I <[email-masked]>
Date: Wed, 20 Apr 2011 11:29:50 -0400

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...

---

From: Robert Rennison <[email-masked]>
Date: Thu, 21 Apr 2011 16:53:27 -0400

Dave, John and George, 

Many thanks for listening to the comments regarding deviation from the base spec and potential problems in doing so.

I strongly support the approach of mandating support for the BFD  baseline specification along with the Poll/final mechanism.

I've made the point in the BFD WG when this was first presented and on the list regarding potential  problems in deviating from the base spec. The more I discuss and think through these the more I come to the conclusion that we should leave the state machines alone and not make changes for perceived optimizations of "issues". If the baseline spec was implementable in the past it still is even if encapsulated in a different wrapper.

In short whilst you could potentially get a BFD session to  work without supporting P/F you may end up dumbing the speed down to the startup value which many vendors begin with and thus the network operators will not be able to get eh equipment they have paid for to operate at the rates they are capable of merely because one vendors "letter of the law" implementation does not support P/F.

Some comments and expansion inline preceded by 

[[
[Rob Rennison] ....
]]

Cheers

Rob

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of David Allan I
Sent: Wednesday, April 20, 2011 11:30 AM
To: [email-masked]
Cc: Ross Callon
Subject: [mpls] FW: Poll / Final in draft-cc-cv-rdi

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.

[[
[Rob Rennison] Without a valid  concrete reason to change the base spec we should leave it alone, and I've yet to see any concrete rationale explained, allusion to "issues" with having to keep a  Tx and Rx state and possible optimizations are  not being concrete enough IMHO to have a productive discussion about and to change what's already working. I will try to read between the lines and see where this takes us.  The  baseline specification  has numerous interoperable implementations and should not be changed lightly. Also re your question of should we make things explicit or implicit in the spec; please do not make things implicit in the specs, any variations  are subtle enough without key points being implicit, so whatever is specified should be explicit.]
]]
 
> 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. 

[[
[Rob Rennison] Agreed, if you do not wish to change what you are accepting from the peer, then do not change the value of "_Required_ Min Rx interval" you put in the  BFD control packets you send to your peer, i.e. you can effectively ignore what he says he wants to send to you via the values he puts in "_Desired_ Min TX Interval" he sends to you.

_But_ 

You do need to interpret and act on the values your peer MEP is telling you via the "Required Min Rx Interval" so you both have to go as slow as your peer wants you to go. So whatever optimizations of the "UP processing loop" you wish to do, and I assume you mean you wish to do it all without reverting to having the control plane i.e. slow path take part, these optimizations will need to interpret the value in the "Required Min Rx interval" as sent by the peer.
You will also need to make sure you send the correct values in the State field to transmission from Down to Init to Up or perhaps your optimization will constantly send Init state.

One additional observation is that if you were to try to interoperate with a peer MEP which was capable of running a session at a value X mS but started off at Y mS where Y >> X then you would end up running at the slow rate of YmS whereas if you were true to the BFD baseline spec you would have been able to get the peer to play at the rate you desired.

This is why many implementations start of slowly at say a few packets per second or so rate and then once they have established a session they tell the peer  what the  rate is they would like to send at, they do this using the poll bit when they modify the value  they are sending in the "Desired Tx interval" field, but do not modify the rate yet. The peer can then take his sweet time setting up the hardware to be prepared to receive some potentially fast BFD control packets with a specific value of "My discriminator".  When the peer has got his hardware ready to receive, the peer responds with the final bit set and you can then "blast way at the fast rate". This is all you as a given MEP care about, "can I get this session speeded up so I can blast at him at the rate I would like to". Conversely the other end is responsible for suggesting a new fast value to you and gives you the courtesy of the P/F mechanism to allow you to get ready, whereupon you set the F bit when you are ready. In this manner  a pair of peers, for a specific session can in an orderly manner progress from a software/ control plane mechanism to one where a _simple_  hardware/fastpath/acceleration logic does the detection.

The upshot of the existing mechanism is a fairly simple hardware implementation involving some timers and pattern matching on discriminators, whereas the optimizations you allude to do not necessarily simply things for the hardware or the remote peer and would limit the interoperability. If your optimization looks to external devices like any other BFD peer then go ahead, but make sure you obey the spirit of the law and not the letter, i.e. do not fail to work with other vendors at a fast rate, which they are capable of,  because you do not support F/P.
]]

>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.

[[
[Rob Rennison] Agreed it does not have to allow for on the fly changes to session parameters  i.e. requests it gets from the peer about the rate the peer wishes to send to it i.e. the values the peer puts into the "Desired Min Tx Interval" but it does need to interpret the values it receives from  the peer in the "Required Min Rx Interval".
]]
 
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...

This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof.

---

From: Alexander Vainshtein <[email-masked]>
Date: Fri, 22 Apr 2011 16:49:52 +0300

Hi all,
I concur with Rob: the session state machine should be
compliant with t RFC 5880.

My 2c,
Sasha
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Robert Rennison [[email-masked]]
Sent: Thursday, April 21, 2011 11:53 PM
To: David Allan I; [email-masked]
Cc: Ross Callon
Subject: Re: [mpls] Poll / Final in draft-cc-cv-rdi

Dave, John and George,

[[
[Rob Rennison] ....
]]

Cheers

Rob

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of David Allan I
Sent: Wednesday, April 20, 2011 11:30 AM
To: [email-masked]
Cc: Ross Callon
Subject: [mpls] FW: Poll / Final in draft-cc-cv-rdi

Hi Folks:

[[

[[

_But_

This is why many implementations start of slowly at say a few packets per second or so rate and then once they have established a session they tell the peer  what the  rate is they would like to send at, they do this using the poll bit when they modify the value  they are sending in the "Desired Tx interval" field, but do not modify the rate yet. The peer can then take his sweet time setting up the hardware to be prepared to receive some potentially fast BFD control packets with a specific value of "My discriminator".  When the peer has got his hardware ready to receive, the peer responds with the final bit set and you can then "blast way at the fast rate". This is all you as a given MEP care about, "can I get this session speeded up so I can blast at him at the rate I would like to". Conversely the other end is responsible for suggesting a new fast value to you and gives you the courtesy of the P/F mechanism to allow you to get ready, whereupon you set the F bit when you are
  ready. In this manner  a pair of peers, for a specific session can in an orderly manner progress from a software/ control plane mechanism to one where a _simple_  hardware/fastpath/acceleration logic does the detection.

[[

the editors
Dave, John and George...

_______________________________________________
mpls mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls