RE: GMPLS signaling documents updated per last calls

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

Hello Maarten,

> 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.

Sorry but this comment doesn't make sense. Of course if one implements an
IP-LSR it could not speak SDH ! The vendor has the choice of the type of box
he wants to implement (IP, ethernet, ATM, SDH, SONET, photonic,...). Of
course we leave the choice of the supported LSP encoding types to the
vendors !

The label structure is defined in the draft.

> 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".

No, not necessarily. Why do you want to reject all SONET implementations ?

> 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. 

No, not necessarily. Why do you want to reject all SONET implementations ?

> 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. 

This didn't change since 1 or 2 years.

By the way, I thought that we reached an agreement ?

> 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.

It is not only a matter of the signal type field in the draft, it is also a
matter of how the network is monitored/operated. A SONET signal is not
always 100% compatible with an SDH signal. It depends on the profile used in
SDH and SONET. For sure there are different profiles for SONET and SDH (e.g.
differences in overhead: SS bit, J0, S1, J1, B3, G1, etc). We understood
that there is a join effort between T1 and ITU to reduce these differences,
but you cannot assume that everybody will adapt to/implement the latest
(draft) version of the transport plane standards.

Indeed, I think that we should have much more than just than two LSP
encoding types (SDH and SONET),  but that we should in addition indentify
profiles. Having SDH and SONET is a strict minimum. Making mandatory the use
of one single LSP encoding type for both SONET and SDH is lying to the
people. It will make GMPLS impossible to use in practice.

Anyway, as you said there are different profiles in SDH, and different
profiles in SONET. The difference between SDH and SONET comes from the fact
that they use different profiles (they can also use the same). In the LSP
encoding type, when we use SONET, we mean a different profile than SDH. We
wanted to have more profiles (e.g. SDH1996, etc) identified but you didn't
want.

If I understood, your idea is to have a second signaling protocol doing a
second pass to setup the profile. Having a control plane with several
signaling round trips and different signaling protocols to setup one single
circuit is a complete mistake from my point of view and from my control
plane design experience. Of course since you want to impose this second
signaling pass, you need to impose a single unique LSP encoding type for
both SDH and SONET so that we will be obliged to use another pass to make
the distinction. I think that now everybody can understand what you have in
mind but don't want to explain.

>Otherwise we will get a lot of confusion in the marketplace.

I think that you are creating the confusion by claiming that there is no
difference at all between SDH and SONET.

> 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.

We are back at the beginning of the discussion... for the Xth time ! As
usual.

Rgds,

Eric

-----Original Message-----
From: Maarten Vissers [mailto:mvissers@lucent.com]
Sent: Wednesday, December 19, 2001 9:05 AM
To: Mannie, Eric
Cc: 'jonathan.sadler@tellabs.com'; 'Stephen Trowbridge'; Kireeti
Kompella; ccamp@ops.ietf.org; dbrungard@att.com; lberger@movaz.com
Subject: Re: GMPLS signaling documents updated per last calls


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.