[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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