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

[Maarten Vissers <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] 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:

 

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?

 

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