RE: Please Clarify Doubts regarding RGT & RNC

[Vishal Sharma <vishal@JasmineNetworks.com>]

Neil and Juergen,

I think Hai has already made the point. When I was talking about change
in bandwidth, I was implicitly assuming that Hai was referring to the
virtual concatenation case. (Correct me if I am wrong, but I didn't 
think there was any other situation, proposed in the standards, 
where you could dynamically change the bandwidth of an existing SONET
channel.)
[Although, one might conceive of situations where implementations that
support
arbitrary concatenation might allow for one to increase the bandwidth
of an existing circuit simply by adding more STS-1s to it. For instance,
if one was switching an arbitrarily concatenated STS-5, and wanted to make
it an STS-7 (assuming that the 2 other STS-1s were contiguous with the
5 STS-1s that formed the STS-5 signal), one might be able to do it.]

I understand that if you wanted to setup
a totally different SONET/SDH channel (with a different bandwidth),
you would need to go the "create new->switch_to_new->delete old"
route.

Also, Neil, I did read your earlier email. The reason I did not think that
that comment applied here was because (I thought) the current discussion
was only in the context of virtual concatenation with LCAS, 
since that appears to be the only scheme which allows for the dynamic
addition or deletion of channels to an existing (virtually 
concatenated) connection.

-Vishal

> -----Original Message-----
> From: Hai Vodinh [mailto:HVoDinh@turinnetworks.com]
> Sent: Thursday, March 22, 2001 12:56 PM
> To: ccamp@ops.ietf.org
> Subject: RE: Please Clarify Doubts regarding RGT & RNC
> 
> 
> 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>
>