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

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

Hi Dimitri

See inline [DF]

>hi don
>
>"Don Fedyk" <dwfedyk@nortel.com> 02/03/2007 17:44
> To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, <ccamp@ops.ietf.org>
>
>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)
[DF]I don't see this a big issue in the case of GMPLS. 
>
>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)
[DF] my understanding is it is already there. It seems odd
to me to follow the reasoning that says it is OK for
symmetric BW to have the object but deny it for asymmetric
BW. 
> 
>> 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 ? 
[DF] Specifically GMPLS control of Ethernet.  

>
>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)
>
[DF] RFC 3945 Section 7.10.  Bi-directional LSP: makes all the
arguments for a single LSP setup. Besides RSVP-TE is
extensible as well so the additional object will not show up
unless it is GMPLS and unless it involves a technology that
supports asymmetrical bandwidth. I don't see the issue.  

Regards,
Don 


>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>
>
>
>