[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Questions on draft-takacs-asym-bw-lsp-00.txt
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