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

From: [email-masked]
Date: Fri, 2 Mar 2007 08:40:29 +0100

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

hence, better forget about this idea and look at a simple extensions
consisting in linking two uni-directional LSP with an association 
oject

ps: the document includes in many places "marketing-like" statements 
completely - examples

" The limitation of symmetrical resource requirements may pose 
   difficulties for operators to efficiently support the services 
   foreseen for next generation networks."

pls give us a break with all the hype and hubub about "services 
foreseen for next generation networks" 

"Means must be provided by higher 
   layer entities, e.g., the network management system (NMS), to 
   correlate the LSPs not just from RSVP-TE but also from an OAM point 
   of view. "

which OAM ??? never heard someone complaining when using MPLS-BFD
where is the proof point ?

"Additionally, translation functionality may be required to 
   provide operators with a service oriented bidirectional abstraction 
   hiding the complex control plane operation."

could you speak with an IETF language please, this sentence just 
mean nothing

thanks,
-d.

[email-masked]
27/02/2007 21:50
Please respond to internet-drafts
 
        To:     [email-masked]
        cc: 
        Subject:        I-D ACTION:draft-takacs-asym-bw-lsp-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

                 Title                           : GMPLS RSVP-TE extension 
in support of bidirectional LSPs with 
                 Author(s)               : A. Takacs, et al.
                 Filename                : draft-takacs-asym-bw-lsp-00.txt
                 Pages                           : 8
                 Date                            : 2007-2-27
 
   GMPLS provides general connection control functionality supporting 
   different network technologies. This memo specifies a further 
   generalization to support bidirectional LSPs with asymmetric 
   requirements. The extension improves the flexibility of bidirectional 
   LSP establishment and at the same time simplifies the control and 
   management of asymmetric services. 

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-takacs-asym-bw-lsp-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-takacs-asym-bw-lsp-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
                 [email-masked].
In the body type:
                 "FILE /internet-drafts/draft-takacs-asym-bw-lsp-00.txt".
 
NOTE:            The mail server at ietf.org can return the document in
                 MIME-encoded form by using the "mpack" utility.  To use 
this
                 feature, insert the command "ENCODING mime" before the 
"FILE"
                 command.  To decode the response(s), you will need 
"munpack" or
                 a MIME-compliant mail reader.  Different MIME-compliant 
mail readers
                 exhibit different behavior, especially when dealing with
                 "multipart" MIME messages (i.e. documents which have been 
split
                 up into multiple messages), so check your local 
documentation on
                 how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
ftp://[email-masked]/internet-drafts/draft-takacs-asym-bw-lsp-00.txt
_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce

---

From: "Don Fedyk" <[email-masked]>
Date: Fri, 2 Mar 2007 11:44:42 -0500

Hi Dimitri 

Please see inline:
> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> 
> let's go back to basic
> 
> per RFC 3471
> 
> "4. Bidirectional LSPs
> 
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.

> consisting in linking two uni-directional LSP with an association 
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>

---

From: [email-masked]
Date: Fri, 2 Mar 2007 18:06:23 +0100

hi don

"Don Fedyk" <[email-masked]>
02/03/2007 17:44
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, 
<[email-masked]>
        cc: 
        Subject:        RE: I-D ACTION:draft-takacs-asym-bw-lsp-00.txt

Hi Dimitri 

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

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.

Regards,
Don 
<snip>

---

From: "Don Fedyk" <[email-masked]>
Date: Fri, 2 Mar 2007 16:21:35 -0500

Hi Dimitri

See inline [DF]

