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