RE: Simple solution to terminate the discussion about SONET versus SDH

["Mannie, Eric" <Eric.Mannie@ebone.com>]

Stephen,

>> In an earlier email of Eric's, I see also:
>> If we give you a solution that does what you want to do, plus in addition
>> what some other people want to do, why are you complaining ????
>I am complaining because a document that simply lists all of the different
>things that different people want to do is not a standard - it is just a
>catelogue of everyone's proprietary choices.

I understood that proprietary means for you the stuff that *you* don't like
:-)

>To have a standard, you
>make a choice and write it down so you can interoperate.

you are probably not aware of what profiles or implementation agreements are
(you don't have the same for SDH). GMPLS is full of choices (options). Which
signaling are you going to use: RSVP-TE or CR-LDP ? Which routing protocol
are you going to choose ? The IETF RFCs are full of choices (options). You
never want to believe me when I told you that GMPLS is a toolbox. Pick the
tools you need, forget the others. If you disagree with this approach it is
your right, but it is a common approach taken by many standardization
bodies. Your freedom stops where my freedom is starting.

Kind regards,

Eric

-----Original Message-----
From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com]
Sent: Tuesday, February 26, 2002 6:29 PM
To: Dimitri.Papadimitriou@alcatel.be
Cc: Mannie, Eric; 'Heiles Juergen'; 'mvissers@lucent.com'; Wijnen, Bert
(Bert); 'vijay@umbc.edu'; ccamp-wg; 'sob@harvard.edu'; 'Kireeti
Kompella'
Subject: Re: Simple solution to terminate the discussion about SONET
versus SDH


Dimitri,
Perhaps we were not precise enough in spoken language in reaching
our "agreement" in SLC. We discussed that we would use the SDH coding
in the cases where we had identical multiplex structures between
SONET and SDH. I came away thinking that this translated to "shall",
and obviously some others thought it translated to "should". For
those of us who understood "shall", we then move to the followup
discussion that SONET is a subset of SDH and therefore there are no
cases where a SONET multiplex structure exists that is not also
in SDH, so we use only SDH codings (leaving aside the VT3 case
which is not real, and if it were, would be added to G.707).

By "pragmatic evolutionary scenario", it seems that you are proposing
to leave in place dual codings that impede interworking to preserve
or protect pre-standard implementations. I believe that the purpose
of a standard is to allow interworking, not to protect pre-standard
implementations.

In an earlier email of Eric's, I see also:
> If we give you a solution that does what you want to do, plus in addition
> what some other people want to do, why are you complaining ????
I am complaining because a document that simply lists all of the different
things that different people want to do is not a standard - it is just a
catelogue of everyone's proprietary choices. To have a standard, you
make a choice and write it down so you can interoperate.
Regards,
Steve

