[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]
John....tend to agree with these points. The only truly recursive
topological construct is p2p.....one can almost consider this as THE
topological atomic building block of hierarchy (ie a client/server layer
network relationship). This becomes quite evident when we consider the
fact that a link connection in layer network N is provided by a trail in
layer network N-1...a relationship which is clearly recursive across a
stack of nested layer networks.
Now a p2mp construct (like a p2p construct) is also a connection (Note -
A trail is specific p2p relationship, so in a p2mp connection a trail
exists between the root and each leaf). However mp2p and mp2mp
constructs are not connections.
As previously noted, one can only recursively construct topology with a
p2p connection. So if we want to create p2mp connections (and we will)
these should only exist at the very top of a network stack in the
context of a some service instance, ie we cannot use p2mp connections
(and certainly not mp2p and mp2mp constructs) for recursive topology
creation.
Why is this important?
Well, its all about deterministic resource assignment and
management....and this plays through to a whole raft of practical
considerations (eg OAM/fault management, performance/SLAs, etc) that
should be important to operators and their customers (which can be other
operators). The key point about a connection is that it must only have
a single source and no internal routing once created....this is
essentially a definition of a connection, and it comes from information
theory considerations of resource determinism. Connections do not
(obviously) exist in the cl-ps mode. In the co-cs mode connections can
be created using time (eg SDH/PDH), freq (eg WDM) and space (eg per
fibre) dimension resource partitions. In the co-ps mode connections can
only be practically created by resource partitioning of the time
dimension. Note that the key difference between the co-cs and co-ps
mode in the time dimension is one of regular or irregular (respectively)
partitioning of resource. What this essentially means is that labelling
and resource assignment are coupled/fixed processes and always
deterministic in the co-cs mode but not in the co-ps mode. This has
many immediate practical consequences too, eg one can't create mp2p
constructs in the co-cs mode but one can in the co-ps mode.
Aside=> A practical consideration (but not axiomatic to its definition)
is that once created a connection is only consciously moved by (i) a
customer request (most obvious for SVC case), (ii) from failures (eg
prot-sw) or (iii) by premeditated planned works. Counter example: If
we add nodes/links to a cl-ps mode network than traffic can move at will
under the routing rules of the IGP, but this is not true (or should not
be true) in co-ps and co-cs mode networks....nothing intrinsically wrong
with that, its purely a function of the connection object and how this
must be defined wrt BOTH labelling and resource assignment
considerations. And a key point to grasp in all this is that the 3
network modes are quite different and it is folly to try and treat them
all identically alike.
Now, the above was what I was hinting at in my last mail to Igor wrt to
the point about the binding of CV OAM messages (forward
defect-detection) and BDI OAM messages (backward defect-detection
indication) for fault management. It's quite an important point, and
its why in a client/server relationship for creating topology we require
congruent bidirectional routings of the symmetric atomic p2p connection
building block.
regards, Neil
> -----Original Message-----
> From: owner-ccamp@ops.ietf.org
> [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Drake, John E
> Sent: 06 March 2007 22:24
> To: Dimitri.Papadimitriou@alcatel-lucent.be; Adrian Farrel
> Cc: ccamp@ops.ietf.org
> Subject: RE: What is this fate sharing thing? [Was: Questions
> on draft-takacs-asym-bw-lsp-00.txt]
>
>
> 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
> >
> >
> >
> >
> >
> >
> >
> >
>
>