The MPLS WG Archive

[darren.freeland@bt.com]

Hi Yangguang,

Yes, perhaps the choice of overlay or peer model should be left to operators
dependent on their business models.  I recall that there was a draft from
Lucent & Japan Telecom presented in Pittsburgh that touched on possible
business models for the OTN (draft-hayata-ipo-carrier-needs).  Perhaps these
need to be included in a new draft that fully considers operator
requirements for the optical layer ...

Regards,
Darren.

-----Original Message-----
From: Yangguang Xu [mailto:xuyg@lucent.com]
Sent: 19 October 2000 18:31
To: mpls@UU.NET; ip-optical@lists.bell-labs.com
Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: Draft
MinutesFrom Pittsburgh



Hi,

Should peer/overaly model the choice of service providers according to their
business models?  

Yangguang 

John Drake wrote:
> 
> Darren,
> 
> GMPLS allows, but does not require, multiple types of hierarchically
related
> LSPs to exist in a single instance of a link state database.  If a network
> owner decides to have MPLS devices supporting multiple types of LSPs in
the
> same instance of a link state database, then his network is an
instantiation
> the peer model.
> 
> From my perspective, the focus of the peer model is to facilitate how a
> network owner constructs his network most efficiently and not how he
> represents it to his customers.  The latter is typically done using
multiple
> service definitions.
> 
> For example, a few years ago, one would build an IP service using routers
> mesh connected in an overlay on top of a PNNI  transport network.  This
was
> perceived as an exquisitely painful way of doing things and led directly
to
> the development of MPLS.  I.e., extend the IP control plane to support
> traffic engineering and then have the ATM switches implement MPLS.  This
> eliminates the artificial overlay boundary between IP routers and ATM
> switches.  (On the other hand, there would still be operational benefits
to
> using MPLS to control the ATM switches even if the network owner wished to
> maintain this overlay boundary.)
> 
> GMPLS just extends this concept to encompass other types of transport
> networks.
> 
> Thanks,
> 
> John
> 
> -----Original Message-----
> From: darren.freeland@bt.com [mailto:darren.freeland@bt.com]
> Sent: Thursday, October 19, 2000 2:53 AM
> To: azinin@cisco.com; neil.2.harrison@bt.com
> Cc: mpls@UU.NET; ip-optical@lists.bell-labs.com
> Subject: [IP-Optical] RE: Optical link bundling. Was Re: Draft Minutes
> From Pittsburgh
> 
> Hi Alex,
> 
> >>> - "server layer trails (in an OTN) = client layer links", and
> >>> networks operators *will* have to support multiple client
> >>> layers for a very long time...including some large BW servives
> >>> directly off the L1 fabric.
> >>>
> >>> This is a really important point.  It is a fundamental
> >>> characteristic of a layered network architecture.
> >
> > [AZ] Got it. I didn't realize what layers you meant.
> 
> This is the first time I have actually seen anyone on the MPLS or IPO
lists
> publicly acknowledge the "client layer links = server layer trails" fact.
I
> assume then that you now also acknowledge the single control plane 'Peer'
> model as being impractical?  Okay, using a single 'best of breed' routing
> protocol and a single 'best of breed' signalling protocol across the IP
and
> optical layers may be feasible (I stress may), but it follows from the
above
> simple concept (as Neil Harrison stated before) that the addresing scheme
> used by the optical layer cannot be related to any particular clients (ie
> not from the same addressing space in terms of possible trail connectivity
> at layer network access points).  Sure this would not be the case if IP
was
> the only client of the optical layer, but (*reality check*), operators
WILL
> still be making most of their revenue from non-IP clients for a long time
to
> come, and therefore an optical transport network WILL have to support
> multiple clients.
> 
> Are we now seeing a realisation of this in the IETF?  I think it's obvious
> that what was defined as the 'Overlay' model in
> draft-awduche-mpls-te-optical-02.txt and
> draft-many-ip-optical-framework-01.txt must be developed first.
> 
> Cheers,
> Darren.
> 
> _______________________________________________
> IP-Optical mailing list
> IP-Optical@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/ip-optical

_______________________________________________
IP-Optical mailing list
IP-Optical@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/ip-optical