Re: I-D ACTION:draft-takacs-asym-bw-lsp-00.txt

[Dimitri.Papadimitriou@alcatel-lucent.be]

igor

"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, but remember that the 
major reasoning behind bi-dir LSP has always been to facilitate 
timeslot/lambda selection).

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.

-d.






Igor Bryskin <i_bryskin@yahoo.com>
03/03/2007 21:03
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     Adrian Farrel <adrian@olddog.co.uk>, ccamp@ops.ietf.org, 
Don Fedyk <dwfedyk@nortel.com>
        Subject:        Re: I-D ACTION:draft-takacs-asym-bw-lsp-00.txt


Dimitri,

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 
unidirectional LSPs.
If fate sharing is a "MUST", I say with reciprocal LSPs  you don't have 
extra flexibility , but you do have extra complexity.

Igor

Dimitri.Papadimitriou@alcatel-lucent.be wrote:
igor


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 

data paths 

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)

-d.





Igor Bryskin 
03/03/2007 14:26

To: Adrian Farrel , Don Fedyk 
, Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
cc: ccamp@ops.ietf.org
Subject: Re: I-D ACTION:draft-takacs-asym-bw-lsp-00.txt


Hi,

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 
distribution,,,,)
d) solution for the opposite direction resource allocation contention 
problem
e) тАж

ThatтАЩs why we decided to introduce Upstream Label and support 
bi-directional LSPs.
The introduction of Upstream T-SPEC/FLOWSPEC seems to me a natural and 
relatively inexpensive price for preserving the a),b),c)тАж..


Igor 
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 
service?

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 
of 
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 
signaling 
exchanges. The data plane presence can be established identically by 3.a. 
or 
3.b.

Adrian 




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.