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

[Paul Bonenfant <pbonenfant@photuris.com>]

Apologies for the re-send...sent this last message 
from my non-standard account ;)

Paul

-----Original Message-----
From: Randy Bush [mailto:randy@psg.com]
Sent: Friday, May 18, 2001 10:31 AM
To: Paul Bonenfant
Subject: BOUNCE ccamp@ops.ietf.org: Non-member submission from [Paul
Bonenfant <paul@photuris.com>] 


you must post from your subscription address

randy


------- start of forwarded message -------
From: Paul Bonenfant <paul@photuris.com>
To: Zhi-Wei Lin <zwlin@lucent.com>
CC: Paul Bonenfant <pbonenfant@photuris.com>,
 	"'Bernstein, Greg'" <GregB@ciena.com>,
 	'Steve West' <Swest@turinnetworks.com>,
 	'Stephen Trowbridge' <sjtrowbridge@lucent.com>,
 	ccamp@ops.ietf.org, ip-optical@lists.bell-labs.com,
 	"t1x1.5" <t1x15@t1.org>, q11/15 <tsg15q11@itu.int>
Subject: Re: [IP-Optical] concatenation extensions in sonet/sdh

Hi Zhi,

Well, misplaced/disgusting metaphors notwithstanding (my apologies,
must have been the waning hours of a long day!), I think we agree.

This is about what to include, and not to include, in the GMPLS 
signaling spec for SONET/SDH.  This isn't an issue of crystal ball 
gazing, it's an issue of pre- "standard" (transparent service) and 
perhaps even "re-visited"/post-standard (arbitrary concatenation)
commercial implementations. 

Let's not get lost in standards purism -- if full interoperability
were always required, we never would have standardized SONET BLSRs 
and SDH MS/SPRINGs.  Standardize to a level of commonality among
vendors and allow proprietary extensions for differentiation, but
don't preclude commercially implemented features in that vein. If
this is in keeping with your option (4), great.  If not, either we 
need another option, or the utility of the spec will be lessened, 
in my view -- call me a "reformed" standards purist (smile). 

Paul   

Zhi-Wei Lin wrote:
> 
> Hi Paul,
> 
> I'll have to disagree. I thought the discussion thus far have been what
> is arbitrary and what is virtual, its capabilities, how to handle
> support, what actions need to be taken to allow support.
> 
> I don't see that as hurling dung in Greg's direction. If this were the
> case or if some folks interpret it that way, then let me be the first to
> apologize to Greg (sorry!). There was no intention in my part to hurl
> dung (I think that's disgusting, yuk...I'll have to go wash my hands
> just thinking about it ;-)
> 
> 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.
> 
> OK. Now let's hurl some dung in some other direction other than Greg!
> ;-)
> 
> Zhi
> 
> Paul Bonenfant wrote:
> >
> > We seem to be hurling generous amounts of dung
> > in Greg's general direction for proposing that
> > GMPLS handle "non-standard" SONET/SDH features.
> > This begs a question (well, at least one)...
> >
> > Mind you, I've not been _actively_ engaged in
> > the T1X1 & ITU discussions of late, but where,
> > for example, is the the notion of "transparency"
> > defined in T1X1/ITU SONET/SDH specs, c.f. the
> > discussion of various transparency flags in
> > section 2.1 of draft-ietf-ccamp-gmpls-sonet-sdh-00?
> >
> > By the same arguments, should this too be removed
> > from the spec and left to "proprietary" extensions,
> > until such time as the experts have validated its
> > applicability (as opposed to, let's say, the market)?
> >
> > Paul
> >
> > -----Original Message-----
> > From: Bernstein, Greg [mailto:GregB@ciena.com]
> > Sent: Thursday, May 17, 2001 5:58 PM
> > To: 'Steve West'; 'Stephen Trowbridge'
> > Cc: 'Zhi-Wei Lin'; 'Maarten Vissers'; Anup Tirumala; ccamp@ops.ietf.org;
> > chickoo66@yahoo.com; ip-optical@lists.bell-labs.com; t1x1.5; q11/15
> > Subject: RE: [IP-Optical] concatenation extensions in sonet/sdh
> >
> > Why don't we just remove the contiguous arbitrary concatenation from the
> > GMPLS specification  since it's not standard and doesn't offer any value
> > that I can see.  Anything else could be left for peoples proprietary
> > extensions:-)
> >
> > Greg B.
> >         Dr. Greg M. Bernstein, Senior Scientist, Ciena
> >         New phone: (510) 573-2237
> >

------- end of forwarded message -------