>hi don
>
>"Don Fedyk" <[email-masked]> 02/03/2007 17:44
> To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, <[email-masked]>
>
>Hi Dimitri 
>
>Please see inline:
>> -----Original Message----- From: [email-masked]
>>    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."
>> 
>> 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. 
>-> 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. 
>
[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>
>
>
>

---

From: [email-masked]
Date: Sat, 3 Mar 2007 00:56:09 +0100

hi don

see inline

[dp] well see below

[dp] step 1: unidir LSP between A-B: Tx ----> Rx 

tspec A->B (Path), flowspec B->A (Resv)

[dp] step 2: sym bidir LSP between A-B: Tx ----> Rx 
                                        Rx <---- Tx

but tspec A->B (Path)    == flowspec A->B (Resv)
and flowspec B->A (Resv) == tspec B->A (Path)

in brief, tspec A->B (Path) acts as is floswpec A->B (Resv)
was sent from A to B (for upstream data path)

[dp] step 3: asymmetric bidir LSP A-B:

w/  tspec A->B (Path)    =/= flowspec A->B (Resv)
and flowspec B->A (Resv) =/= tspec B->A (Path)

therefore, you need

tspec A->B & flowspec A->B (in Path) 

and

flowspec B->A & tspec B->A (in Resv)

[dp] i think i should be more precise WHY this specific req ?
is that specific to Ethernet ? or to PBB-TE probably ;-)

[dp] the issue is threefold 

a) you will see from the above that asym bi-dir LSP do not
call for an upstream tspec

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) 

thanks,
- d.

Regards,
Don

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 3 Mar 2007 00:10:57 -0000

Cutting to the chase (I hope):

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

> 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

> 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

---

From: Igor Bryskin <[email-masked]>
Date: Sat, 3 Mar 2007 05:26:53 -0800 (PST)

Hi,
 
 Provided that we have 1.a - there is a clear requirement for  asymmetrical bidirectional services – I tend to agree with Don on this. 
   
  If implementing a bidirectional service by an association of two reciprocal unidirectional LSPs is so great, then why do we need bi-directional LSPs in the first place? The answer is well recognized:
  a)      the setup is faster;
  b)      the CP state is smaller
  c)      the management is simpler (fate-sharing, recovery, alarm distribution,,,,)
  d)      solution for the opposite direction resource allocation contention problem
  e)      …
   
  That’s why we decided to introduce Upstream Label and support bi-directional LSPs.
  The introduction of Upstream T-SPEC/FLOWSPEC seems to me a natural and relatively inexpensive price for preserving the a),b),c)…..

  Igor 

Adrian 

---------------------------------
TV dinner still cooling?
Check out "Tonight's Picks" on Yahoo! TV.

---

From: [email-masked]
Date: Sat, 3 Mar 2007 17:53:25 +0100

igor

1. treating the LSPs independently is an added value (in terms of 
flexibility), the sole reason for departing in case of bi-directional LSP 
was (look at the discussion on the list in 2000) due to a) keeping 
establishment of data path independent would have led to lambda LSPs with 
different wavelength in up and downstream direction over different paths 
b) improve setup and recovery time 

now, the conditions are totally different, reason why expliciting these is 
de-facto required in addition to the claim "i have a clear requirement 
for" that kind of service

2. at the end, the question is whether you need to have for the underlying 
data paths 

a) a signaled association on each intermediate node 

b) a signaled association at the end-points

c) no signaled association

3. if a) is selected there is no other choice than an upstream flowspec in 
the Path msg and a upstream tspec in the Resv message

the reason is ultra-clear, if you use an upstream tspec as this draft 
proposes it is equivalent to the dest. (source Rx) telling to the source 
(Dest Tx) what are traffic characteristics of the data flow that the 
"sender" (= Dest Tx) will generate hence just telling what the latter 
knows; hence resulting in requiring to send back over the Resv the adapted 
upstream tspec, and a third exchange in the form of an upstream flowspec 
(ok totally irrealistic and completely opposed to the simple and 
inexpensive method you are looking at)

note that any method creates for providing a) creates a real 
interoperability issue, reason why even a (correct) proposal along the 
lines of upstream flowspec in the Path msg and a upstream tspec in the 
Resv message did not progress (see e.g. draft-dube, that was partially 
going into the correct direction)

-d.

Igor Bryskin <[email-masked]>
03/03/2007 14:26
 
        To:     Adrian Farrel <[email-masked]>, Don Fedyk 
<[email-masked]>, Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     [email-masked]
        Subject:        Re: I-D ACTION:draft-takacs-asym-bw-lsp-00.txt

Hi,

Provided that we have 1.a - there is a clear requirement for  asymmetrical 
bidirectional services – I tend to agree with Don on this. 
 
