Subject: Re: Two orthogonal issue

From: Kireeti Kompella <[email-masked]>
Date: Tue, 24 Oct 2000 19:43:46 -0700 (PDT)

Hi Ron,

> Have we been discussing two distinct questions, as if they were the same?
> These are:

> 	1) Overlay model vs. Peer model
> 	2) UNI vs MPLS signaling between client IP network and optical transport
> network

> The first issue addresses the degree to which a client IP network can access
> the optical transport network's signaling. The second issue addresses the
> syntax of the interface between the client IP network and optical transport
> network.

Good distinction.

> These two issues are orthogonal to one another.

In principle, yes.

In practice, though, the connotation of "UNI" is pretty much
"overlay" -- the distinction between U and N means that there is
a restriction in information exchange.  And in any case, the
current UNI spec has a very restricted flow of information across
the U/N border -- it's primarily a signalling protocol, and the
information exchange is "end point discovery" and "LSP status".

However, in GMPLS, both models are supported equally.  For the
peer model, one puts all boxes in one IGP area.  One easy way to
accomplish the overlay model is by the notion of IGP areas; another
is by means of IGP instances.  The finishing touch is to define a
good means of doing inter-area TE which includes GMPLS TE (watch
this space).

> Whether we choose a UNI or MPLS signaling, flexible access policy is
> required. That way, an optical carrier could decide exactly how much
> privilege to grant each client, on a case by case basis.

Absolutely.  A lot of folks don't seem to get this point: for
example, one could have OXCs and *some* routers in the backbone
area; other routers in non-backbone areas, and yet other clients
(routers, ADMs, ...) accessing the same OXCs via the UNI.  And
one could run NMS systems as well for provisioning legacy boxes.

> Please re-orient me if I am missing the point, entirely.

You aren't.  Note however that two other points have been raised:
a) is IP the "right" protocol for the control plane; and
b) is GMPLS the "right" protocol for the control plane.
However, I haven't seen convincing arguments that IP and GMPLS
aren't suitable; nor have I seen alternate proposals.

> P.S. I hope that I have not just opened Pandora's box.

No, it was already wide open :-)

One thing that has come out of this debate is that carriers are
thinking more deeply about requirements, which is a welcome step
forward.  At the same time, several deep-rooted biases are being
exposed, and I'll be the first to admit my bias towards using
MPLS/GMPLS for the control plane.  Another step forward, but this
one is more painful.

Kireeti.

---

From: Ron Bonica <[email-masked]>
Date: Wed, 25 Oct 2000 22:27:04 -0400

> one could run NMS systems as well for provisioning legacy boxes.

If the client IP network were to used MPLS signaling to obtain services from
the optical transport network, and if the optical transport network were
clever about enforcing a configurable admission control policy, would there
be any need for a UNI? Couldn't the admission control policy restrict client
networks to services that they might otherwise have obtained through the
UNI?

---

From: Yakov Rekhter <[email-masked]>
Date: Wed, 25 Oct 2000 19:51:01 -0700

Kireeti,

[clipped...]

> MPLS/GMPLS for the control plane.  

There are fairly pragmatic reasons for using MPLS/GMPLS for
the control plane - for more on this folks may read
draft-awduche-mpls-te-optical-02.txt.

Yakov.

---

From: "Jason Sauviac" <[email-masked]>
Date: Wed, 25 Oct 2000 23:00:46 -0600

UNSUBSCRIBE

---

From: Yangguang Xu <[email-masked]>
Date: Thu, 26 Oct 2000 09:25:34 -0400

Ron,

> networks to services that they might otherwise have obtained through the

You are right. Especially in the case you mentioned.

I understand many folks don't even want to hear "UNI" probably because of their
previous bad experiences of ATM UNI. (Mee too, at beginning). Yet, optical UNI
is different from ATM UNI in many key aspects (and sure similar in many
concepts).

Think optical UNI as only a "functional" interface. It can be thin and thick
with service providers' control according to different network application
scenarios. 

For one extreme, optical network and routers are owned by different service
providers. You sure need a thick UNI with strong security and policy control.

For another extreme, optical network and routers are owned by the same service
provider and provisioned within a single area. Now UNI is very thin. Actually
only GMPLS signaling is needed. However, the "UNI" is still there because the
optical LSP is triggered by the request from routers' traffic engineering
function.

UNI is not a monster. It's up to how we define and design it.

Regards,

Yangguang

---

From: Yakov Rekhter <[email-masked]>
Date: Thu, 26 Oct 2000 06:45:45 -0700

Yangguang,
 
> providers. You sure need a thick UNI with strong security and policy control.

That is clearly the case where the overlay model is needed (and the
peer model isn't suitable).

> optical LSP is triggered by the request from routers' traffic engineering

For the latter case (OXCs and routers are provisioned within a single
area), routers themselves may as well compute routes for LSPs. So,
why bother with UNI in this scenario ? As Kireeti was trying to
explain to you before,

Yangguang> The key point is whatever routers can do to optical network, 
Yangguang> optical switches can do by themselves (as easy as router can do). 
Yangguang> Why bother?

Kireeti> This is not a router vs. optical switch issue.  The issue is
Kireeti> that the *originator* of the LSP has all the info.  The originator
Kireeti> of the LSPs can do a full path computation, can do both paths
Kireeti> simultaneously, has no coordination issues, no extensions to
Kireeti> signalling or link state protocols.         

Yakov.

P.S. And just to add to this, you may look at the attached e-mail
that was posted to this list last February...

 -- using template mhl.format --
Date:    Wed, 02 Feb 2000 01:18:21 PST
To:      Theimer Thomas <[email-masked]>
cc:      [email-masked], [email-masked]

From:    Tony Li <[email-masked]>
Subject: Re: MPLS and Optical network!!

> I would expect that initially the optical domain will have a control
> plane that is independent from the layer 3 control plane of routers. Of
> course,
> there is traffic engineering in the optical domain, and there is traffic
> engineering
> in the layer 3 domain, but why do they have to be integrated ???

In addition to Curtis' points, we should also note that traffic engineering
computations for deriving the optimal allocation of circuits in static network
is already considered to be a computationally 'hard' problem in operations
research.

If we partition the problem in the way that you describe, we make the
computation 'harder' in the sense that we've precluded the traffic engineering
demands on the routed plane from interacting nicely with the wavelength
allocation in the optical plane.  One can envision (possibly pathological) cases
where optimality is actually improved by keeping certain traffic on the routed
plane, thereby allowing other traffic to make use of the optical plane.

The more cynical might suggest that I'm proposing that we simply dump the hard
parts of the problem in the laps of the OR folks and do the bare minimum amount
of engineering necessary to have a simplistic, functional system.  ;-)

Tony