[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,
I
think the point is on flexibility. If bandwidth is available with fine
granularity one can leverage this in many cases. To add a new example:
central office - branch office connectivity, in this scenario it
seems to be likely to have the same recovery...etc requirements but
different bw needs for up/down streams.
Regarding "fate sharing", as you specified, it depends on how one defines
"a strong use case"...one may use diversely routed LSPs as well to provide
bidirectional connection for, e.g., the above service, but with co routed LSPs
issues may become simpler (like management, CP states, OAM,...).
Regards,
Attila
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:
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.
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.