If implementing a bidirectional service by an association of two 
reciprocal unidirectional LSPs is so great, then why do we need 
bi-directional LSPs in the first place? The answer is well recognized:
a)      the setup is faster;
b)      the CP state is smaller
c)      the management is simpler (fate-sharing, recovery, alarm 
distribution,,,,)
d)      solution for the opposite direction resource allocation contention 
problem
e)      …
 
That’s why we decided to introduce Upstream Label and support 
bi-directional LSPs.
The introduction of Upstream T-SPEC/FLOWSPEC seems to me a natural and 
relatively inexpensive price for preserving the a),b),c)…..

Igor 
Adrian Farrel <[email-masked]> wrote:

> 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

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 

 TV dinner still cooling?

---

From: Igor Bryskin <[email-masked]>
Date: Sat, 3 Mar 2007 12:03:15 -0800 (PST)

Dimitri,

Suppose a link carrying a bi-directional service in one direction fails and you need to perform e2e recovery. Suppose the service is mapped on 2 unidirectional reciprocal LSPs. If you re-route just one LSP you will loose fate sharing. If you need to re-route both LSPs, than recovery of a bi-directional LSP will be twice faster than recovery of two unidirectional LSPs.
If fate sharing is a "MUST", I say with reciprocal LSPs  you don't have extra flexibility , but you do have extra complexity.

Igor

[email-masked] wrote: igor

-d.

Igor Bryskin 
03/03/2007 14:26
 
        To:     Adrian Farrel , Don Fedyk 
, Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     [email-masked]
        Subject:        Re: I-D ACTION:draft-takacs-asym-bw-lsp-00.txt

Hi,

Provided that we have 1.a - there is a clear requirement for  asymmetrical 
bidirectional services &#1090;&#1040;&#1059; I tend to agree with Don on this. 
 
e)      &#1090;&#1040;&#1078;
 
That&#1090;&#1040;&#1065;s why we decided to introduce Upstream Label and support 
bi-directional LSPs.
The introduction of Upstream T-SPEC/FLOWSPEC seems to me a natural and 
relatively inexpensive price for preserving the a),b),c)&#1090;&#1040;&#1078;..

Igor 
Adrian Farrel  wrote:

Adrian 

 TV dinner still cooling?

---------------------------------
Need a quick answer? Get one in minutes from people who know. Ask your question on Yahoo! Answers.

---

From: [email-masked]
Date: Sat, 3 Mar 2007 22:52:14 +0100

igor

"If you need to re-route both LSPs, than recovery of a bi-directional LSP 
will be twice faster than recovery of two unidirectional LSPs."

that is clearly not the case. there is no sequential operation(s) in case 
of unidirectional LSPs, recovery time diff depends on the failure location 
and notif. propagation, at best they would be equal, otherwise you may 
have a slight difference (in favor of bi-dir LSP, but remember that the 
major reasoning behind bi-dir LSP has always been to facilitate 
timeslot/lambda selection).

the real problem of asym LSPs. compared with sym bidir LSP where it is 
assumed that bw control is sym. (which is, at the end, the only reason for 
making this case sensible) the result here with asym bw LSP is that the 
control of both direction/data paths is concentrated at the head-end, in 
case the tail-end desires increasing the upstream bw.

-d.

03/03/2007 21:03
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     Adrian Farrel <[email-masked]>, [email-masked], 
Don Fedyk <[email-masked]>
        Subject:        Re: I-D ACTION:draft-takacs-asym-bw-lsp-00.txt

Dimitri,

Suppose a link carrying a bi-directional service in one direction fails 
and you need to perform e2e recovery. Suppose the service is mapped on 2 
unidirectional reciprocal LSPs. If you re-route just one LSP you will 
loose fate sharing. If you need to re-route both LSPs, than recovery of a 
bi-directional LSP will be twice faster than recovery of two 
unidirectional LSPs.
If fate sharing is a "MUST", I say with reciprocal LSPs  you don't have 
extra flexibility , but you do have extra complexity.

Igor

[email-masked] wrote:
igor

data paths 

-d.

Igor Bryskin 
03/03/2007 14:26

Hi,

Provided that we have 1.a - there is a clear requirement for asymmetrical 
bidirectional services тАУ I tend to agree with Don on this. 

e) тАж

