The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2000-Oct> msg00249



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

[IP-Optical] RE: Optical link bundling. Was Re: Draft MinutesFrom Pittsburgh

  • From: Yangguang Xu <xuyg@lucent.com>
  • Date: Thu, 19 Oct 2000 13:31:04 -0400
  • Organization: Lucent Technologies, Inc.


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