RE: What is this fate sharing thing? [Was: Questions on draft-takacs-asym-bw-lsp-00.txt]

["Don Fedyk" <dwfedyk@nortel.com>]

Hi Dimitri 

Inline [DF]

> -----Original Message-----
> From: Dimitri.Papadimitriou@alcatel-lucent.be 
> 
> adrian, all
> 
> the point is not whether "We need asymmetrical bidirectional services"
> but "Do we have a clear requirement for asymmetrical 
> bidirectional LSPs?" 
[DF]  I agree. 

> 
> when i look at some of the examples that have been cited, it would 
> surprise me that we would provision an LSP per micro-flow across the 

> network (being Ethernet or whatever packet technology), even 
> more, GMPLS 
> is mostly used as an edge-to-edge technology in most cases, 
> GMPLS capable 
> devices do not even interact with the sources of traffic some where 
> mentioning in their examples
[DF] Two points. The GMPLS for Ethernet Provider Backbone Bridges-TE is
hardly a micro flow but you are correct that at high bandwidth levels it
would likely be symmetric BW. 

> 
> i am also reading that some Ethernet equipment are 
> introducing several 
> specific (data plane) constraints, indeed, but the control 
> plane is not 
> going to elevate those, in part. these constraints are 
> independent whether 
> one has unidirectional LSP, or asym bandwidth LSP 
> provisioning capability 
> at control plane level (adrian pointed this out numerous 
> times but this is 
> one of the cornerstone of the whole discussion)

[DF] Sorry I'm missing your point here. 
> 
> hence, the point since so far, is that they are no convincing 
> argument in 
> favor of an asymmetric LSP bandwidth provisioning WITHIN a single 
> signaling exchange, indeed, most arguments are boiling down to 
> hypothetical control plane efficiency that can be ensured by 
> other means 
> if we consider the restricting conditions where the proposed approach 
> would be workable 

[DF] I don't agree on the efficiency point.  By any measure of
efficiency a single RSVP-TE session that handles both directions and
possibly different bandwidths is better that 2 that do 1/2 the job each.
If bandwidth is the same, in each direction today we don't need an
extension.  Igor gave a nice summary.  

BTW I do believe that there will be an association object to correlate
at the very least primary and back-up bi-directional LSP.  I agree an
association object can manage 2 RSVP-TE uni-directional sessions for a
full bi-directional connection, and while there is some merit to not
extending current BW semantics there are also a set of new correlation
rules that have not been implemented. 

So if we enumerate the GMPLS LSP building block possibilities I see: 

Unidirectional LSP with BW (supported today by existing procedures)
- 1 RSVP-TE session 

Symmetric BW bi-directional LSP (supported today by existing procedures)
- 1 RSVP-TE session can be used by existing GMPLS 

Asymmetric BW bi-directional LSP (not yet defined).
- 2 Unidirectional LSPs with BW + an association object need to be used
plus a set of extensions to path correlation 
OR 
- 1 Symmetric BW bi-directional LSP can be used and no BW objects (many
MPLS TE sessions have no real BW in the control plane)
OR
- 1 Symmetric BW bi-directional LSP a bi-directional BW object. 

Regards,
Don 

> 
> -d.
> 
> 
>  
> 
> 
> 
> 
> 
<snip>