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

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

Hi Dimitri 

Please see inline:
> -----Original Message-----
> From: owner-ccamp@ops.ietf.org 
> [mailto:owner-ccamp@ops.ietf.org] On Behalf Of 
> Dimitri.Papadimitriou@alcatel-lucent.be
> 
> let's go back to basic
> 
> per RFC 3471
> 
> "4. Bidirectional LSPs
> 
>    This section defines direct support of bidirectional LSPs.  Support
>    is defined for LSPs that have the same traffic engineering
>    requirements including fate sharing, protection and restoration,
>    LSRs, and resource requirements (e.g., latency and jitter) in each
>    direction."
> 
> what does it mean in practice that Path msg can carry a TSPEC and the 
> Resv a FLOWSPEC, and still allow for establishment of two data paths
> (upstream & downstream)
> 
> [...]
> 
>  "With bidirectional LSPs both the downstream and upstream data paths,
>    i.e., from initiator to terminator and terminator to 
> initiator, they
>    are established using a single set of signaling messages."
> 
> in brief, a single msg exchange for two data paths (upstream 
> & downstream)
> 
> but if you change the initial condition and still be somehow 
> respectful
> of the RSVP operation
> 
> the path msg shall carry an (upstream) FLOWSPEC and (downstream) TSPEC
> and not a downstream TSPEC and a (default) TSPEC, but now you got the 
> real issue of carrying a FLOWSPEC in a Path msg ??? 
Well we have with GMPLS that a Path message with a single TSPEC for both
upstream and downstream and in a Resv message a single FLOWSPEC for both
upstream and downstream is available today. 
This draft proposes that that single TSPEC can be split into an upstream
and downstream component.  The FLOWSPEC is proabably redundant in this
case.

> 
> hence, better forget about this idea and look at a simple extensions
> consisting in linking two uni-directional LSP with an association 
> oject
> 
The requirement is one Path message for a bidirectional path with
asymmetric bandwidth. In GMPLS we already have one Path message for a
path with symmetric bandwidth. The requirement is to signal this all
from the upstream end.  The question is: Do we make simple extensions to
GMPLS signaling or go to uni-directional LSPs and define the procedures
to associate bi-directional labels that have been set up with two
associated sessions?  

While I have not added up the changes to compare the differences it sure
seems like processing an upstream and downs stream TSPEC in a path
message is a smaller delta than defining all the procedures for
associated LSPs. 

Regards,
Don 
<snip>