RE: Please Clarify Doubts regarding RGT & RNC

[Hai Vodinh <HVoDinh@turinnetworks.com>]

Neil

The 'create_new->switch_to_new->delete_old' scheme seems to me to be fairly
inefficient mechanism for making small bandwidth change to large pipe.
Think about addimg 3 sts-1s to a sts-1-43v pipe, you would have to first
make a sts-1-46v, switch the client signal over, then delete the original
sts-1-43v.  I do agree that it is a more straight forward way to achieve the
goal, it is probably also simpler to keep track of the sts-1s also.  I think
however if bandwidth modification (to existing pipe) is an important service
then we need a more efficient mechanism. I'm not saying that this would be
easy.

My question to carriers would be: is b/w modification for virtually
concatenated SPE important? in the short term & long term?

-----Original Message-----
From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]
Sent: Thursday, March 22, 2001 1:38 AM
To: Juergen.Heiles@icn.siemens.de; vishal@JasmineNetworks.com;
HVoDinh@turinnetworks.com; zwlin@lucent.com
Cc: ccamp@ops.ietf.org; GregB@ciena.com
Subject: RE: Please Clarify Doubts regarding RGT & RNC


Vishal....you asked (in mail below) for operator input.....perhaps you
missed this item I posted Wed 14/03/2001 13:35 on the thread 'RE: Three
GMPLS related IDs' against this ID from Yangguang Xu
http://www.ietf.org/internet-drafts/draft-xu-ccamp-gmpls-arch-intra-domain-0
0.txt

<prior text snipped NH>
10	In section 5.4.1.5 'actions' on trails are defined.  For a CO
network with fixed BW selection at trail creation time it is very hard to
see what a 'modify' action could be....other than perhaps a change of
restoration priority and/or change of dedicated back-up trail/resource.  If
there is any notion of (working) BW change here (be it a scalar magnitude
change, ie same route, or a vector change, ie new route (with or without a
scalar magnitude change)), it would seem to me that this is really a new
pair of 'create_new->switch_to_new->delete_old' actions.  I note however
that this has been marked as TBD, but I think it would help if it was made
clear that BW changes cannot (IMO) be a single 'modify' action.
<post text snipped NH>

So in essence I agreed with what Juergen is saying.

neil

> -----Original Message-----
> From: Heiles Juergen [mailto:Juergen.Heiles@icn.siemens.de]
> Sent: 22 March 2001 09:07
> To: 'Vishal Sharma'; 'Hai Vodinh'; 'Zhi-Wei Lin'
> Cc: ccamp@ops.ietf.org; Greg Bernstein (E-mail)
> Subject: RE: Please Clarify Doubts regarding RGT & RNC
> 
> 
> Vishal,
> 
> in the circuit switched world he connection has a fixed 
> bandwidth. You cannot change the bandwidth. You have to tear 
> down the connection and set-up a new one with a different 
> bandwidth. For example if you want to change from VC-3 
> (STS-1-SPE) to VC-4 (STS-3c-SPE) the VC-3 connection is 
> released and a VC-4 connection is setup. The route could be 
> different as some equipment migth support VC-3 but not VC-4s 
> or vice versa.
> Virtual concatenation toegether with LCAS provides 
> flexibility in certain steps. However it applies only to the 
> end points as you mentioned. Between the end points you still 
> setup connections with fixed bandwidth.
> 
> Regards
> 
> Juergen
> 
> > -----Original Message-----
> > From:	Vishal Sharma [SMTP:vishal@JasmineNetworks.com]
> > Sent:	Thursday, March 22, 2001 9:36 AM
> > To:	'Hai Vodinh'; 'Zhi-Wei Lin'
> > Cc:	ccamp@ops.ietf.org; Greg Bernstein (E-mail)
> > Subject:	RE: Please Clarify Doubts regarding RGT & RNC
> > 
> > Hai,
> > 
> > Yes, now that you mention it, it probably is an important 
> capability.
> > (Although,
> > I am not sure how soon it needs to be made available.)
> > [Again, any carriers listening on this channel?? "Hello, calling all
> > carriers... we need some service provider input here."]
<snipped to end NH>