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

From: Lavanya Srivatsa <[email-masked]>
Date: Wed, 9 Jun 2010 17:15:07 +0530

All,

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?

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.

Can somebody please clarify?

- Lavanya

---

From: David Allan I <[email-masked]>
Date: Wed, 9 Jun 2010 14:02:28 -0400

HI Lavanya:

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?

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

---

From: Maarten Vissers <[email-masked]>
Date: Thu, 10 Jun 2010 10:41:50 +0200

Dave, Lavanya,
 
The 1+1 SNC/N protection architecture is the following:
 
                                            MEP Sink A
                   W                           | W
                  /---->-------MIP-MIP------->----\
--MEP-MIP----MIP-+                                 \--MIP-----MIP-MEP->
   X              \-----MIP-MIP-----MIP-MIP-->----/                Y
                   P                           | P
                                            MEP Sink B

                  MEP Sink C
                   W |                           W
                  /------------MIP-MIP-------<----\
<-MEP-MIP----MIP-/                                 +--MIP-----MIP-MEP-
   X              \-----MIP-MIP-----MIP-MIP--<----/                Y
                   P |                           P
                  MEP Sink D

In this 1+1 SNC/N architecture the MEP functions (X,Y) are located outside
the protected domain. Inside the protected domain two pairs of MEP Sink
functions (A,B and C,D) are present in which the OAM from MEP X to MEP Y and
vice versa from MEP Y to MEP X is non-intrusively monitored.

MEP X generates CC/CV, LM and RDI OAM and this OAM is terminated in MEP Y.
MEP Y generates CC/CV, LM and RDI OAM and this OAM is terminated in MEP X.

MEP Sink A and B monitor non-intrusively the CC/CV and LM OAM information
generated by MEP X.
MEP Sink C and D monitor non-intrusively the CC/CV and LM OAM information
generated by MEP Y.
Note that there is no return path from A to X, from B to X, from C to Y and
from D to Y.

MEP Sink A,B,C and D determine then the SF and SD status of the Working and
Protection connections.

MEP X and Y determine the SF and SD status and near-end and far-end
performance of the protected connection.

The 1+1 SNC/S architecture is the following:

                   W                                   W
                  /-MEP-----------MIP-MIP------->---MEP-\
--MEP-MIP----MIP-+   W1                             W2
\--MIP-----MIP-MEP->
   X              \-MEP----MIP-MIP-----MIP-MIP-->---MEP-/                Y
                   P P1                             P2 P

                   W                                   W
                  /-MEP-----------MIP-MIP-------<---MEP-\
<-MEP-MIP----MIP-/   W1                             W2   +--MIP-----MIP-MEP-
   X              \-MEP----MIP-MIP-----MIP-MIP--<---MEP-/                Y
                   P P1                             P2 P

The 1:1 SNC/S architecture is the following:

                   W                                   W
                  /-MEP-----------MIP-MIP------->---MEP-\
--MEP-MIP----MIP-/   W1                             W2
\--MIP-----MIP-MEP->
   X              \-MEP----MIP-MIP-----MIP-MIP-->---MEP-/                Y
                   P P1                             P2 P

                   W                                   W
                  /-MEP-----------MIP-MIP-------<---MEP-\
<-MEP-MIP----MIP-/   W1                             W2   \--MIP-----MIP-MEP-
   X              \-MEP----MIP-MIP-----MIP-MIP--<---MEP-/                Y
                   P P1                             P2 P

Both SNC/S protection architectures have a common model. The difference
between the two architectures is the type of protection bridge process: 1+1
SNC/S deploys a "broadcast bridge" and 1:1 SNC/S deploys a "selector
bridge".

In this 1+1/1:1 SNC/S architecture MEP functions (X,Y) are located outside
the protected domain. Inside the protected domain two pairs of MEP functions
(W1,P1 and W2,P2) are present. MEP W1 and MEP W2 monitor the Working
connection. MEP P1 and MEP P2 monitor the protection connection. 

MEP X generates CC/CV, LM and RDI OAM and this OAM is terminated in MEP Y.
MEP Y generates CC/CV, LM and RDI OAM and this OAM is terminated in MEP X.

MEP W1 generates CC/CV, LM and RDI OAM and this OAM is terminated in MEP W2.
MEP W2 generates CC/CV, LM and RDI OAM and this OAM is terminated in MEP W1.
MEP P1 generates CC/CV, LM and RDI OAM and this OAM is terminated in MEP P2.
MEP P2 generates CC/CV, LM and RDI OAM and this OAM is terminated in MEP P1.

MEP W1, W2, P1 and P2 determine the SF and SD status of the working and
protection connections.

MEP X and Y determine the SF and SD status and near-end and far-end
performance of the protected connection.

Comparing the three SNC protection architectures one can observe that
- 1+1 and 1:1 SNC/S protection architectures are identical and have the same
type of OAM
- 1+1 SNC/N protection architecture and the 1+1/1:1 SNC/S protection
architectures are different. The OAM generated by the MEP X and Y in both
architectures is the same.

Regards,
Maarten
________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf
Of David Allan I
Sent: woensdag 9 juni 2010 20:02
To: Lavanya Srivatsa; MPLS TP
Subject: Re: [mpls-tp] BFD sessions wrt protection types

HI Lavanya:

"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?

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

---

From: Lavanya Srivatsa <[email-masked]>
Date: Mon, 14 Jun 2010 00:39:35 +0530

Dave,

Please see inline.

- Lavanya

________________________________
From: David Allan I [[email-masked]]
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.”

[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 hope this helps
D

---

From: John E Drake <[email-masked]>
Date: Mon, 14 Jun 2010 08:26:17 -0700

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-----
> Of Lavanya Srivatsa
> Sent: Sunday, June 13, 2010 12:10 PM
> To: MPLS TP; David Allan I
> "A single bi-directional BFD session is used for fate sharing operation.
> Two independent BFD sessions are used for independent operation.
> 
> ....
> 
> 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?
> 
> 
> 
> [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.
> 
> 
> 
> functionality to protect traffic, why should the "underlying" OAM
> operation be disturbed just because the "application" above it undergoes a
> change?
> 
> 
> 
> 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
> 
>

---

From: John E Drake <[email-masked]>
Date: Mon, 14 Jun 2010 12:14:37 -0700

Hi,

As I said, all references to protection will be removed from the I-D.  This means that there is no mandated coupling of which mode is run with which protection scheme.

Thanks,

John

> Of John E Drake
> Sent: Monday, June 14, 2010 8:26 AM
> To: Lavanya Srivatsa; MPLS TP; David Allan I
> 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
> 
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp