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

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

Hello Stephen,

It is not because two things are not totally the same that they cannot
interoperate:

- there is one unique way to request an SDH signal.
- there is one unique way to request a SONET signal.
- the two are interoperable while keeping the distinction.

You are claiming that SONET is totally a subset of SDH from all point of
views. In that case why do you care of SONET ? Let's completely forget SONET
and let's use only SDH. Is this correct ? Could you clarify the distinction
between SONET and SDH for the monitoring, etc ?

Implementations of SONET and SDH are not identical today and they will stay
different for a while. We need a solution that takes this into
consideration. The current GMPLS draft takes into consideration the two
point of views:

a. SONET is totally included in SDH: great ! Just request an SDH signal. It
works and there is no issue.
b. one still has a SONET version which is not fully in SDH: just request a
SONET signal if not able to request an SDH signal.

Why do you want absolutely to make case b impossible ?

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 don't
understand that you cannot accept other point of views if there are not
preventing you to do what you want.

Kind regards,

Eric



-----Original Message-----
From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com]
Sent: Monday, February 25, 2002 7:52 PM
To: Kireeti Kompella
Cc: Wijnen, Bert (Bert); Mannie, Eric; 'mvissers@lucent.com';
'vijay@umbc.edu'; ccamp-wg; 'sob@harvard.edu'
Subject: Re: SONET/SDH label agreement for IETF, ITU-T and OIF


Kireeti:
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)

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. There are not a few signals in SONET which are not in SDH.
There is ONE, and it is one with no defined mappings. It is VT3, NOT
VC-3. I repeat my earlier email since you seem to have missed it
the first time. You even asked that someone should correct you if
you were wrong. Please read also the additional remarks and conclusions
below the included email.
Steve Trowbridge wrote:
> Kireeti,
> The one outlyer is VT3 (3 Megabits). VC-3 is an extremely popular
> rate in both SONET and SDH. I exchanged an email with Deborah Brungard
> (T1X1.5 chair) on this one and I take the liberty of sharing her response:
> 
> 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 basically, there are no mappings or equipment functions for this rate,
> and as far as we know no network equipment or networks supporting it.
> Deborah suggests that if we were ever to define such mappings, that this
> would be proposed for addition to G.707 and hence be part of SDH.
> 
> I think our agreement had been to use the SDH label for all signals that
> had the same multiplex structure in SONET and SDH. In Salt Lake City, we
thought
> that this was everything except VT3. Given that VT3 seems not to be a
"real"
> signal at this point and will likely be added to SDH if it ever becomes
> real, does our agreement then become that we use SDH labels for
everything?
> 
> Regards,
> Steve
> 
> Kireeti Kompella wrote:
> > 
> > Hi Deborah,
> > 
> > > I previously made the
> > > comments to merge the (1) SDH and SONET values as one value
> > 
> > There was a meeting among Steve Trowbridge, Maarten Vissers,
> > Eric Mannie, Dimitri Papadimitriou, the CCAMP ADs and chairs on
> > several issues, among them this one.  The upshot was that whenever
> > possible, the SDH label should be used, with the encoding type
> > set to SDH (i.e., G.707); however, there are signals that have
> > no SDH equivalent (if I remember right, VC-3 -- someone correct
> > me!), so we will keep SONET labels and encoding types around
> > for that case and for legacy equipment.
> > 
> > The revised SONET/SDH document will contain the exact wording.
> > I will also be sending a reply to the ITU communication stating
> > the agreement we came to.
> > 
> > Kireeti.

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.

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.
Regards,
Steve

Kireeti Kompella wrote:
snip
> 
> Here's what I thought we had agreed:
> 
> 1) There is a document in the ITU that defines a *single* standard that
>    encompasses both SONET and SDH -- almost.  There are a few signals
>    that are in SONET but not in SDH; it was believed that the only such
>    signal was VC-3.  Also, there are "legacy" implementations of SONET
>    that do not match the ITU document.
> 
> 2) Thus, it was agreed (to my recollection) that both the SONET and
>    SDH label formats will be retained, with wording that says that
>    whenever possible, the SDH equivalent should be used.  This covers
>    both the cases of SONET signals that don't have SDH equivalents,
>    and legacy equipment.
> 
> It is *not* the IETF's intention to promote an artificial separation
> between SONET and SDH.  Nor is it the intent to promote as standard
> work that is now "pre-standard".
> 
> However, it *is* the IETF's goal to be able to set up paths across
> SONET and SDH networks, and to be pragmatic about this.  This was
> the spirit in which an agreement was forged -- or so I thought.  In
> retrospect, it would have been wise to go one step further and
> decide the actual words.
> 
> So, here we are again, arguing over this.  Let's follow the AD's
> suggestion and look for consensus in the WG.
> 
> 1) Do you think we should have just a single set of traffic parameters
>    and label values for SDH, and none for SONET?
> or
> 2) Do you think we should have one for SONET and one for SDH, with
>    the proviso that, if an SDH equivalent is available, one SHOULD
>    use the SDH equivalent?
> or
> 3) Do you think we should have one for SONET and one for SDH, with
>    the proviso that, if an SDH equivalent is available, one MUST
>    use the SDH equivalent?
> 
> (in the above, SHOULD and MUST are to be interpreted as in RFC 2119.)
> 
> PLEASE respond with just (1), (2) or (3), and avoid long diatribes!
> 
> Feedback is welcome from *all* those interested in the CCAMP WG.
> Also, what we are looking for is rough consensus, not votes.
> 
> Thanks,
> Kireeti.