"If you need to re-route both LSPs, than recovery of a bi-directional LSP
will be twice faster than recovery of two unidirectional LSPs."
that is clearly not the case. there is no sequential operation(s) in case
of unidirectional LSPs, recovery time diff depends on the failure location
and notif. propagation, at best they would be equal, otherwise you may
have a slight difference (in favor of bi-dir LSP,
IB>> True, if you don't need to preserve the fate -sharing, if you do you need to correleate the path selection for both LSPs.
but remember that the
major reasoning behind bi-dir LSP has always been to facilitate
IB>> am not sure that I got the rest of your message.
the real problem of asym LSPs. compared with sym bidir LSP where it is
assumed that bw control is sym. (which is, at the end, the only reason for
making this case sensible) the result here with asym bw LSP is that the
control of both direction/data paths is concentrated at the head-end, in
case the tail-end desires increasing the upstream bw.
To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
cc: Adrian Farrel
Subject: Re: I-D ACTION:draft-takacs-asym-bw-lsp-00.txt
Suppose a link carrying a bi-directional service in one direction fails
and you need to perform e2e recovery. Suppose the service is mapped on 2
unidirectional reciprocal LSPs. If you re-route just one LSP you will
loose fate sharing. If you need to re-route both LSPs, than recovery of a
bi-directional LSP will be twice faster than recovery of two
If fate sharing is a "MUST", I say with reciprocal LSPs you don't have
extra flexibility , but you do have extra complexity.
1. treating the LSPs independently is an added value (in terms of
flexibility), the sole reason for departing in case of bi-directional LSP
was (look at the discussion on the list in 2000) due to a) keeping
establishment of data path independent would have led to lambda LSPs with
different wavelength in up and downstream direction over different paths
b) improve setup and recovery time
now, the conditions are totally different, reason why expliciting these is
de-facto required in addition to the claim "i have a clear requirement
for" that kind of service
2. at the end, the question is whether you need to have for the underlying
a) a signaled association on each intermediate node
b) a signaled association at the end-points
c) no signaled association
3. if a) is selected there is no other choice than an upstream flowspec in
the Path msg and a upstream tspec in the Resv message
the reason is ultra-clear, if you use an upstream tspec as this draft
proposes it is equivalent to the dest. (source Rx) telling to the source
(Dest Tx) what are traffic characteristics of the data flow that the
"sender" (= Dest Tx) will generate hence just telling what the latter
knows; hence resulting in requiring to send back over the Resv the adapted
upstream tspec, and a third exchange in the form of an upstream flowspec
(ok totally irrealistic and completely opposed to the simple and
inexpensive method you are looking at)
note that any method creates for providing a) creates a real
interoperability issue, reason why even a (correct) proposal along the
lines of upstream flowspec in the Path msg and a upstream tspec in the
Resv message did not progress (see e.g. draft-dube, that was partially
going into the correct direction)
To: Adrian Farrel , Don Fedyk
, Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
Subject: Re: I-D ACTION:draft-takacs-asym-bw-lsp-00.txt
Provided that we have 1.a - there is a clear requirement for asymmetrical
bidirectional services Ôáõ I tend to agree with Don on this.
If implementing a bidirectional service by an association of two
reciprocal unidirectional LSPs is so great, then why do we need
bi-directional LSPs in the first place? The answer is well recognized:
a) the setup is faster;
b) the CP state is smaller
c) the management is simpler (fate-sharing, recovery, alarm
d) solution for the opposite direction resource allocation contention
ThatÔáýs why we decided to introduce Upstream Label and support
The introduction of Upstream T-SPEC/FLOWSPEC seems to me a natural and
relatively inexpensive price for preserving the a),b),c)ÔáÖ..
Adrian Farrel wrote:
Cutting to the chase (I hope):
>>-> btw, where this requirement come from ?
> [DF] Specifically GMPLS control of Ethernet.
> [dp] i think i should be more precise WHY this specific req ?
> is that specific to Ethernet ?
1.a. Do we have a clear requirement for an asymmetrical bidirectional
1.b. Do we have a clear requirement for asymmetrical bidirectional LSPs?
(Does 1.b follow from 1.a?)
> [dp] the issue is threefold
> a) you will see from the above that asym bi-dir LSP do not
> call for an upstream tspec
2. If 1.b, what should we use on a Path message to indicate the bandwidth
the forward flow.
2.a. an 'upstream' TSpec
2.b. a FlowSpec
> b) the gain compared to the cost of having a real bi-dir.
> setup is so low that setting unidir LSP is simpler
> c) but there is an operational issue in linking two LSPs
> (asymmetric) together that one could think of associating
> them, we have a very efficient technique for this, that
> does not impact intermediate nodes (ASSOCIATION object)
> and provides for full flexibility (common or diverse spatial
> path for the upstream and downstream flow)
3. Even if 1.b. we can consider:
3.a. A single signaling exchange for both directions
3.b. Two 'associated' signaling exchanges
Personally, I think that the discussion is confused by talking about
"bidirectional LSPs". The issue really seems to revolve around the
exchanges. The data plane presence can be established identically by 3.a.
TV dinner still cooling?
Check out "Tonight's Picks" on Yahoo! TV.
Need a quick answer? Get one in minutes from people who know. Ask your
question on Yahoo! Answers.