RE: [IP-Optical] concatenation extensions in sonet/sdh

[Bala Rajagopalan <BRaja@tellium.com>]

Folks,

Without getting into the merits of arbit concat,
the suggestion that the GMPLS document be explicit about
the "standard" (ITU) versus "pre" or "non-standard" 
features controlled seems reasonable. Afterall,
when you name the doc "GMPLS for SONET/SDH", the
natural expectation is that you refer to what people
commonly understand as "SONET/SDH". In any case,
a precise description of the new features 
and a notation that these are not
currently "standard"  isn't a big deal to do. 
On the other hand, not doing so just breeds confusion.

Regards,

Bala Rajagopalan
Tellium, Inc.
2 Crescent Place
P.O. Box 901
Oceanport, NJ 07757-0901
Tel: (732) 923-4237
Fax: (732) 923-9804
Email: braja@tellium.com 

> -----Original Message-----
> From: Mak, L (Leen) [mailto:lmak@lucent.com]
> Sent: Friday, May 18, 2001 5:42 AM
> To: 'Zhi-Wei Lin'; Paul Bonenfant
> Cc: 'Bernstein, Greg'; 'Steve West'; 'Stephen Trowbridge';
> ccamp@ops.ietf.org; ip-optical@lists.bell-labs.com; t1x1.5; 
> q11/15; Mak,
> L (Leen)
> Subject: RE: [IP-Optical] concatenation extensions in sonet/sdh
> 
> 
> I think Zhi brings us back to the question which started
> this debate in the first place.
> I would support Zhi's option 4).
> 
> That is, in the IETF doc(s), make a clear distinction between
> the stuff supporting currently standardised SONET/SDH
> transport capabilities and the stuff aimed at possible future 
> extensions. The latter could be in an informational Annex 
> or alike, and once ITU and/or T1 standardise a new 
> transport capability, its related control stuff can easily be 
> moved from the Annex to the body of the RFC.
> 
> We should avoid blurring the roles of the various standards 
> bodies. This is not in the interest of the operators nor in 
> the interest of the vendors, because spreading subjects 
> over more bodies will only increase the risk of 
> inconsistencies, misunderstandings etc, etc.
> 
> So ITU-T and T1X1 should remain the bodies where 
> SONET/SDH transport capabilities are being proposed,
> discussed, and standardised.
> The IETF should remain the body where the GMPLS
> capabilities, required to control those transport capabilities
> are standardised. 
> Their relation should be: "the transport capability gets
> the control capability it needs", and not the other way
> around. 
> 
> 
> Leen Mak.
> 
> 
> 
> > -----Original Message-----
> > From: Zhi-Wei Lin [mailto:zwlin@lucent.com]
> > Sent: Friday, May 18, 2001 1:46
> >[...]
> > As for transparency and the rest, right. So as you said, the 
> > question we
> > should ask ourselves is:
> > 
> > 1) Should we add extensions to GMPLS for capabilities not 
> standardized
> > 2) Should we pre-empt standards and add capabilities that 
> are not yet
> > standardized
> > 3) If 2) is yes, should we add capabilities that we "think" will be
> > standardized. What about capabilities where we have no opinion or we
> > think will not be standardized (folks, bring out your crystal ball!)
> > 4) Should we stick strictly with standards-compliant 
> capabilities and
> > include extensions to allow ease of extending the 
> signalling mechanism
> > (Deborah's point). Add these in the future once it is standardized.
> > 
> >[..]
> > Zhi
>