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

[Dimitri.Papadimitriou@alcatel-lucent.be]

hi don




"Don Fedyk" <dwfedyk@nortel.com>
02/03/2007 17:44
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, 
<ccamp@ops.ietf.org>
        cc: 
        Subject:        RE: I-D ACTION:draft-takacs-asym-bw-lsp-00.txt


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. 

-> well, the problem is that in bi-dir. symmetric LSPs, there is no 
"upstream flowspec" because redundant with the tspec values, hence,
symmetry allows for simplification

This draft proposes that that single TSPEC can be split into an upstream
and downstream component. 

-> that is impossible, there is no upstream and dowstream component to
   the tspec (the source is not the Tx for both components)

The FLOWSPEC is proabably redundant in this case.

-> simple, the problem is that we're going to have an object that does
   not make any sense in Path msg (or any other "name" we will find for
   it)
 
> 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. 

-> btw, where this requirement come from ? 

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? 

-> the question is more basic, there is no reason, to contortionate 
the protocol to find a solution here (full flexibility without any
backward compatibility issue)

thanks,
-d.

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>