Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: Draft Minutes From Pittsburgh

From: John Drake <[email-masked]>
Date: Thu, 19 Oct 2000 09:19:20 -0700

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: [email-masked] [mailto:[email-masked]]
Sent: Thursday, October 19, 2000 2:53 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
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
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/ip-optical

---

From: Bala Rajagopalan <[email-masked]>
Date: Thu, 19 Oct 2000 12:41:39 -0400

Hello,

> maintain this overlay boundary.)

In the case of IP over optical,
I would just like to add that once you do have an IP-centric control
plane within optical networks, you could have routing between IP and
optical network that in fact supports the overlay model, alleviating the
scalability concerns that arise with IP over ATM model described above.

It's then a question of the coupling between the IP and optical control
planes. This can be as loose or tight as you want, for example, supporting
a UNI that separates the control planes, or the peer model without any
separation.

I do agree that if  you considered other types of clients,  the
peer model constructs don't seem  practical.

regards,

--

Bala Rajagopalan
Tellium, Inc.
2 Crescent Place
P.O. Box 901
Oceanport, NJ 07757-0901
Tel: (732) 923-4237
Fax: (732) 923-9804
Email: [email-masked]

---

From: Yangguang Xu <[email-masked]>
Date: Thu, 19 Oct 2000 13:31:04 -0400

Hi,

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

Yangguang