The MPLS WG Archive

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



[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 Minutes From Pittsburgh

  • From: John Drake <jdrake@calient.net>
  • Date: Thu, 19 Oct 2000 09:19:20 -0700
  • Cc: mpls@UU.NET, ip-optical@lists.bell-labs.com

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