Hi Vijay
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