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

[Dimitri.Papadimitriou@alcatel-lucent.be]

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 <i_bryskin@yahoo.com>
03/03/2007 14:26
 
        To:     Adrian Farrel <adrian@olddog.co.uk>, Don Fedyk 
<dwfedyk@nortel.com>, 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 <adrian@olddog.co.uk> 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.