ThatтАЩs why we decided to introduce Upstream Label and support 
bi-directional LSPs.
The introduction of Upstream T-SPEC/FLOWSPEC seems to me a natural and 
relatively inexpensive price for preserving the a),b),c)тАж..

Igor 
Adrian Farrel wrote:

Adrian 

TV dinner still cooling?

 Need a quick answer? Get one in minutes from people who know. Ask your 
question on Yahoo! Answers.

---

From: Igor Bryskin <[email-masked]>
Date: Sat, 3 Mar 2007 14:43:54 -0800 (PST)

Dimitri, see in-line

that is clearly not the case. there is no sequential operation(s) in case 
of unidirectional LSPs, recovery time diff depends on the failure location 
and notif. propagation, at best they would be equal, otherwise you may 
have a slight difference (in favor of bi-dir LSP, 

IB>> True, if you don't need to preserve the fate -sharing, if you do you need to correleate the path selection for both LSPs.

but remember that the 

IB>> am not sure that I got the rest of your message.

Igor

-d.

Igor Bryskin 
03/03/2007 21:03
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     Adrian Farrel , [email-masked], 
Don Fedyk 
        Subject:        Re: I-D ACTION:draft-takacs-asym-bw-lsp-00.txt

Dimitri,

Igor

data paths 

-d.

Igor Bryskin 
03/03/2007 14:26

Hi,

Provided that we have 1.a - there is a clear requirement for asymmetrical 
bidirectional services Ôáõ I tend to agree with Don on this. 

e) ÔáÖ

ThatÔáýs why we decided to introduce Upstream Label and support 
bi-directional LSPs.
The introduction of Upstream T-SPEC/FLOWSPEC seems to me a natural and 
relatively inexpensive price for preserving the a),b),c)ÔáÖ..

Igor 
Adrian Farrel wrote:

Adrian 

TV dinner still cooling?

 
---------------------------------
Don't get soaked.  Take a quick peak at the forecast 
 with theYahoo! Search weather shortcut.

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 3 Mar 2007 23:35:20 -0000

> the Path msg and a upstream tspec in the Resv message

That *does* raise an interesting question. Namely, does the ingress know the 
bandwidth to request? If it does then there is no need for a TSpec on the 
Resv as the reservation has already been made commensurate with the FlowSpec 
on the Path.

If the ingress does *not* know and needs to see a TSpec from the egress, 
then we need another Path exchange after the Resv in order to make the 
actual reservations. In that case it really would be a mess and not worth 
trying to shoe-horn into a bidirectional LSP format.

A

---

From: [email-masked]
Date: Sun, 4 Mar 2007 01:25:43 +0100

"Adrian Farrel" <[email-masked]>
04/03/2007 00:35
Please respond to "Adrian Farrel"
 
        To:     "Igor Bryskin" <[email-masked]>, Dimitri 
PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     <[email-masked]>, "Don Fedyk" <[email-masked]>
        Subject:        Re: I-D ACTION:draft-takacs-asym-bw-lsp-00.txt

> the Path msg and a upstream tspec in the Resv message

That *does* raise an interesting question. Namely, does the ingress know 
the 
bandwidth to request? If it does then there is no need for a TSpec on the 
Resv as the reservation has already been made commensurate with the 
FlowSpec 
on the Path.

-> if you do that you prevent the ingress-side to never adapt resource
reservation to the traffic parameters of the egress (in fact, it would
boil down to "single-sided" asymmetry forever)

-> hence, initially you must satisfy at least condition where flowspec 
=< tspec, nevertheless, after the tspec may "increase" and therefore 
the flowspec may be adapted 

-> this is what i said also to don, the case where initially the ingress 
is completely unaware of what it can reserve is impossible without major
protocol modifications

-> my partial conclusion, is that a workable asym bw lsp doesn't elevate
the need for the general case, and only provides apparent facilitation in
a corner case, whereas a technique making use of association object would
prevent all this protocol massaging, keep full backward compatibility, and
provide full flexibility

A

---

From: Igor Bryskin <[email-masked]>
Date: Sun, 4 Mar 2007 05:55:30 -0800 (PST)

Adrian and Dimitri,

