[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: What is this fate sharing thing? [Was: Questions on draft-takacs-asym-bw-lsp-00.txt]
Hi Adrian,
Please see inline.
Regards,
Attila
> -----Original Message-----
> From: Adrian Farrel [mailto:adrian@olddog.co.uk]
> Sent: Tuesday, March 06, 2007 12:05 PM
> To: Attila Takacs (IJ/ETH); Pandian, Vijay; Don Fedyk
> 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.
Control plane fate sharing was mentioned as one benefit when having a
single session. In this case additional message exchanges are not needed
and there are no additional delays which otherwise would be an issue
with restoration.
>
> 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.
>
Agreed, the data plane aspects are technology specific.
> 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?
Another point is on application scenarios. As Dimitri pointed out in his
early mails, if a general extension to support asymmetric bandwidth is
going to be specified its complexity might outweigh its benefits.
However, given a focused scenario with single sided control and full
bandwidth knowledge at the ingress, the simple extensions given in the
ID might be appropriate. The question on this would be whether the
proposed extension with this scope is worth the effort.
>
> 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
>
>
>
>