RE: Proposed text for the concatenation

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

If the goal is interoperability,  it seems like we are getting very
concerned with things that don't matter to that goal.  I'd like to have the
signaling take in all the cases we've discussed, and where there are areas
that the existing standards don't cover (or may not want to cover) we should
define what we mean precisely, state that it is non-standard.
As Lyndon Ong pointed out if multiple vendors don't interoperate with this
feature it will be dropped from the internet standard.
As someone already pointed out, if a customer is willing to pay for a
feature we will supply it.  I'm not sure why we wouldn't want to be able to
interoperate with that feature and for the purpose here we need to describe
what it is in a signaling protocol. Regardless of its current status as a
standard or industry practice.

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

-----Original Message-----
From: Mannie, Eric [mailto:Eric.Mannie@ebone.com]
Sent: Tuesday, May 22, 2001 3:39 AM
To: 'Maarten Vissers'
Cc: ccamp@ops.ietf.org; ip-optical@lists.bell-labs.com
Subject: RE: Proposed text for the concatenation


Re-hello Maarten,

>I have been asking for this AUG-X addition.....
>AUG-X/STSG-X, TUG-X/VTG are not defined as signal types in SDH/SONET
>standards at all. The STSG-X has been made a signal type by my company
>some years ago to support the requirements of some specific customers.

Whaoum, you implemented a non-standardized feature and you re-defined
SDH/SONET in your equipment without the permission of ITU-T :-)

I think that this feature make a lot of sense, you are not the only one that
requested it. In a similar way, other folks requested TUG-X/VTG and this
complements very well your initial request. Moreover, these signal types are
of paramount importance for GMPLS operations since they allow to open a
forwarding adjacency (i.e. an SDH/SONET circuit for which you don't specify
the content) that can be later on sub-structured in whatever you like
(following the SDH/SONET rules of course).

By the way, I don't understand why you said that you need a standard for
AUG-X/STSG-X, TUG-X/VTG...

THERE IS ABSOLUTELY NO NEW STANDARD REQUIRED FOR THAT !

It does not change ANYTHING to SDH/SONET in the data/forwarding plane. It
stays 100% PURE SDH/SONET as in the standards. It is purely a signaling
feature. In addition, even the terminology (AUG-X) is defined in the
standards.

So the only issue that I see is that you don't want to have it because you
can control it by a control plane (whatever is the control plane ???).

>AUG-X/STSG-X, TUG-X/VTG are not defined as signal types in SDH/SONET
>standards at all.

"Signal type" is not a G.707 vocabulary, we used that vocabulary for GMPLS
signaling. Even VC-4's, VC-3's, etc are not defined as a signal type. So do
you want to say that we cannot neither open a VC-4 circuit because G.707 did
not define the GMPLS concept of signal type ? That doesn't make any sense !

Moreover, AUG-X, TUG-2 and TUG-3 ARE DEFINED in G.707 of course (that's part
of the fundamental specification).

>....I don't want to have
>my requested feature treated any different than any other feature that I
>have been argueing about (arbitrary concatenation, semi-transparent
>STM-N).

Are we playing a game here ???

>As this AUG-X feature is beyond current standards (in this case
>G.783), it should be first addressed by Q.9/15 and then by G.ason/GMPLS
>series of control plane specifications.

Great, the own ITU-T functional description is not aligned to its own
protocol ! So it means that SDH does not work ! Seriously, who cares ?
Protocols are implemented not functional descriptions that helps to
understand protocols. I am sure that G.783 will be updated very soon to
reflect SDH.

Sorry I am lost, what is the goal of all your e-mails ? What do you want to
achieve ?

Rgds,

Eric


-----Original Message-----
From: Maarten Vissers [mailto:mvissers@lucent.com]
Sent: Monday, May 21, 2001 4:28 PM
To: Mannie, Eric
Cc: ccamp@ops.ietf.org; ip-optical@lists.bell-labs.com
Subject: Re: Proposed text for the concatenation


Eric,

I am serious. (See also my reply to Greg.)

You wrote:
> Note that GMPLS doesn't do something strange about AUG-X/STSG-X,
TUG-X/VTG,
> they are defined in the standards, it is just a code type, like VC-4 or
> STM-1. By the way, AUG-X in GMPLS was asked by your own colleagues.

I have been asking for this AUG-X addition, with the assumption that I
would write a contribution to get G.783 extended with an additional
MSn/Sn_A function supporting this AUG-X feature... You find this once
more reflected in my email to Greg this morning.

AUG-X/STSG-X, TUG-X/VTG are not defined as signal types in SDH/SONET
standards at all. The STSG-X has been made a signal type by my company
some years ago to support the requirements of some specific customers.
It's proprietary so far.

But given the result of the discussions last week, I don't want to have
my requested feature treated any different than any other feature that I
have been argueing about (arbitrary concatenation, semi-transparent
STM-N). As this AUG-X feature is beyond current standards (in this case
G.783), it should be first addressed by Q.9/15 and then by G.ason/GMPLS
series of control plane specifications.
Up to that moment in time, it should be a vendor specific extension of
G.ason/GMPLS.

Regards,

Maarten