[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GMPLS signaling documents updated per last calls
- To: Dimitri Papadimitriou <dimitri.papadimitriou@alcatel.be>
- Subject: Re: GMPLS signaling documents updated per last calls
- From: George Newsome <gnewsome@lucent.com>
- Date: Fri, 21 Dec 2001 14:56:09 -0500
- Cc: "Mannie, Eric" <Eric.Mannie@ebone.com>, "'Maarten Vissers'" <mvissers@lucent.com>, "'jonathan.sadler@tellabs.com'" <jonathan.sadler@tellabs.com>, "'Stephen Trowbridge'" <sjtrowbridge@lucent.com>, Kireeti Kompella <kireeti@juniper.net>, ccamp@ops.ietf.org, dbrungard@att.com, lberger@movaz.com
- Organization: Lucent Technologies, Bell Labs
- References: <D52BF6463BA3D311BFA700508B63C5AA06B405CA@brumsgpnt01.gtsgroup.com> <3C23889E.88D573ED@alcatel.be>
Dimitri Papadimitriou wrote:
>
> Maarten,
>
........
>
> 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.
>
This is almost funny. The whole debate is about getting rid of unnessary
and restrictive complexity in your current solution.
.........
> >
> > 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
Given your current solution, I can only wish you well
> the art transmission system modelling "theory" since in practice state
> of the art models are rarely applicable in the real world.
Good models are taken from the real world - the one that some of us have
worked with for many years. Its hard to see how such models don't apply.
(Remember the new economy - the old models didn't apply)
>
> ... these remarks translates the problem of people working only from
> the "theoretical" viewpoint without any pragmatic view on the reality.
>
Well Dimitri, if you can't deal with Maarten's arguments, at least you
can try and call him names.
........
>
> 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.
>
Again, the best I can do is wish you well with your "simple" model
Have a Merry Xmas
Regards
George