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

["Adrian Farrel" <adrian@olddog.co.uk>]

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