The MPLS WG Archive

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



[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 FromPittsburgh

  • From: Olivier Duroyon <oduroyon@adn.alcatel.com>
  • Date: Thu, 19 Oct 2000 13:40:51 -0500
  • CC: jdrake@calient.net, braja@tellium.com, azinin@cisco.com, neil.2.harrison@bt.com, mpls@UU.NET, ip-optical@lists.bell-labs.com
  • Organization: Alcatel


Darren,

I think you made your point clear.
But John's last mail explained the different options and one should cover some
of your concerns.

> >> There's no reason why the back
> >> end couldn't be GMPLS in peer mode

Sure, or ATM PNNI, or  a centralized management entity.

> I believe there is a reason.  And I've yet to be convinced otherwise by
> anyone.  The way I see it, peer model = single control plane.  Single
> control plane = common addressing, signalling, & routing.  Common addressing
> = only possible if the OTN has a single client.

Why do you say that?
-case of IP clients:
ISPs are connected together using BGP and nevertheless, they are representing
different administrative entities. They
just need to register to get an IP address range.
-case of non-IP clients:
The Optical UNI is here defined to break (if needed) the layers between the
administrative entities and be able
to support the case where the server layer trail is different than the client
layer link.

> This has been explained in
> the recent "server layer trails = client layer links" links discussions =>
> i.e. common addressing not possible in a multi-client OTN => i.e. peer model
> impractical in a multi-client OTN.  I think this fundamental issue has to be
> recognised.

I would say that your are always referring only to the peer model without UNI
support at the edge.
And this is limitating the peer model capabilities.

Regards,
Olivier Duroyon
Alcatel USA
(703) 654 8605

>
>
> Regards,
> Darren.
>
> -----Original Message-----
> From: John Drake [mailto:jdrake@calient.net]
> Sent: 19 October 2000 17:58
> To: 'Bala Rajagopalan'
> Cc: 'darren.freeland@bt.com'; azinin@cisco.com; neil.2.harrison@bt.com;
> mpls@UU.NET; ip-optical@lists.bell-labs.com
> Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: Draft
> Minutes From Pittsburgh
>
> Bala,
>
> I think that there's a big difference between the service interface offered
> to a user (aka the front end) and the interface that a service device uses
> to attach to the rest of the network (aka the back end).  There's no reason
> why the back end couldn't be GMPLS in peer mode even if the front end was
> something silly like ATM UNI.
>
> Thanks,
>
> John
>
> -----Original Message-----
> From: Bala Rajagopalan [mailto:braja@tellium.com]
> Sent: Thursday, October 19, 2000 9:42 AM
> To: John Drake
> Cc: 'darren.freeland@bt.com'; azinin@cisco.com; neil.2.harrison@bt.com;
> mpls@UU.NET; ip-optical@lists.bell-labs.com
> Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: Draft
> MinutesFrom Pittsburgh
>
> Hello,
>
> John Drake wrote:
>
> >
> >
> > 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.)
>
> 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: braja@tellium.com
>
> _______________________________________________
> IP-Optical mailing list
> IP-Optical@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/ip-optical