Dimitri.Papadimitriou@alcatel.be wrote:
> 
> That's probably the issue here, i see lot of response with respect
> to the last status that has been achieved over years at bodies like
> the T1X1/ITU-T (and ETSI) to improve interoperability between Sonet
> and SDH; the option (2) doesn't at all preclude this, it give us the
> capability to have a more pragmatic evolutionary scenario. That's
> also the paradox, i see people coming from the transmission world
> having an idealistic view on transmission networks (and control plane)
> while they know it will take years to achieve full interop; this while
> others have a real pragmatic view on what short/mid-term needs are/
> will be.
> 
> The option 2) takes into account current install base (with GMPLS
> soft update) and future needs - we don't even have to discuss in
> detail here the specifics btw Sonet and SDH overhead and corr.
> processing - if the "SHOULD" must have to be clarified then let's
> go for it.
> 
> rgds,
> - dimitri.
> 
> "Mannie, Eric" wrote:
> >
> > Stephen,
> >
> > Of course SDH and SONET are interoperable and can be interconnected. You
buy
> > a gateway and it is done.
> >
> > I spoke about the fact that in the control plane we should know if a
signal
> > is using the SONET "profile" or the SDH "profile". Otherwise you cannot
> > achieve automatically what you described hereafter.
> >
> > If at one end you generate a J1 on 64 bytes with the SONET profile you
need
> > to interpret it at the other end as specified in the SONET "profile",
not
> > using the SDH "profile" on 16 byte format. You cannot assume that all
> > existing SONET boxes (speaking GMPLS or not) will know that the other
end is
> > SDH. This is just one example. I think that this is now clear for
everybody.
> >
> > Also due to a lot of legacy boxes at the network periphery, SS
conversion is
> > still needed somewhere. These legacy boxes will not speak GMPLS, but
they
> > will be the source of paths that will fly over GMPLS clouds and that
could
> > even be terminated on GMPLS nodes. When signaling the LSP (SNC)
initiated on
> > a SONET cloud and terminated in an SDH could you need to go through a SS
> > conversion. So you need to make a distinction between the SDH and SONET
> > "profiles".
> >
> > Having a the same LSP Encoding Type for SDH/SONET is not general enough
and
> > will not cover the cases where some cloud ignore that the other end is
SDH.
> > Having a different LSP encoding type for SONET and SDH is just
identifying
> > the profile to use. It doesn't prevent you to request an SDH signal from
any
> > box to any box, if supported. It doesn't prevent any interoperability.
> >
> > By the way we could may be add to your list other possible differences
in
> > J0, K1/K2, E1 (?), F1 (?), E2, maybe S1 and M1 ?, etc. Just taking a
list
> > from a tutorial without checking in details.
> >
> > Kind regards,
> >
> > Eric
> >
> > -----Original Message-----
> > From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com]
> > Sent: Tuesday, February 26, 2002 4:22 PM
> > To: Mannie, Eric
> > Cc: 'Heiles Juergen'; 'mvissers@lucent.com'; Wijnen, Bert (Bert);
> > 'vijay@umbc.edu'; ccamp-wg; 'sob@harvard.edu'; 'Kireeti Kompella'
> > Subject: Re: Simple solution to terminate the discussion about SONET
> > versus SDH
> >
> > Eric,
> > I don't think you ask quite the right question.
> > The right question is:
> > Can all frame structures which are common to SONET and SDH be
> > interconnected,
> > and do they interoperate? This is what we care about from the viewpoint
of
> > establishing switched connections.
> > The answer to this is YES.
> >
> > Are they fully identical from all points of view? As Juergen says, this
is
> > the
> > tricky question, as the answer of "No" might mislead some into thinking
that
> > these signals cannot be interconnected between SONET and SDH. This is
not
> > the case.
> >
> > For those who care, some of the key differences are as follows. Note
that
> > these
> > do NOT affect the ability to interconnect these signals (although
sometimes
> > there
> > are rules about HOW to interconnect them).
> >
> > SS bits - In the past, this was an issue in the high order pointers. SDH
> > sent
> > and expected "10", for SONET these bits were unspecified. This problem
was
> > corrected
> > a few years ago by requiring that ALL equipment send "10" and ignore the
> > incoming
> > bits. Note that even prior to aligning the standards, a great deal of
the
> > older
> > equipment followed this strategy as VC-4s and STS-3cs were
interconnected
> > long
> > before the standards alignment.
> >
> > Trace identifier - For J1, within SONET, a 64 byte format is normally
used.
> > For SDH,
> > a 16 byte format is normally used. SONET specifies that in the case that
the
> > far end
> > is SDH, a 16 byte format should be used to allow interworking. For J2,
this
> > is normally
> > used in SDH and not normally in SONET. Interworking is acheived by
having
> > the SDH end
> > ignore the incoming trace identifier (a required capability in the
> > standards).
> >
> > RDI - SONET uses some extra bits that are reserved in SDH to further
> > classify far end
> > alarms (called ENHANCED RDI). This provides no obstacle to interworking:
The
> > SONET
> > side will not be able to provide a more detailed classification of SDH
end
> > alarms (it
> > does know there is a far end alarm). The SDH end ignores the extra bits.
The
> > Enhanced
> > RDI feature only operates if both ends are SONET.
> >
> > BIP - The coding for BIP is identical. The way degrade is detected is
> > different.
> > SONET generally uses a Poisson algorithm to declare degrade and SDH
normally
> > uses
> > a bursty error detection algorithm. This provides no obstacle to
> > interconnect - the
> > criteria for declaring dDEG is just slightly different. Also, SONET
provides
> > an
> > EXC alarm for BER > 10^-3 which does not appear in SDH. This also does
not
> > prevent
> > interconnect - you just have an alarm which can be declared at one end
and
> > not the
> > other.
> >
> > These are the major differences (besides the fact that SONET and SDH
tend to
> > have
> > different names for identical things- This is just a US/Europe language
> > issue).
> > Regards,
> > Steve
> >
> > "Mannie, Eric" wrote:
> > >
> > > Dear All,
> > >
> > > There is an easy way to stop definitively this discussion based on
> > technical
> > > facts:
> > >
> > > Stephen, Juergen and Maarten, please tell us: today, are the frame
> > > structures and all the bytes in the SDH and SONET overhead completely
> > > identical, used and interpreted in the same way, is the monitoring
exactly
> > > the same ? In particular, if I provision and operate an SDH
circuit/LSP is
> > > this fully identical to a SONET circuit/LSP from *all* point of views
?
> > >
> > > PLEASE ANSWER BY YES OR NO ONLY. Other explanations are not needed at
this
> > > stage.
> > >
> > > If the answer is yes: SONET is totally identical to SDH.
> > > If the answer is no: SONET is not the same as SDH.
> > >
> > > I think that without that answer we cannot take any *technical*
decision
> > on
> > > this mailing list and at the IETF.
> > >
> > > Thanks to answer.
> > >
> > > Kind regards,
> > >
> > > Eric
> > >
> > > ps: feel free to forward this e-mail to any ITU-T mailing list if a
> > > confirmation is needed.
> 
> --
> Papadimitriou Dimitri
> E-mail : dimitri.papadimitriou@alcatel.be
> Website: http://www.rc.bel.alcatel.be/~papadimd/index.html
> Address: Alcatel - Optical NA, Fr. Wellesplein, 1
>          B-2018 Antwerpen, Belgium
> Phone:   Work: +32 3 2408491 - Home: +32 2 3434361