When a GMPLS tunnel is setup, it is setup for a reason.  Let's say, management plane requests a tunnel ingress node to setup a tunnel. The request may not (and normally does not) contain an explicit path, but it definitely contains all bandwidth parameters, because the tunnel was requested, as I siad,  for a particular reason  (application, SLA, etc.). Also, how else you can ensure the fate sharing other than computing a path on the ingress node taking in consideration the bandwidth requirements for both directions?
So, yes, I'd say that it is safe to assume that ingress node always knows about bandiwidth in both directions.

I'd say even more. We have a strict requirement from our customers that actively deploy our GMPLS CP, that a communication between management and control plane should always hapen at one (ingress) node.

Igor

PS It would be interesting to hear from providers on this topic.

[email-masked] wrote: "Adrian Farrel" 
04/03/2007 00:35
Please respond to "Adrian Farrel"
 
        To:     "Igor Bryskin" , Dimitri 
PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     , "Don Fedyk" 
        Subject:        Re: I-D ACTION:draft-takacs-asym-bw-lsp-00.txt

A 

---------------------------------
It's here! Your new message!
Get new email alerts with the free Yahoo! Toolbar.

---

From: "Attila Takacs \(IJ/ETH\)" <[email-masked]>
Date: Sun, 4 Mar 2007 23:06:05 +0100

Hi all,

Please see inline.
Regards,
Attila 

> [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: Saturday, March 03, 2007 1:11 AM
> To: Don Fedyk; [email-masked]
> Cc: [email-masked]
> 1.a. Do we have a clear requirement for an asymmetrical 
> bidirectional service?
> 

It would be good to have operators reflect on these. My two cents are
that asymmetrical bidirectional services are apparently there. In
regards to LSPs carrying highly aggregated traffic in backbones
asymmetry might be of less importance, however LSPs getting further out
to the edges of the network may have really asymmetrical loads.

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

I agree with Don and Igor on this. Having a TSpec there and ending up
with "single-sided" LSP control would be not a problem in practice.

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

Agree. The target of the ID was to have a discussion on the topic and
see if there is interest to add a new *option* (3.a) for asymmetric
bidirectional LSP establishment.

---

From: "Diego Caviglia \(GA/ERI\)" <[email-masked]>
Date: Mon, 5 Mar 2007 09:11:48 +0100

From my experience I can quote everything Igor said.  GMPLS tunnel
establishment is, AFAIK, always driven by the NMS/OSS that (quoting Neil
Harrison here) is the King.

So I think that in the real world the Ingress node knows the upstream
and downstream bandwidth of the GMPLS Tunnel is going to set-up.

Moreover if I'll use two uni-directional LSPs in order to set-up an LSP
with asymmetrical bandwidth requirement I can force the path of the two
LSPs to be the same?  Do I have to use the RRO of the first one as ERO
for the second one?  Or I suppose to use a fully defined ERO for both
the two LSP?  In this case I do suppose that the ERO has been calculated
by the NMS?

Regards

Diego

________________________________

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Igor Bryskin
Sent: domenica 4 marzo 2007 14.56
To: [email-masked]; Adrian Farrel
Cc: [email-masked]; Don Fedyk; Igor Bryskin
Subject: Re: I-D ACTION:draft-takacs-asym-bw-lsp-00.txt

Adrian and Dimitri,

When a GMPLS tunnel is setup, it is setup for a reason.  Let's say,
management plane requests a tunnel ingress node to setup a tunnel. The
request may not (and normally does not) contain an explicit path, but it
definitely contains all bandwidth parameters, because the tunnel was
requested, as I siad,  for a particular reason  (application, SLA,
etc.). Also, how else you can ensure the fate sharing other than
computing a path on the ingress node taking in consideration the
bandwidth requirements for both directions?
So, yes, I'd say that it is safe to assume that ingress node always
knows about bandiwidth in both directions.

I'd say even more. We have a strict requirement from our customers that
actively deploy our GMPLS CP, that a communication between management
and control plane should always hapen at one (ingress) node.

Igor

"Adrian Farrel" 
04/03/2007 00:35

> 3. if a) is selected there is no other choice than an upstream
flowspec 
in

