RE: Please Clarify Doubts regarding RGT & RNC

["Bernstein, Greg" <GregB@ciena.com>]

Hi Hai, the non-concatenated grouping in the RGT was not meant to be a
general bundling mechanism (such a mechanism was discussed and rejected in
San Diego), but rather since we already were dealing with multiple
concatenation types (standard, arbitrary, virtual) and an RNC field, the
folks that have SONET/SDH customers that deal in private lines such as DS3s,
T1s and E1s tend to set these up in batches and hence this is the prime use
of this grouping.
Hope this clarifies.

Greg B.
***********************************
Dr. Greg M. Bernstein
Senior Scientist, Ciena Corporation 

-----Original Message-----
From: Hai Vodinh [mailto:HVoDinh@turinnetworks.com]
Sent: Tuesday, March 20, 2001 7:14 PM
To: 'Zhi-Wei Lin'; Vishal Sharma
Cc: ccamp@ops.ietf.org
Subject: RE: Please Clarify Doubts regarding RGT & RNC


I tend to agree with Zhi-Wei that when you need to set up multiple
connections these should be done separately (except perhaps in the virtual
concatenated case) to keep the signaling protocol simple.

I'm following the discussion and still don't have a clear idea why both
virtual concatenation and bundling RGT are needed.  What is the difference
between the two types?

Here is another question: let's say I have a STS-1-4v SPE already set up,
now I need to add 2 more STS-1 to make it a STS-1-6v SPE, how do I signal to
the network that the additional 2 STS-1s need to be co-routed with the other
4 STS-1s?

Thanks,
Hai

-----Original Message-----
From: Zhi-Wei Lin [mailto:zwlin@lucent.com]
Sent: Tuesday, March 20, 2001 12:17 PM
To: Vishal Sharma
Cc: 'manoj juneja'; ccamp@ops.ietf.org
Subject: Re: Please Clarify Doubts regarding RGT & RNC


Hi Vishal,



> > 3 STS-3: ??? How would you signal this? Not supported?
> 
> What do you wish to signal here? Three groups of STS-3 each?
> What does it mean? The STS-3 is a bundle, and you wish to signal
> a bundle of bundles?
> 
> If that is so, and unless I am missing something, I think you'd have
> to signal them separately.
> 
> BTW, I wasn't immediately able to see how this would be signaled
> even using the codepoints proposed in
> draft-lin-ccamp-ipo-common-label-request-01.txt.
> 

I don't understand how that is a bundle. STS-3 as defined in the T1.105
is the entire signal. So then if you can signal multiple STS-1s, my
question was why is this not supported for STS-3 or other STS-X.

Right, draft-lin assumes that when you need to set up multiple
connections, these are done separately. Adding the capability for
multiple connection set-ups as part of the signaling mechanism is not
really necessary. Remember that the signaling mechanism is not the GUI
to the customer. The GUI that the customer sees can provide that
feature. The interface from GUI to the signaling can be a batch function
that sets up the multiple connections. This simplifies the signaling
protocol, allows "bundling" of different connection types set-up at once
(e.g., if customer wants to set up  3 STS-3c, 4 STS-7v, and 2 STS-48c at
once) via a batch process, and does not complicate the protocol from
having to handle this issue.

Some of the points mentioned by Ewart in the OIF discussion was: when
multiple connections are handled at once, what are the characteristics
of these connections? Do they all terminate at the same location? Are
they all co-routed or separately routed? How many labels do you return?
If one label is returned, what happens when one connection failed? What
if the multiple connections have different destinations? etc.


> > 1 STS-3c: RNC=3, RGT=2 (contiguous standard) or 3 (contiguous
> > arbitrary)
> > 1 STS-4c: RNC=4, RGT=3 (contiguous arbitrary)
> >
> > ==> 3 STS-3c: ??? How would you signal this? Not supported?
> 
> Again, as things stand today, you'd have to signal this separately.
> 
> First, is there a requirement to signal these this way? Assuming
> there is, is there a proposal that allows for that?
> 

I wasn't sure whether there is requirement or not. I was extending your
example with what was offered currently. My view was that it seems that
some capabilities are available to certain signal types and not to other
signal types. We probably need to extend or clarify the text, or adopt a
different position in terms of what should and should not be provided by
the signaling protocol, and leave "added features" to separate functions
(the batch process I mentioned above).


> I cannot see how draft-lin-ccamp-ipo-common-label-request-01.txt would
> do it either, since the RNC has been absorbed into the signal type
> in that case, and not all cases are enumerated.
> 

See above for comment.

> > 1 STS-7v: RNC=7, RGT=1 (virtual)
> >
> > ==> 7 STS-7v: ??? How would you signal this? Not supported?
> 
> Same as the two above.
> 

See above (sorry, too many "aboves") ;-)

Zhi