Guys,
let me try to summarize what we have said so far:
1
The basic idea behind the ID is based on some facts (I hope
we all agree that are facts J);
1.1 Ethernet services are (likely) bidirectional
with asymmetric bandwidth;
1.2 GMPLS now allows to set-up bi-directional LSP
with symmetrical bandwidth;
1.3 If, with the existing protocols, there is
the need to set-up a bi-directional service with asymmetric bandwidth
requirement (e.g. IpTv) and with upstream and downstream path that follow the
same route we have to signal two different LSPs using the RRO of the first one
as strict ERO for the second one. If we also want to bind the two LSPs in
order to identify them as part of the same service we can use the ASSOCIATON
obj (modified I suppose)
1.4 Likely (I would say very likely) the NMS
that requests the LSP(s) set-up knows in advance the bandwidth needed in the
two directions. So we are in a different situation w.r.t. the original RSVP
situation. We have all the information we need to set-up the LSP at the Path
processing
Now if
all of we are happy with point 1.3 then we have finished. If someone think
that is better to have the possibility to set-up and identify a bidirectional
service with a single LSP then the ID have reason to exists at least for
discussion J.
IMHO
having the possibility to set-up the LSP at the path processing speed up the
service establishment and this is particularly useful in case of LSP rerouting
in case of failure. In fact if the service is made of the two LSP what could
happens is the first one can be set-up and the second one fails during
signaling this means that first one have to be deleted and two LSP path
recomputed and re-signaled.
Best
Regards
Diego
From:
owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Attila Takacs (IJ/ETH)
Sent: martedì 6 marzo 2007 11.35
To: Pandian, Vijay; Don Fedyk
Cc: ccamp@ops.ietf.org
Subject: RE: Questions on
draft-takacs-asym-bw-lsp-00.txt
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.
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
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?
-----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
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.