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

[Lavanya Srivatsa <[e-mail]>]

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