[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Why Call/Connection Separatation
Bert,
of course you are right, that the subject line should reflect the discussion. It
was however not my intention to start yet another discussion on call/connection
separation but to use it as an example on how to solve issues which seem to be
clear on one side and unclear on the other one. I repeat that in our target
should be to find a solution which is shared between IETF and ITU-T. The way
forward is in my opinions to *help* everybody to understand the issues and to be
open to consider a variety of solutions. This way however requires that the
involved folks *want* to work together and really share a common target - not
sure if we are already there.
Regards
Gert
"Wijnen, Bert (Bert)" wrote:
> It is always interesting to see how a discussion on a
> document that describes initial ideas on change control
> diverts into a discussion on other topics, in this case
> the toipic of "Why Call/Connection Separation".
>
> But people never change the subject line.
> Oh well... if you want to continue this discussion, then PLEASE
> use a proper subject line from now on.
>
> Also if you decide to switch topics again, that you also change
> the subject line.
>
> Thanks,
> Bert
>
> > -----Original Message-----
> > From: Gert Grammel [mailto:Gert.Grammel@alcatel.de]
> > Sent: woensdag 12 maart 2003 11:08
> > To: neil.2.harrison@bt.com
> > Cc: mlazer@att.com; Mark.Jones@mail.sprint.com; ccamp@ops.ietf.org;
> > dwfedyk@nortelnetworks.com; gash@att.com; mpls@UU.NET
> > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> >
> >
> > Neil,
> >
> > I think you haven't got my point about call/connection
> > separation. Please have
> > also a look to my respone to Eve. There can be a discussion about
> > call/connection separation once there is a kind of shared
> > view on 'why it is
> > needed'. In
> > http://www.ietf.org/internet-drafts/draft-ietf-ipo-carrier-req
> > uirements-05.txt
> > the only 'motivating sentence I could find was:
> >
> > To support many enhanced optical services, such as
> > scheduled bandwidth
> > on demand, diverse circuit provisioning and bundled
> > connections, a
> > call model based on the separation of call control and connection
> > control is essential.
> >
> > You gave some practical examples on where you see the need
> > for that. Why not
> > putting it into a document and share it with everybody?
> >
> > I also want to thank you to share with us your choice to go for a L0/1
> > functionality. This is a very clear statement.
> >
> >
> > Regards
> >
> > Gert
> >
> > neil.2.harrison@bt.com wrote:
> >
> > > Hi Gert, I think some clarifications are in order here to
> > make the BT
> > > position (ie not just the NH position) clear. Please see
> > below. regards,
> > > Neil
> > >
> > > Gert Grammel wrote 11 March 2003 15:47 to Monica Lazer:
> > >
> > > <snipped>
> > > > Look at the hottest issue under discussion: We are talking a
> > > > lot about UNI
> > > > features like call/connection separation. Neither Mark nor
> > > > Neil see the UNI
> > > > becoming service relevant at any time soon - so why is it
> > > > under discussion right
> > > > now? Is this your priority 1 issue in ITU-T? Is Mark or Neil
> > > > in a minority
> > > > position in ITU-T? Referring to the Yokohama Meeting this was
> > > > basically
> > > > Kireeti's request: Please explain what you need and for
> > what purpose.
> > >
> > > NH=> A UNI at L1/0 is *not* something we see as important
> > anytime soon. We
> > > also see no need for coupling with L2/3 (either commercially or
> > > technically). Thus we want to be able to choose
> > best-of-breed functionality
> > > for L1/0. We *do* want call/connection separation however,
> > and note this is
> > > independent of the UNI...here is an extract from a
> > colleague of mine on the
> > > ITU lists which sort-of explains why:
> > > "Anyone care to disagree with the notion of a call handle
> > for SPCs in the
> > > ITU-T as a means of bundling under one service instance a
> > customer record
> > > that handles
> > > multiple connections e.g. Virtual Concatenation, with or
> > without LCAS as a
> > > valid application?
> > > Anyone care to disagree that we might want to retrieve
> > information on an SPC
> > > using a single identifier (the call) that shows all
> > connections associated
> > > with that call and the performance of each connection
> > and/or start end of
> > > individual connections?
> > > Anyone care to diagree that the call/connection model
> > cannot be used for
> > > restoration of SPCs?
> > > As for those that want to do UNI on you go...but its not on
> > BT priority
> > > list."
> > > >
> > > <snipped to end>
> >
> > --
> > Alcatel Optical Network Division Gert Grammel
> > Network Strategy phone: +49 711 821 47368
> > Lorenzstrasse 10 fax: +49 711 821 43169
> > D-70435 Stuttgart mailto:Gert.Grammel@alcatel.de
> >
> >
> >
--
Alcatel Optical Network Division Gert Grammel
Network Strategy phone: +49 711 821 47368
Lorenzstrasse 10 fax: +49 711 821 43169
D-70435 Stuttgart mailto:Gert.Grammel@alcatel.de