RE: [IP-Optical] Re: Proposed text for the concatenation

[Paul Bonenfant <pbonenfant@photuris.com>]

Maarten,

Does support for provisioning a pre/non-standard feature
necessarily imply a re-definition of SONET/SDH?  As far as 
I can tell the authors (and I note that you are an author,
as are a few other familiar names from my ITU and T1X1 days!)
went to at least some lengths to explicitly dispel this notion. 

Philosophical discussions notwithstanding, carriers are asking 
for (i.e., will PURCHASE), and vendors from ASIC manufacturers 
to systems providers are building, what amounts to "non"-standard, 
(or perhaps more appropriately "pre"-standard) implementations of 
SONET/SDH in current and emerging equipment. Ignore this and the 
G.ason/GMPLS specs for SONET/SDH will be on the fast track to 
irrelevance. 

Why not just acknowledge that not every aspect of provisioning in 
the spec is "standard" (and note where this is the case), and, as 
Dmitri suggests, work the ITU/T1X1 SONET/SDH spec enhancements in 
parallel.  Then, if ITU or T1X1 rejects any of said enhancements, 
relegate their signaling to vendor proprietary extensions...this
is the converse of your proposal, but IMO will result in a much
more attractive first version of the GMPLS SONET/SDH draft.

Regards, 

Paul

-----Original Message-----
From: Dimitri Papadimitriou [mailto:dimitri.papadimitriou@alcatel.be]
Sent: Monday, May 21, 2001 1:02 PM
To: Maarten Vissers
Cc: Mannie, Eric; ccamp@ops.ietf.org; ip-optical@lists.bell-labs.com
Subject: Re: [IP-Optical] Re: Proposed text for the concatenation


Maarten,

>From my side, i don't see any drawback or problem to collaborate
in order to extend G.783. Since the work can be done in parallel,
without any impact on GMPLS signalling, i don't see where the 
problem is with the today version of the SDH/Sonet GMPLS document.
I think that Eric summarized very well the current situation.

Kind regards,
- Dimitri.

Maarten Vissers wrote:
> 
> 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