RE: Proposed text for the concatenation

["Mannie, Eric" <Eric.Mannie@ebone.com>]

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