RE: Moving right along ...

[mike.sexton@alcatel.co.uk]

Neil,

I am not sure that it is appropriate to get into business model issues on this list. I'd have to get my marketing and business development hat on. However below, in line, is a brief response I suggest if you want to pursue this further we do it off list.

regards,

Mike Sexton




neil.2.harrison@bt.com on 25/10/2001 11:47:18
                                                              
                                                              
                                                              
 To:      Michael J SEXTON/GB/ALCATEL@ALCATEL,                
          mvissers@lucent.com                                 
                                                              
 cc:      sudheer@nayna.com, ccamp@ops.ietf.org               
                                                              
                                                              
                                                              
 Subject: RE: Moving right along ...                          
                                                              





Hi Mike.....nice to hear from you and I think you make some good points.
However, I want to pick-up on one aspect you bring up a few times....and
that is 'choice'.  Operators need choice to suit their views on what
is/is-not a viable business case.

MS: Naturally.

For example, we have various client layer networks besides IP to
accommodate, and of particular importance are managed BW services directly
off the L1 fabric, eg VC4 or lambdas say.  However, we can't see any valid
business case for generalised BoD/SVCs services here.....I mean, given
unknown calling/holding statistics just what capacity would one need to
build to to offer a GoS that customers would consider acceptable and that
you could get past finance/products people (esp given current climate)?

MS: The service level differences here are quite subtle. They are for many practical purposes indistinguishable. But, getting back on subject, whether they are implemented with the help of a control plane or through a centralised service management process
will only affect secondary features (eg speed of customer response, performance etc) and these will be more determined by implementation details in either model.

So, on assumption that S-PVC-like services are all that is commercailly
viable (in our opinion at least) then you can ask yourself just what
additional revenues and/or Opex cost reductions are available from
implementating a control-plane solution?  Even this is difficult to justify
given:
-    current NMS approaches (in SDH) can easily cater for current and
foreseeable core trail churn rates;
-    the big costs are in access and laying ducts and installing
physicals....no control-plane solution is going to impact these.

MS: Agreed these are difficult calls to make. However I note that there has been considerable interest in recent times in the developing business of bandwidth brokerage. In just a few years implementations of this business model have progressed from purely
paper contract based introductions between buyers and sellers through Web based service transactions to automatically switched on demand. In the last case the bandwidth broker installs a switch (controlled through SS7) or an optical cross-connect
controlled through service management centre (in future ?) buyers and sellers attach themselves to BB premises via metro fibre links and exchange bandwidth either on a form of spot market (as available) or under an evergrowing variety of more elaborate
contracts (time of day, OVPN, standby for overflow or protection etc). This trend may continue or it may indeed fizzle out.

However, assuming you do decide you want to implement a control-plane
solution in your transport networks then you really ought to be able to
choose the addressing, signalling and routing components on a best-of-breed
basis to suit what you want to do.  They are after all, quite disjoint
components and there are many architectural possibilities.......and this is
what ASON is all about....choice.

MS: This is the basic standardisation dilemma. where is the "right" trade off between choice and efficiency. The modern solution to protect choice is to set off a number of de juro standards and leave them to slug it out in the market place. Those that
retain sufficient flexibility to find their market niche and adapt, survive those that don't don't.

For example, I could very easily argue that a NSAP + Q.2931/PNNI (signalling
aspects only) + centralised routing approach looks the best commercially for
what we want to do.  Others may argue that the current GMPLS approach suits
them best.  ASON allows this choice.

regards, Neil

