[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 Igor
Good points. Comments in
line.
Adrian,
I would define "fate sharing" very simply: it is the
situation when both directions go through the same links at any time: after
setup, protection switchover, recovery, reroute, etc. In control plane the
bidirectional service where opposite directions fate-share we have some nice
by-products:
In
Ethernet Bridging the "fate sharing" object is the to the level of ports
on the bridge relay. Both direction of the path must pass
through the Bridge relay. There may be link aggregation functions below
this. So I would adjust your definition slightly to include same "link
objects".
a) CP states for both
directions could be always combined together with the summary state reduced in
size;
b) the management of both directions can be accomplished using a
single exchange of signaling messages, This holds for initial setup,
protection switchover, recovery, re-route
c) number of RSVP refreshes also
is half as much
My understanding is that we do like the notion of a
symmetrical bidirectional LSP in a packet switched network layer. This
is a (I'd say big) reason why we want to migrate from MPLS to GMPLS, and you.
Adrian, I believe is still a big advocate of such migration. So, we don't mind
an extra complexity (such as UPSTREAM LABEL, UPSTREAM ACCEPTABLE LABEL
SET).
I have just one question to the authors of the draft: do we have
a strong use case for a bidirectional service requiring the fate sharing (as I
defined it above) of both directions and fully symmetrical (recovery
requirements, colors, etc) apart from the bandwidth requirements? If the
answer is yes, than I say I don't mind a copule of extra signaling
objects.
We
have a draft for GMPLS control of Ethernet PBB-TE which is an emerging L2 data
plane. The Ethernet bridge relay function assumes bi-directionality.
Ethernet data plane OAM is built on the bi-directional relay. IMHO
in that context the answer to your question is yes.
In
fact I think the requirement for asymmetrical BW is just related to the fact we
have a packet technology. (MPLS is no different).
The
need for bi-directional fate sharing is from the requirements of the Ethernet
Bridging Relay and our desire to leverage the Relay capabilities (this packet
layer is different).
The
use case cited for this requirement is the distribution of packet Video which
may well be high BW in one direction and relatively small in the other but
even my Internet connection is asymmetric today and I don't use it for video. So
the use case applies to all kinds of of packet transport.
Regards,
Don
Igor
Adrian Farrel
<adrian@olddog.co.uk> wrote:
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
Don't get soaked. Take a
quick peak at the forecast
with theYahoo!
Search weather shortcut.