Re: [mpls-tp] BFD sessions wrt protection types

[John E Drake <[e-mail]>]

Hi,

The latest version of cc-cv-rdi will remove all references to protection switching.

In order to have a mode in which an LSP failure in one direction did not cause a failure in the other direction, it turns out that using two essentially uni-directional BFD sessions minimized the changes to BFD.  As indicated in the I-D, we basically just have several clarifications to existing BFD behavior. 

Thanks,

John  

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of Lavanya Srivatsa
> Sent: Sunday, June 13, 2010 12:10 PM
> To: MPLS TP; David Allan I
> Subject: Re: [mpls-tp] BFD sessions wrt protection types
> 
> Dave,
> 
> Please see inline.
> 
> - Lavanya
> 
> ________________________________
> 
> From: David Allan I [[e-mail]]
> Sent: Wednesday, June 09, 2010 11:32 PM
> To: Lavanya Srivatsa; MPLS TP
> Subject: RE: BFD sessions wrt protection types
> 
> 
> HI Lavanya:
> 
> 
> 
> When the draft-ietf-mpls-tp-cc-cv-rdi states:
> 
> "A single bi-directional BFD session is used for fate sharing operation.
> Two independent BFD sessions are used for independent operation.
> 
> ....
> 
> The normal usage is that 1:1 protected paths must use fate sharing, and
> independent operation applies to 1+1 protected paths."
> 
> 
> 
> Does this mean that every time (and whenever it is done so) the protection
> switching architecture is changed by configuration/administrator from one
> to the other, the number of BFD sessions must change? Changing BFD
> sessions would include tear down or new setup of sessions?
> 
> 
> 
> As currently written the answer would be "yes". However how frequently do
> you actually expect this to happen in practice. Isn't this a change that
> moves at the speed of lawyers?
> 
> 
> 
> [LS] Agreed, this is not expected to change often, maybe only once during
> network setup too. But I was trying to make a different point here. I feel
> that protection is one way of using the, if I may call it, "output" of an
> OAM process. As an alternate, (and just for argument's sake), faults
> detected by an OAM process need not necessarily result in a protection
> switch. An operator (again just for argument's sake) could simply choose
> to have alarms generated and to take corrective actions through manual
> intervention.
> 
> Similarly, a protection switch onto a recovery path need not be the result
> of an OAM indication, but could be manually driven.
> 
> So, on the whole, I feel the OAM and protection switch processes are
> related but not dependent. Therefore imposing restrictions on the number
> of BFD sessions based on the protection switching architecture, IMHO, does
> not seem to be right.
> 
> For eg: if 1:1 requires fate share, it should be of no interest to the
> protection switch process, whether the OAM process chose to run 1 OAM/BFD
> session or 2 OAM/BFD sessions. All the protection switch process needs is
> that, irrespective of the number of sessions, the traffic of both
> directions of the path fate share even during an unidirectional fault. How
> the OAM process does this should not be of any concern to the protection
> switch process.
> 
> 
> 
> Since protection switching is an "application" that uses the OAM
> functionality to protect traffic, why should the "underlying" OAM
> operation be disturbed just because the "application" above it undergoes a
> change?
> 
> 
> 
> I am unable to understand the dependency of the number of BFD-OAM sessions
> based on the protection switching architectures/types.
> 
> 
> 
> In a perfect world specifying a greenfield technology you'd get that
> decoupling. My take is that BFD cares about whether somthing is up or down
> in order to conserve nodal resources. When something is broken, the node
> has better things to do than expend compute cycles originiating large
> numbers of messages that simply black hole. That is when the nodal
> resources are better spent being available for management or CP activity,
> and restoration will happen faster in some implementations as a
> consequence of dialing back superfluous BFD message generation.
> 
> 
> 
> I hope this helps
> 
> D
> 
>