Re: GMPLS signaling documents updated per last calls

[Maarten Vissers <mvissers@lucent.com>]

Eric,

It is not the intention to leave the choice of LSP encoding type and SU label
structure to the vendor. This would give immediate interworking problems.

VC-11/VT1.5, VC-12/VT-2, VC-2/VT-6, VC-3/STS-1, VC-4/STS-3c, VC-4-4c/STS-12c,
VC-4-16c/STS-48c, VC-4-64c/STS-192c and VC-4-256c/STS-768c must all have LSP
encoding type "SDH". Also STS-1/STM-0 upto STM-256/STS-768 must have the LSP
encoding type "SDH".

VC-3/STS-1, VC-4/STS-3c, VC-4-4c/STS-12c, VC-4-16c/STS-48c, VC-4-64c/STS-192c
and VC-4-256c/STS-768c must all have the same SDH-based "SU" structure. 

Looking at the label text in section 3 of the sonet-sdh document, I find it very
confusing to read that SONET doesn't use the "U" field. As we indicated before
there is no STS type signal that isn't having an SDH equivalent; i.e. there are
no specific higher order SONET signals left. It is therefore much better to take
out the SONET text for the SU label part altogether. Otherwise we will get a lot
of confusion in the marketplace.

Also the examples with STS-1 (examples 3 to 5 in secton 3) must use the label
with U in the range 2 to 4; the STS-1 is equivalent to the VC-3 in SDH and must
thus use the "SDH" SU format.

-------

All,

With the clarification on VT-3 given by Deborah, I would request to consider a
further simplification of the GMPLS standard: delete the LSP encoding type
"SONET" and rename the LSP encoding type "SDH" into "SDH/SONET". Then there
would be no ambiguity left at all.

Regards,

Maarten


"Mannie, Eric" wrote:
> 
> Hi Jonathan,
> 
> > Why SHOULD and not MUST?  This ambiguity is likely to create
> interoperability problems in the future...
> 
> To leave to the manufacturer and to the user the right to decide if he/she
> wants to signal an LSP as either SDH or SONET. There is no interoperability
> problem at all since you use EITHER SDH OR SONET. If you decide to request
> an SDH signal with what do you want to have interoperability issue at this
> stage ? The sentence means indeed "one should better use SDH than SONET" !
> Once you decided, there is no issue.
> 
> > I'm curious what sort of backward compatability is necessary, as a
> "standard" doesn't exist currently that this needs to be backward
> compatible with...
> 
> Backward compatibility with the OIF UNI 1.0 Implementation Agreement, with
> the implementations that could not care of SDH, with implementations that
> still do a distinction between SONET and SDH for some reasons, with the
> implementations that could still use the VT3 (DS1C) (I don't have
> confirmation that nobody is using it today, and this is not the goal of this
> draft to state what is obsolete or not in SONET), etc.
> 
> Anyway, there is no issue, the SONET label format is not used until SONET is
> explicitly requested as such. This is not a primary feature of the draft,
> but a *secondary feature*, for SONET lovers. Otherwise, SDH is used for
> everything, consequently you don't care of the SONET label, you skip it in
> the draft, you ignore it, you don't implement it and you just use a full SDH
> implementation.
> 
> I think that the solution is quite simple: if the SONET signal is indeed an
> SDH signal, why do you bother with SONET ? Just ask for an SDH signal,
> that's all.
> 
> By the way, since according to some folks SONET is just a subset of SDH, why
> do we care about SONET in these documents ? Why don't we simply remove all
> references to SONET ?
> 
> Is there somebody on this mailing list that cares about SONET ? If yes, why
> ? Who is still manufacturing SONET boxes ? Why is that not called SDH ?
> 
> Kind regards,
> 
> Eric
> 
> -----Original Message-----
> From: Jonathan Sadler [mailto:jonathan.sadler@tellabs.com]
> Sent: Tuesday, December 18, 2001 9:57 PM
> To: Mannie, Eric
> Cc: 'Stephen Trowbridge'; Kireeti Kompella; ccamp@ops.ietf.org;
> dbrungard@att.com; lberger@movaz.com
> Subject: Re: GMPLS signaling documents updated per last calls
> 
> Eric -
> 
> Comments inline...
> 
> Jonathan Sadler
> 
> "Mannie, Eric" wrote:
> > "A SONET signal which has an identical SDH signal SHOULD be requested
> using
> > the same traffic parameters as for the equivalent SDH signal, and will
> > consequently use the SDH label."
> 
> Why SHOULD and not MUST?  This ambiguity is likely to create
> interoperability problems in the future...
> 
> > We spend with Maarten a lot of time to write that sentence (not easy to
> > write).
> >
> > Maybe that it should be better written:
> >
> > "A SONET signal which has an identical SDH signal SHOULD be requested as
> an
> > SDH signal using the same traffic parameters as for the equivalent SDH
> > signal, and will consequently use the SDH label."
> 
> Again, "SHOULD" needs to be replaced with "MUST"...
> 
> > This doesn't mean that the SONET signal format disappear (simply not used
> in
> > that case), for backward compatibility we need to keep it.
> 
> I'm curious what sort of backward compatability is necessary, as a
> "standard" doesn't exist currently that this needs to be backward
> compatible with...
> 
> > Kind regards,
> >
> > Eric
> >
> > -----Original Message-----
> > From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com]
> > Sent: Tuesday, December 18, 2001 7:46 PM
> > To: Kireeti Kompella
> > Cc: ccamp@ops.ietf.org; dbrungard@att.com; lberger@movaz.com;
> > bwijnen@lucent.com; sob@harvard.edu
> > Subject: Re: GMPLS signaling documents updated per last calls
> >
> > 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.
begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:mvissers@lucent.com
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard