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

["Drake, John E" <John.E.Drake2@boeing.com>]

Dimitri,

I think you're absolutely right.  Furthermore, this application seems to
be a natural for LSP hierarchy, where there would be a containing
symmetric bi-directional LSP with contained asymmetric uni-directional
LSPs.  The latter would be correlated with the Association object.

This would give you fate sharing and fast recovery via the
re-instantiation of the containing LSP, and reasonable control plane
performance, since the contained LSP signaling is only between the
containing LSP endpoints.

Thanks,

John 

> -----Original Message-----
> From: Dimitri.Papadimitriou@alcatel-lucent.be 
> [mailto:Dimitri.Papadimitriou@alcatel-lucent.be] 
> Sent: Tuesday, March 06, 2007 1:45 PM
> To: Adrian Farrel
> Cc: Attila Takacs (IJ/ETH); ccamp@ops.ietf.org; Don Fedyk; 
> owner-ccamp@ops.ietf.org; Pandian, Vijay
> Subject: Re: What is this fate sharing thing? [Was: Questions 
> on draft-takacs-asym-bw-lsp-00.txt]
> 
> adrian, all
> 
> the point is not whether "We need asymmetrical bidirectional services"
> but "Do we have a clear requirement for asymmetrical 
> bidirectional LSPs?" 
> 
> when i look at some of the examples that have been cited, it 
> would surprise me that we would provision an LSP per 
> micro-flow across the network (being Ethernet or whatever 
> packet technology), even more, GMPLS is mostly used as an 
> edge-to-edge technology in most cases, GMPLS capable devices 
> do not even interact with the sources of traffic some where 
> mentioning in their examples
> 
> i am also reading that some Ethernet equipment are 
> introducing several specific (data plane) constraints, 
> indeed, but the control plane is not going to elevate those, 
> in part. these constraints are independent whether one has 
> unidirectional LSP, or asym bandwidth LSP provisioning 
> capability at control plane level (adrian pointed this out 
> numerous times but this is one of the cornerstone of the 
> whole discussion)
> 
> hence, the point since so far, is that they are no convincing 
> argument in favor of an asymmetric LSP bandwidth provisioning 
> WITHIN a single signaling exchange, indeed, most arguments 
> are boiling down to hypothetical control plane efficiency 
> that can be ensured by other means if we consider the 
> restricting conditions where the proposed approach would be workable 
> 
> -d.
> 
> 
>  
> 
> 
> 
> 
> 
> "Adrian Farrel" <adrian@olddog.co.uk>
> Sent by: owner-ccamp@ops.ietf.org
> 06/03/2007 12:05
> Please respond to "Adrian Farrel"
>  
>         To:     "Attila Takacs \(IJ/ETH\)" 
> <Attila.Takacs@ericsson.com>, 
> "Pandian, Vijay" <Vijay.Pandian@sycamorenet.com>, "Don Fedyk" 
> <dwfedyk@nortel.com>
>         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?
> 
> - 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?
> 
> - 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?
> 
> 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.
> 
> 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.
> 
> End-to-end protection features are implemented at a different 
> level and seem to be beyond this debate.
> 
> 
> 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?
> 
> Adrian
> 
> ----- Original Message -----
> From: "Attila Takacs (IJ/ETH)" <Attila.Takacs@ericsson.com>
> To: "Pandian, Vijay" <Vijay.Pandian@sycamorenet.com>; "Don Fedyk" 
> <dwfedyk@nortel.com>
> Cc: <ccamp@ops.ietf.org>
> Sent: Tuesday, March 06, 2007 10:34 AM
> Subject: RE: Questions on draft-takacs-asym-bw-lsp-00.txt
> 
> 
> Hi Vijay,
> 
> let me answer this.
> 
> If you need different protection for each direction then you 
> likely will
> need differently routed LSPs. In this case one better uses separate
> sessions for the two directions since all the benefits of having a
> single session (like fate sharing) is gone if the LSPs take different
> routes. The ID only proposes to relax the symmetrical 
> bandwidth property
> of the bidirectional LSP establishment given in RFC3471.
> 
> Regards,
> Attila
> 
> ________________________________
> 
> From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On
> Behalf Of Pandian, Vijay
> Sent: Tuesday, March 06, 2007 1:36 AM
> To: Don Fedyk
> Cc: ccamp@ops.ietf.org
> Subject: RE: Questions on draft-takacs-asym-bw-lsp-00.txt
> 
> 
> 
> Don,
> 
> The question I had regarding P&R was trying to figure out if one
> direction required a better P&R (say 1+1) and the reverse direction
> probably required some basic P&R (say Re-routing).
> 
> So the requirement is to use the same "physical link" for the
> forward and reverse direction. Am I right?
> 
> Regards,
> 
> Vijay
> 
> 
> 
> -----Original Message-----
> From: Don Fedyk [mailto:dwfedyk@nortel.com]
> Sent: Monday, March 05, 2007 6:41 PM
> To: Pandian, Vijay; ccamp@ops.ietf.org
> Subject: RE: Questions on
> draft-takacs-asym-bw-lsp-00.txt
> 
> 
> Hi Vijay
> 
> 
> ________________________________
> 
> From: owner-ccamp@ops.ietf.org
> [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Pandian, Vijay
> Sent: Monday, March 05, 2007 2:07 PM
> To: ccamp@ops.ietf.org
> Subject: Questions on
> draft-takacs-asym-bw-lsp-00.txt
> 
> 
> Hi,
> 
> I have some basic questions, primarily trying to
> understand the scope of this ID as well as the application 
> behind such a
> requirement.
> 
> 1. Does this ID address just an asymmetric
> Bandwidth requirement?
> 
> The postulation was that GMPLS today supports
> bi-directional service with a single RSVP-TE session creating a
> bidirectional LSP.  The most common implementation of this is Optical
> TDM networks.  Since this was the starting point, the ID postulates
> setting up an asymmetric service with a single asymmetric LSP.  (Like
> many new drafts it sets a requirement and postulates a an
> implementation.)
> 
> So to your question besides bandwidth there is also
> underlying requirement to align with GMPLS single session 
> procedures and
> support a bi-directional packet data plane as Ethernet does today.  A
> single bidirectional (in this case asymmetric BW capable) 
> LSP.  In other
> words a single RSVP-TE session.  Several people have pointed 
> out this is
> also achievable with two unidirectional RSVP-TE sessions (one at each
> end).  Rather than reopen that debate on this thread I will 
> acknowledge
> the authors had a single session in mind more as a requirement of the
> technology.  Ethernet data forwarding is bi-directional symmetric and
> there are efficiencies in a single session of a 
> bi-directional LSP.  On
> the other hand the issue is there is currently no way to specify the
> asymmetric BW. If you want to discuss the pros and cons of multiple
> sessions versus single there is already a thread on this (RE: I-D
> ACTION:draft-takacs-asym-bw-lsp-00.txt)
> 
> |  2. How about other attributes? in particular LSP
> Protection & Recovery (P&R) related attributes?
> 
> With respect to GMPLS, the plan was to allow
> bi-directional Protection or Recovery LSPs controlled by separate
> RSVP-TE sessions in separate from the single RSVP-TE session 
> associated
> with the primary bidirectional LSP.
> 
> 3. If P&R are indeed different, doesn't it make
> sense to route them separately (separate CSPF calculation at each end)
> and eventually signal them independently as well?
> 
> 
> Hopefully I addressed part of this already. Recovery of
> the bi-directional LSP could be handled by another RSVP-TE session &
> LSP.  The data plane in our case must have a bi-directional symmetric
> path so you can only do a CSPF at one end and/or force the paths to
> align.
> 
> 4. Is there a need for the forward and reverse
> flows to be on the same path?
> 
> 
> That is the way an Ethernet data plane works, and in my
> case this is where the requirement comes from. There is Ethernet data
> plane OAM and in some cases Ethernet forwarding rules that 
> both require
> bi-directional symmetric paths.  The requirement is to be able to
> support native Ethernet loopback and data plane trace functions and
> bi-directional symmetry in the data plane is required.
> 
> 5. What is "fate sharing"? I couldn't find this
> in other RFCs or IDs. Is it same as link/node/SRLG disjoint paths?
> 
> 
> Yes it is related.  A shared resource link group
> identifies shared resources at some granularity. Fate shared 
> paths have
> shared resources at a very high level of granularity.  Disjoint paths
> have none or very few shared resources.  For a bidirectional path the
> shared fate comes from the fact that both direction have common
> resources and if one fails the other is likely to fail.
> 
> Regards,
> Don
> 
> 
> Regards,
> 
> Vijay
> 
> 
> 
> 
> 
> 
> 
>