> -----Original Message-----
> From: mike.sexton@alcatel.co.uk [mailto:mike.sexton@alcatel.co.uk]
> Sent: 25 October 2001 11:49
> To: Maarten Vissers
> Cc: Sudheer Dharanikota; ccamp@ops.ietf.org
> Subject: Re: Moving right along ...
>
>
>
>
> Maarten,
>
> In the interests of reconciliation consider the following:
>
> ASON and G-MPLS are both post hoc conceptual models
> describing the same physical and logical network. The
> objectives of automation through signalling are broadly
> similar. Therefore it would be surprising indeed if the
> solutions were widely different. ASON
> is indeed based on the layered model of G.805 and deals with
> layering issues up-front. GMPLS is derived from the Internet
> model which regards the physical layer as flat. When real
> world layering is encountered it is dealt with by refinements
> many of which
> appear in draft-ietf-mpls-lsp-hierarchy-03.txt which is one
> of the source documents from which G-MPLS inherits. Here LSP
> regions are defined in 6.2 which are as near as I can tell
> exactly equivalent to G.805 layer networks. Further, precedence rules
> between layers are established with the clear implication
> that a higher layer cannot be configured until the
> appropriate resources in the lower layer have been
> instantiated. The manner in which this may be done is
> considered a "local matter". The example
> given indicates that a Forwarding Adjacency (equivalent to a
> G.805 link supported by one or more trails (LSPs) in the
> server layer) may be initiated in various ways including from
> an external manager or another (adjacent) LSR. Thus the
> example you gave of
> a VC-1x layer being set up by signalling and VC-4 layer being
> set up by an external planning/management is certainly a
> valid implementation within the scope of the G-MPLS solution.
> By the same token it is undesirable (and anyway will not be
> possible) to
> confine signalling to certain layers while reserving others
> for management through a standard. Operators will want to
> make such important architectural choices on the basis of
> optimising their own operation. Once you have agreed on a
> signalling protocol to
> create connections within a layer network it is generically
> applicable to any layer network. Of course making such an
> implementation choice (ie management for VC-4, signalling for
> VC-1x) is an example of the "local policies" mentioned above.
> Such choices
> frequently appear as part of some sort of application
> specific profile or applications framework on top of the base
> generic standard. Note this sort of profiling (if that is the
> correct term) is
> generally needed to ensure interworking amongst elements
> which implement the same generic standard.
>
> On the last occasion that we studied application of
> signalling for transport networks in ITU (over 10 years ago
> at the time G.805 was first issued) we had concluded that
> connection set-up within a layer was the easy part ie there
> were several well
> established candidates to choose from (B-ISUP was the
> favorite. Neither PNNI nor RSVP existed at that time. ISIS
> had already been adopted for DCN in SDH and thus provided
> basic neighbour discovery and xSPF computation if required).
> The major new problem to
> resolve for multi-layer transport networks was indeed
> considered to be the desired behaviour at inter-layer
> boundaries. It seems that both initiatives have sidelined
> this issue as out of scope for the time being.
>
> regards,
>
> Mike Sexton
>
>
>
>
>
>
>
> Maarten Vissers <mvissers@lucent.com> on 25/10/2001 06:03:38
>
>
>
>  To:      Sudheer Dharanikota <sudheer@nayna.com>
>
>  cc:      ccamp@ops.ietf.org(bcc: Michael J
>           SEXTON/GB/ALCATEL)
>
>
>
>  Subject: Re: Moving right along ...
>
>
>
>
>
>
> Sudheer,
>
> Another issue is ...
>
>      - ASON is layer network based, GMPLS is not
>
> i.e. a request for a connection within ASON is treated within
> the boundaries of
> one layer network (e.g. within the boundaries of a
> VT1.5/VC-11 layer network, or
> within the boundaries of a STS-3c/VC-4 layer network). A
> VT1.5/VC-11 connection
> request is processed within the VT1.5/VC-11 layer network,
> using existing
> VT1.5/VC-11 links (GMPLS: link bundles). If there is not
> enough capacity  in the
> VT1.5/VC-11 links to support the request, the call fails.
> There is no "hidden"
> set up of a STS-1 or VC-4 trail supporting an additional
> VT/LOVC link or
> extending an existing VT/LOVC link. The set up of an
> additional STS-1 or VC-4
> trail is supported within the scope of network planning and/or network
> engineering. This is separated from the connection set up.
>
> Regards,
>
> Maarten
>
> Sudheer Dharanikota wrote:
> >
> > Hi Maarten:
> >
> > Maarten Vissers wrote:
> >
> > > Sudheer,
> > >
> > > At the moment I am unable to briefly summarize the
> differences between GMPLS and
> > > ASON. I was working from the perception that GMPLS could
> be one of the protocols
> > > supporting ASON. The technical comments I made during the
> last 10 months were
> > > based on this perception. Also the last comment
> describing the concept of serial
> > > compound link had this basis. Reading Yanhe's reply I had
> the impression that
> > > GMPLS is able to support serial compound links, but
> reading Eric's reply I got
> > > the opposite impression. Furthermore being very surprised
> by Eric's reaction on
> > > a pure technical issue, I composed a few challenging
> words to attrack more
> > > people to participate in the  discussion... :-)
> >
> > I see one of the issue here being ...
> >
> >     - Does GMPLS support serial compound links?
> >
> > Let us enumerate few more questions and move the discussion
> to a technical
> > level again, we need participation especially from the
> folks who are involved
> > in ASON architecture work.
> >
> > >
> > > Being impressed by the few hundred people attending the
> last ccamp sessions in
> > > London, I am surprised by the low percentage of those
> people being actively
> > > contributing to the correspondence. It can't be the case
> that only a handful of
> > > people have an opinion on these matters... and I believe
> the discussions would
> > > stay technical if more people express their opinion...
> there would not be a
> > > yes/no game between just a few people.
> > >
> >
> > I thought this is how most of the standards meetings work.
> 5 % work, 95 %
> > try to gather industry intelligence ( :-) ) either by
> attending IETF or by following
> >
> > the mailing list.
> >
> > >
> > > With G.8080 (ex. G.ason) and G.7713 (ex. G.dcm) available
> it will be possible to
> > > start an evaluation of GMPLS as a specific protocol for
> ASON. As indicated in a
> > > previous email from Steve Trowbridge, ITU-T will make
> those ASON documents
> > > available to IETF so we can jointly work this evaluation.
> > >
> >
> > Most of these documents are available on the t1x1 site. But
> what we need here is
> > the "delta" that is missing between ASON architecture and
> the view of GMPLS
> > architecture. Can you help us with this? We may start with
> a short list...
> >
> > >
> > > The approval of the current ASON recommendations is just
> a first step within the
> > > larger ASON task. Work is started on other elements of
> ASON (G.rtg (routing),
> > > G.lm (link management) and pnni based specific protocol
> as an implementation of
> > > the protocol neutral specification in G.7713)),
> discussions are started
> > > identifying further ASON elements, and work to extend
> G.8080 is planned to start
> > > after this SG15 meeting.
> > >
> >
> > Obviously GMPLS is a potential candidate to solve the ASON
> issues. It may be
> > ahead of its time as far as ITU and ANSI are concerned. So
> let us ammend or
> > modify it to the ITU view on the transport control plane.
> >
> > Regards,
> >
> > sudheer
> >
> > >
> > > Up to so far... {time to shut down my computer and go to
> the concert hall in
> > > Geneva... time to relax after a week and a half of hectic
> work over here...}
> > >
> > > Regards,
> > >
> > > Maarten
> > >
> > > Sudheer Dharanikota wrote:
> > > >
> > > > Hi Marteen:
> > > >
> > > > Can you briefly summarize the differences you see between
> > > > GMPLS architecture and ASON architecture? This has been
> > > > asked by many of the folks at IETF.
> > > >
> > > > Regards,
> > > >
> > > > sudheer
> > > >
> > > > PS: I thought these mails were about label format and suddenly
> > > > this is turning into an ITU versus IETF discussion :-(
>