[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: GMPLS signaling documents updated per last calls
Hi,
it didn't attend the come together at the IETF meeting, put it seems to me that the agreements where reached with different assumptions in the two parties minds.
I hear that the SONET labels was only left to support VT-3 and I hear that they are left for interworking with existing implementations (OIF UNI1.0).
VT-3 is not a reason for me as
- VT-3 is not used in SONET (Deborah may be think about removing it from T1.105!)
- only a definition for the VT-3 label is needed, not for all other SONET signals. Furthermore it can be defined based on the SDH label.
Providing interworking with implementations that are based on draft documents is a little bit strange in my view. The implementers know that these documents are drafts and may change and so they have to change their implementation. Otherwise giving drafts a higher status contradicts all decision and voting processes for the final version as one can always reject changes based on existing implementations. However it seems that is the way the IETF works.
Ok, but in this case it should be clearly mentioned in the document. Furthermore the SONET definitions should be completely separated from the SDH definitions and but into a interworking part. Otherwise with the mixture of SONET and SDH within the text it is only confusing.
Concerning SDH/ITU and SONET/T1 I think it is more a political issue to have still the T1 recommendations with the full description. ETSI makes a reference to G.707 and only mentions which parts of G.707 apply or don't apply (ETS300147).
Regards
Juergen
> -----Original Message-----
> From: Dimitri Papadimitriou [mailto:dimitri.papadimitriou@alcatel.be]
> Sent: Wednesday, December 19, 2001 6:37 PM
> To: Maarten Vissers
> Cc: Mannie, Eric; '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
>
>
> This discussion is going into limbos because once a solution
> is provided and agreed by all parties, afterwards the elements
> having enabled to come up to this decision disappear... for
> instance, VT3 SPE now are not used anymore... were they used
> one week before and just stop now ?
>
> Mor generally, since it is not the job of the CCAMP community to
> verify if the content of ITU/T1X1 specifications are implemented
> in current networks it is for me irrelevant to state as done by
> Stephen that they are not used. How can i verify such assertion ?
>
> At the end of the day i have got the following impression ITU
> T1 people blind the differences they maintain in their own
> documents... Deborah/Stephen sorry but GR.253 specification has
> just been extended to LCAS capabilities so T1X1 and ITU maintains
> their own version (G.707 is also being extended)... in this
> context sorry but we are at a point where people maintains
> artificial discussions for reasons which are very difficult
> to understand ?
>
> Very interesting the following e-mail from Maarten, why do i
> have to keep two terms in order to translate the same entity
> if Sonet is a subset of SDH ?
>
> Cheers,
> - dimitri.
>
> Maarten Vissers wrote:
> >
> > 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.
>