RE: How does XML help Network Operators

["David T. Perkins" <dperkins@dsperkins.com>]

HI,

In the discussions so far, there is not a limitation to bulk configuration
retrieval from a managed system and bulk configuration restore to a
managed system.

In the numbers that you provided, which are...
>A large network operator with 60 million telephone
>subscribers figures that some day a good chunk of those subscribers might be
>served with VoIP.  Just to pick an easy number, lets say at some point they
>are converting 1 million subscribers per year (which, as I'm sure you can
>calculate, means it would take 60 years to evolve from POTS to VoIP).  Even
>at that leisurely pace, they are converting on the order of 10 subscribers
>per second each 8 hour working day.
I have some problem with these. But first lets verify....
(1000000 conversions per year)/(6 work days per week * 52 weeks)=3205 per day
and 
(3205 per day)/(8 hours per day)= 400 per hour
and
(400 per hour)/(60 min per hour) = 6.7 per minute

So, I don't see 10 per second. (Also, these are changes over the WHOLE
network, and not per device.) What would the numbers turn out when
the number of devices was factored in? With automation, why an 8 hour
day or only 6 days per week?

These numbers are guesses. It would be much better to get REAL numbers.
For example, in a given meto area (such as the SF bay area), how many
phone service adds/deletes/changes occur per day. What is the total
number of lines in service.

Bert and all of the rest of us want REAL data and not projections.

At 10:47 AM 10/1/2002 -0500, Allen, Keith wrote:
>All,
>
>Hello all,
>
>I believe Bert wrote earlier about trying to document the needs of different
>types of carriers - large, small, core, access, etc.  Working for a large
>access provider, we often find it hard to get suppliers that are oriented
>towards enterprises or core service providers to understand our needs.  I
>think it will be a difficult challenge for this group to try to accommodate
>all.
>
>I have gotten the impression from some messages that the focus of a
>configuration protocol should be on the retrieval (dumping) and restoring of
>configuration state from/to some network element.  Unfortunately access
>networks are not so stable that the greatest configuration management
>concern is backups and restores.  Change is constant.  Our greatest
>configuration management concern is updating the configuration of network
>elements to support some new service need, such as the addition of a new
>subscriber or a change in subscriber status.  The management system also has
>to be updated if changes are made to the NE.  So, I see the need for a
>configuration protocol that enables a much more dynamic interaction between
>a management system and an NE than just dumping and restoring.
>
>It's not so much that we have to make do with "junior operators," although
>skilled talent is always a concern.  It's simply scale.  For fun, consider
>this future scenario.  A large network operator with 60 million telephone
>subscribers figures that some day a good chunk of those subscribers might be
>served with VoIP.  Just to pick an easy number, lets say at some point they
>are converting 1 million subscribers per year (which, as I'm sure you can
>calculate, means it would take 60 years to evolve from POTS to VoIP).  Even
>at that leisurely pace, they are converting on the order of 10 subscribers
>per second each 8 hour working day.  Just getting the VoIP gateways
>configured as subscribers are added will be a scramble that I don't think
>can be done with dumps and restores.
>
>Designing one protocol that enables one operator to simply dump the
>configuration of a device while allowing another operator to go in and
>change a specific set of parameters on a device or perform some query will
>be a challenge.
>
>
>Keith Allen
>
><rest cut>
Regards,
/david t. perkins


--
to unsubscribe send a message to xmlconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/xmlconf/>