Re: SONET/SDH label agreement for IETF, ITU-T and OIF

[Kireeti Kompella <kireeti@juniper.net>]

Hi Steve,

On Mon, 25 Feb 2002, Stephen Trowbridge wrote:

> I start with the simple answer and follow with the diatribe - those
> who don't want to read the diatribe can stop after the answer:
> My answer: (1)

Noted.  For you, I'll make an exception and read the diatribe :-)

> Background: I clarified this in an email to you and the list last Dec. 18.
> I am surprised and disappointed that you did not take note of the
> answer.

Sorry!  I did read that, but was confused by a more recent exchange
between Maarten and Eric (irrelevant to this discussion).

> > Deborah Brungard wrote:
> > > The VT3 (3M) structure was defined - but no services (mappings) were ever defined for it. So there are no services/equip
> > > with it. My take was if in the future it was ever defined (doubtful), we would be adding it to g707 also. So then it
> > > would just be part of g707 too.

So, one issue is put to rest: there is no need to define separate
signalling for SONET signals on the basis that SDH doesn't fully
include SONET, as there are no (useful) non-SDH signals.

(An aside, for my own edification: are the overhead bytes for SDH and
SONET defined identically?  Or are they not defined sufficiently for
this to be an issue?)

> To do other than (1) introduces the case that there are two standardized
> codings for the same multiplex structure based on whether one thinks it
> is SONET or SDH. The result is that you are not interoperable in the
> control plane for something that IS interoperable in the transport plane.
> This is NOT the objective of standards.

I agree with you that to do other than (1) introduces 'confusion'.
However, the control plane is *software*.  It is relatively easy to
ensure interoperability in the control plane -- be prepared to
accept both mappings.  It is not so easy to dismiss hardware.

> Further, I am opposed to keeping pre-standard codings in a standards
> track document just because someone has built to the draft. Every
> ID includes the statement: "It is inappropriate to use Internet- Drafts
> as reference material or to cite them other than as "work in progress.""
> Certainly we all do early implementations, but any implementation done
> against an ID must ALWAYS be done with the understanding that this is
> subject to change, and may need revision once the ID is advanced to a
> proposed standard.

I can't fault you here.  This is why I agree with Bert that we leave
this to the WG at large.  If the sense of the WG is that having two
encodings for the same signal is bad (for whatever reason), we'll
have just one.  If the WG thinks that having dual encodings is more
pragmatic with respect to existing hardware, we'll have two.

If there isn't consensus in either direction, we'll go with one
encoding -- that's the right thing to do in principle.

Kireeti.