[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]
Dimitri,
> Dimitri.Papadimitriou@alcatel-lucent.be
> Sent: 08 March 2007 23:34
>
> igor
>
> "Hence, if we are to support Ethernet layer by GMPLS, we must
> consider
> mapping them on single bi-directional LSPs."
>
> this statement is fundamentally incorrect,
NH=> You are correct, but for a different reason that you seem to talk
about below. GMPLS is a suite of control-plane protocols...a server
layer control-plane does not support/create client layer network
topology, it is the server layer *data-plane* that does that job.
I attempted to explain a few days ago why a p2p bidirectionally
congruent server layer *data-plane* construct is THE atomic building
block for client topology creation (any client)...and I tried to show an
example here from fault management (eg OAM, prot-sw) considerations why
this is important. As a thought experiment try constructing a client
layer topology from anything other than p2p server layer building
blocks.
The way native cl-ps mode Ethernet works however makes this
(bidirectionally congruent server requirement) rather obvious/important
anyway IMO....which is the point Igor is making above, so he is actually
correct in this respect. And this has nothing to do with whether one
uses a GMPLS control-plane in the server layer network or not, it is
only relevant to the server layer data-plane.
regards, Neil
> the association of control
> plane state to data plane state is independent on the Ethernet
> constraints,
> one may device control plane techniques that are
> facilitating
> operations but there are by no means reason to constrain the
> way nodes are
> performing such association
>
> as i wrote a couple of days ago
>
> "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)"
>
> -d.
>
>
>
>
>
>
> Igor Bryskin <i_bryskin@yahoo.com>
> Sent by: owner-ccamp@ops.ietf.org
> 07/03/2007 15:34
>
> To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL,
> Adrian Farrel
> <adrian@olddog.co.uk>
> cc: "Attila Takacs \(IJ/ETH\)"
> <Attila.Takacs@ericsson.com>,
> ccamp@ops.ietf.org, Don Fedyk <dwfedyk@nortel.com>,
> owner-ccamp@ops.ietf.org, "Pandian, Vijay"
> <Vijay.Pandian@sycamorenet.com>
> Subject: Re: What is this fate sharing thing? [Was:
> Questions on draft-takacs-asym-bw-lsp-00.txt]
>
>
> Dimitri.
>
> See in-line.
>
> Dimitri.Papadimitriou@alcatel-lucent.be wrote:
> 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
>
>
> IB>> What Neil and Don are saying is that some signifficant Ethernet
> functionality will be lost if an Ethernet bi-directional
> service is mapped
> on non-congruent paths. This exactly coincides with what I
> hear from our
> local Ethernet experts. Hence, if we are to support Ethernet layer by
> GMPLS, we must consider mapping them on single bi-directional
> LSPs. This
> is not "hypothetical control plane efficiency" discussion.
> Bi-directional
> LSPs are as important in Ethernet as in TDM or optical
> layers. But I do
> agree with you that so far there were no convincing examples
> presented
> just yet that illustrate the need of bandwidth asymetrical services.
>
> Igor
>
> -d.
>
>
>
>
>
>
>
>
> "Adrian Farrel"
> Sent by: owner-ccamp@ops.ietf.org
> 06/03/2007 12:05
> Please respond to "Adrian Farrel"
>
> To: "Attila Takacs \(IJ/ETH\)" ,
> "Pandian, Vijay" , "Don Fedyk"
>
> cc:
> 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)"
> To: "Pandian, Vijay" ; "Don Fedyk"
>
> Cc:
> 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
>
>
>
>
>
>
>
>
> 8:00? 8:25? 8:40? Find a flick in no time
> with theYahoo! Search movie showtime shortcut.
>
>
>