[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Why Call/Connection Separation
all, in order to re-initiate the discussion w/i the
ccamp wg an "ason functional req's" i-d has been (re-)
initiated that should (hopefully) explain the reasons/
rationales (the "why") and the expectations (the "what")
for call-connection control separation and other
requirements such as crank back for instance
we plan to submit it right after the meeting (subm.
deadline being over for this meeting) in order to move
a step forward with this discussion
hint: i'd be of great interest if the user community
(in particular ops folks) could give us their view-
point here as well
thanks,
- dimitri.
"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
> >
> >
> >
--
Papadimitriou Dimitri
E-mail : dimitri.papadimitriou@alcatel.be
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : dpapadimitriou@psg.com
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone : +32 3 240-8491