[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: SONET/SDH label agreement for IETF, ITU-T and OIF
- To: "Mannie, Eric" <Eric.Mannie@ebone.com>, "Stephen Trowbridge" <firstname.lastname@example.org>, "Kireeti Kompella" <email@example.com>
- Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF
- From: "Brungard, Deborah A, ALASO" <firstname.lastname@example.org>
- Date: Mon, 25 Feb 2002 18:39:39 -0500
- Cc: "Wijnen, Bert (Bert)" <email@example.com>, <firstname.lastname@example.org>, <email@example.com>, "ccamp-wg" <firstname.lastname@example.org>, <email@example.com>
My answer is (1).
A reminder - this outcome also impacts gen-signaling draft where the sdh and sonet labels are defined. I think it would help with a lot of the misunderstanding if choice (1) was clarified to say ITU-T SDH. We are not discussing ETSI SDH, as was used for the comparison in the Framework for GMPLS control draft. Which is my take for choosing (1).
And one other reminder - my comment on the pdh labels always got lost in the sdh-sonet mail explosion. I would like a response. My comment was simply to say that if one has different labels for ANSI PDH and ETSI PDH, we will need another label for ITU-T PDH. Or we could simply have one label, ITU-T PDH, as it includes both sets and does not require a third label plus a gateway function.
The remaining part of this mail contains a response to Eric's mail below:
My understanding was that the labels were an indication of structure. In all the gmpls documents, the label indicates switching structure. On structure, the ITU-T is a superset of ANSI SONET-specific, ETSI SDH-specific, and an overlapping set of common structures. Are you saying there are interoperability problems with the structures of the overlapping set? As ITU-T G.707 and ANSI T1.105 are identical for the overlapping set, are these problems with non-standard equipment? Wouldn't these be in the draft on non-standard aspects?
As all the gmpls documents have referred to the label as indicating structure, I think it will mis-represent if we now try to say they also provide other interworking functions e.g. monitoring. We know the use of two labels for sdh and sonet will not provide interoperability of byte use (e.g. monitoring). As you also are aware of the many variations, I'm sure you agree with me - we can only wish it was so simple.
The OIF UNI was another incompatibility cited with using the ITU-T SDH labels instead of distinct SDH and SONET labels. The OIF UNI is a UNI. It is not a network interface (internal or between networks). The UNI only addresses the link connection to the network (which in the framework for control draft is referred to as a virtual label, only addressing the local link). The requirements of a network - especially global network(s) - are very different. I would hope we are not pre-locked into an implementation which has a very different defined scope. Otherwise why are we having this discussion?
From: Mannie, Eric [mailto:Eric.Mannie@ebone.com]
Sent: Monday, February 25, 2002 2:54 PM
To: 'Stephen Trowbridge'; Kireeti Kompella
Cc: Wijnen, Bert (Bert); 'firstname.lastname@example.org'; 'email@example.com';
Subject: RE: SONET/SDH label agreement for IETF, ITU-T and OIF
It is not because two things are not totally the same that they cannot
- 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.
From: Stephen Trowbridge [mailto:firstname.lastname@example.org]
Sent: Monday, February 25, 2002 7:52 PM
To: Kireeti Kompella
Cc: Wijnen, Bert (Bert); Mannie, Eric; 'email@example.com';
'firstname.lastname@example.org'; ccamp-wg; 'email@example.com'
Subject: Re: SONET/SDH label agreement for IETF, ITU-T and OIF
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:
> 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
> that this was everything except VT3. Given that VT3 seems not to be a
> 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
> 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
Kireeti Kompella wrote:
> 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?
> 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?
> 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.