RE: What is this fate sharing thing? [Was: Questions on draft-takacs-asym-bw-lsp-00.txt]

["Don Fedyk" <dwfedyk@nortel.com>]

Hi Adrian


In an Ethernet bridging context I'll try to add what I know. 

> -----Original Message----- From: Adrian Farrel
> [mailto:adrian@olddog.co.uk] Sent: Tuesday, March 06, 2007
> 6:05 AM To: Attila Takacs (IJ/ETH); Pandian, Vijay; Fedyk,
> Don (BL60:1A00) Cc: ccamp@ops.ietf.org Subject: What is
> this fate sharing thing? [Was: Questions on
> draft-takacs-asym-bw-lsp-00.txt]
> 
> Hi,
> 
> There has been a lot of discussion about "fate-sharing"
> and I am not sure what problem we are trying to solve.
> 
> - Is this a data plane feature where a data plane fault in
> one direction must cause data plane interruption in both
> directions?
[DF]When we say data plane I suppose it depends on the Physical
layer as well. I'm not much of an expert on physical layers
but I believe we went over much of this in the GMPLS control
of optical. 

For Ethernet bridging, if there is a fault detected in one direction
the OAM signals the fault and at a minimum an alarm is
raised. I don't believe there is an immediate attempt to
interupt data but one result may be to use the indication or
activate protection or restoration mechanisms. 
In Ethernet bridging the Bridge Relay is a bi-drectional functions 
that is attached to two ports. (below the ports there may be 
unidirectional links). 
 
> 
> - Is this a protection feature where the switch-over of
> one direction to its backup path must be accompanied by a
> switch-over of the other direction, too?
[DF]In Ethernet this is the case. Unidirectional Ethernet would
not support many Ethernet features. 

> 
> - Is this a control plane feature where the removal of
> control plane state in one direction must cause the
> removal of control plane state in the other direction?
[DF]I don't know if I can parse this. "removal of control plane
state in one direction in a bidirectional LSP?" I think you
may be refering to the case where two RSVP-TE sessions
control a single bi-directional path.  The point is the data
plane should not be unidirectionally active since this would
create issues with OAM functions that assume a bidirectional
data plane.  
> 
> The use of a single control plane state (bidirectional
> signaling) obviously makes control plane fate-sharing
> automatic, but the use of associated signaling does not
> preclude control plane fate sharing - it just needs
> additional message exchanges.
[DF]True but in the case of associated case there is also a
concept of a master and slave relationship between the
associated signaling paths for any given action. This
requires new capability as well.
> 
> The use of an identical path for both directions can
> provide some elements of data plane fate sharing, but it
> is important to note that it does not guarantee it. For
> example, a unidirectional fiber could fail.  This issue is
> not impacted by bidirectional or associated signaling as
> the directions can be installed on the path by associated
> signaling, and as a failure might only impact one
> direction in bidirectional signaling.
[DF]The bi-directional aspects are at the L2 Ethernet bridge level.
Unidirectional faults are detected as loss of Connectivity
check messages or the like and declared the ethernet LSP in
fault. What action is taken depends on the choice of
configuration and control plane.

> 
> End-to-end protection features are implemented at a different 
> level and seem to be beyond this debate.

[DF]There could be an association object to implement some
aspects of co-ordination between a primary and a backup LSP.
> 
> 
> So I am wondering what relevance fate-sharing has to the
> discussion of asymmetrical bandwidth. Maybe the discussion
> has reduced to:
> - We need asymmetrical bidirectional services 
> - Does the value of a single signaling exchange
> outweigh the cost of new signaling objects and procedures?
[DF]The fate sharing aspect is related to the Ethernet
bi-directionality.  We need bi-directional Ethernet LSPs 
with (symmetric or asymmetric BW). This requirement is stronger 
than your first point.

Perhaps Fate sharing is not the right or the best term.  My
understanding of Ethernet is a typically a Spanning tree
creates the bi-directional Ethernet paths that have these
properties. You can also configure static Ethernet paths
that have the same properties. 


Regards,
Don 


> 
> Adrian
> 
<snip>