the 
bandwidth to request? If it does then there is no need for a TSpec on
the 
Resv as the reservation has already been made commensurate with the 
FlowSpec 
on the Path.

then we need another Path exchange after the Resv in order to make the 
actual reservations. In that case it really would be a mess and not
worth 
trying to shoe-horn into a bidirectional LSP format.

-> my partial conclusion, is that a workable asym bw lsp doesn't elevate
the need for the general case, and only provides apparent facilitation
in
a corner case, whereas a technique making use of association object
would
prevent all this protocol massaging, keep full backward compatibility,
and
provide full flexibility

A 

________________________________

It's here! Your new message!
Get new email alerts
<http://us.rd.yahoo.com/evt=49938/*http:/tools.search.yahoo.com/toolbar/
features/mail/>  with the free Yahoo! Toolbar.

---

From: "Don Fedyk" <[email-masked]>
Date: Mon, 5 Mar 2007 10:19:29 -0500

Hi All
 
Igor has captured my understanding as well that the situation we are
concerned with is a GMPLS control plane being deployed to map the
capabilities from a management plane. 
 
In terms of this requirement I see GMPLS control of optical/tdm and
GMPLS control of Ethernet being just as you say: The ingress node knows
the bandwidth for both directions. 
  
Regards,
Don 

	From: Igor Bryskin [mailto:[email-masked]] 
	Sent: Sunday, March 04, 2007 8:56 AM
	To: [email-masked]; Adrian Farrel
	Cc: [email-masked]; Fedyk, Don (BL60:1A00); Igor Bryskin
	Subject: Re: I-D ACTION:draft-takacs-asym-bw-lsp-00.txt

	Adrian and Dimitri,
	
	When a GMPLS tunnel is setup, it is setup for a reason.  Let's
say, management plane requests a tunnel ingress node to setup a tunnel.
The request may not (and normally does not) contain an explicit path,
but it definitely contains all bandwidth parameters, because the tunnel
was requested, as I siad,  for a particular reason  (application, SLA,
etc.). Also, how else you can ensure the fate sharing other than
computing a path on the ingress node taking in consideration the
bandwidth requirements for both directions?
	So, yes, I'd say that it is safe to assume that ingress node
always knows about bandiwidth in both directions.
	
	I'd say even more. We have a strict requirement from our
customers that actively deploy our GMPLS CP, that a communication
between management and control plane should always hapen at one
(ingress) node.
	
	Igor

		"Adrian Farrel" 
		04/03/2007 00:35

		> 3. if a) is selected there is no other choice than an
upstream flowspec 
		in
		> the Path msg and a upstream tspec in the Resv message
		
		That *does* raise an interesting question. Namely, does
the ingress know 
		the 
		bandwidth to request? If it does then there is no need
for a TSpec on the 
		Resv as the reservation has already been made
commensurate with the 
		FlowSpec 
		on the Path.
		
		-> if you do that you prevent the ingress-side to never
adapt resource
		reservation to the traffic parameters of the egress (in
fact, it would
		boil down to "single-sided" asymmetry forever)
		
		-> hence, initially you must satisfy at least condition
where flowspec 
		=< tspec, nevertheless, after the tspec may "increase"
and therefore 
		the flowspec may be adapted 
		
		If the ingress does *not* know and needs to see a TSpec
from the egress, 
		then we need another Path exchange after the Resv in
order to make the 
		actual reservations. In that case it really would be a
mess and not worth 
		trying to shoe-horn into a bidirectional LSP format.
		
		-> this is what i said also to don, the case where
initially the ingress 
		is completely unaware of what it can reserve is
impossible without major
		protocol modifications
		
		-> my partial conclusion, is that a workable asym bw lsp
doesn't elevate
		the need for the general case, and only provides
apparent facilitation in
		a corner case, whereas a technique making use of
association object would
		prevent all this protocol massaging, keep full backward
compatibility, and
		provide full flexibility

		A 

	

	It's here! Your new message!
	Get new email alerts
<http://us.rd.yahoo.com/evt=49938/*http://tools.search.yahoo.com/toolbar
/features/mail/>  with the free Yahoo! Toolbar.
<http://us.rd.yahoo.com/evt=49938/*http://tools.search.yahoo.com/toolbar
/features/mail/>