Re: GMPLS signaling documents updated per last calls

[Dimitri Papadimitriou <dimitri.papadimitriou@alcatel.be>]

Maarten,

I will add some hints here to the one already pointed out by Eric.
See in-line...

"Mannie, Eric" wrote:
> 
> 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 main question is not the control but the transmission plane. And i
would like to strengthen that if (even today) or in future convergence
is achieved the current proposal doesn't preclude it at all. In the 
meantime your Maarten (or ITU since you maintain another confusion here
for me) doesn't provide backward comptability.
 
> 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 ?

Again your restricted interpretation.
 
> > 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 ?

Probably this one of the key question here.
 
> > 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 ?

The agreement "we have a satisfactory solution but not the one proposed
by Maarten/Stephen/etc." so this discussion for me is closed ... but i 
think that some people would like to see THEIR OWN solution into the 
document the reason is clear for me introduce their own view on the 
protocol architecture for distributed control plane restricting us to 
use the complexities they have introduced in their own model... sorry 
but this was not the aim of the last IETF meeting discussion.
 
> > 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.

I would like also to remember here that our target is to achieve an
efficient and interoperable running code, we don't target state of
the art transmission system modelling "theory" since in practice state
of the art models are rarely applicable in the real world.

... these remarks translates the problem of people working only from 
the "theoretical" viewpoint without any pragmatic view on the reality.
 
> 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.

Eric the above remark is clear from the study made on the difference b/w
the OH at the Section/RS, Line/MS and Path. I think that we were
probably
on the right track when having used the versioning of the SDH/Sonet
rec's
but we took the decision at that time to introduce this profiling into
the
routing ("the discovery of the interface capabilities").
 
> 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.

For all, if you take a look at the complexity introduced by this model,
call/discovery then connection i more than 100% sure that we are on the 
right track here BY KEEPING THINGS SIMPLE.
 
> >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.

Strange to see such a remark coming from your side... see below.
 
> > 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.

... and after Maarten you friendly tell us that we introduce
confusion...
is it not the case when you rediscuss many times the same issue for
which
a decision has been taken and endorsed one or two weeks before ?
 
> 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.
begin:vcard 
n:Dimitri;Papadimitriou Dimitri
tel;home:+32 2 3434361
tel;work:+32 3 2408491
x-mozilla-html:FALSE
url:http://www.alcatel.com
org:Alcatel Bell;IPO NA (NSG) - Antwerpen 
version:2.1
email;internet:dimitri.papadimitriou@alcatel.be
title:Optical Networking R&S - Senior Engineer
adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM
fn:Papadimitriou Dimitri
end:vcard