Subject: RE: Comments on draft-ip-optical-framework-00.txt

From: Jonathan Lang <[email-masked]>
Date: Thu, 23 Mar 2000 13:55:15 -0800

Krishna,
  The Open model seems quite "Closed" to me - the very nature of clouds
implies information hiding in my mind.  What is exactly meant by open?
Also, I'm not sure I agree with your definition of overlay, as many people
allow the overlay model to encompass both your (2) and (3).  Furthermore, I
don't think the Peer Model implies OXCs are "agile but fat & dumb" since as
they are "peers", this would also imply routers are "agile but fat & dumb"
as well - and at some point, someone needs to have intelligence.  I would
suggest that the Peer model allows both routers and OXCs to interoperate
intelligently.

Regards,
Jonathan

-----Original Message-----
From: Krishna Bala [mailto:[email-masked]]
Sent: Thursday, March 23, 2000 11:59 AM
To: [email-masked]; Jagan Shantigram
Cc: Khaled Elsayed; [email-masked]; [email-masked]
Subject: RE: Comments on draft-ip-optical-framework-00.txt 

Jagan,
There are several architectural models for IP over Optical Networks that
are emerging:

1. Peer Model
In this model the IP router is entirely aware of the details on the
underlying
optical network (topology information, wavelength and port usage and lamda
assignment).
It is able to control and manage entire end to end paths. In this model the
OXC is "agile but fat & dumb".
2. Overlay Model
The optical layer is "fat & dumb". The lamda connections between the IP
routers behave as if they were dedicated fibers between them. The IP routes
provision logical optical circuits over a fixed or at best a quasi-fixed
optical
layer.
3. Open Model
In this scenario the optical layer comprises of several "vendor/network
operator clouds"
that have well defined interfaces. For example, an Optical UNI can be used
to
interconnect the IP router to the OXC and the Optical NNI can be used to
connect
two optical network domains together. Here the optical layer is "fat, smart
and agile".

It is unclear at this time which of these models will prevail.

Krishna Bala
Tellium

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of Curtis
> Villamizar
> Sent: Thursday, March 23, 2000 1:55 PM
> To: Jagan Shantigram
> Cc: [email-masked]; Khaled Elsayed; [email-masked];
> [email-masked]
> Subject: Re: Comments on draft-ip-optical-framework-00.txt
>
>
>
> In message <[email-masked]>, Jagan
> Shantigram wr
> ites:
> > At 12:52 PM 3/22/00 -0500, Curtis Villamizar wrote:
> > >
> > >In message <[email-masked]>, Khaled Elsayed writes:
> > >>
> > >>
> > >> Hello Jagan,
> > >>
> > >> > When we do not have lambda conversion however, this problem cannot
> > >> > be solved optimally.. it is akin to the graph coloring
> > >> > problem - which ofcourse has heuristics that can get us to
> > >> > a factor (?) of the optimal solution. So, connections may
> > >> > be blocked even though there is capacity on the fiber to
> > >> > support it, just because the wavelength is already used up.
> > >> >
> > >>
> > >> Connections can be blocked when?? At service provisioning time or
> > >> at the time the connection is requested?? My point is a
> > >> connection of 2.48 Gbps is not likely to be a random event or an
> > >> ATM-like SVC. If a customer would require such huge bandwidth, it
> > >> would need that BW to go through or it would better look for
> > >> another carrier that will provide a TDM/leased line?? Of course
> > >> wavelength conversion can help build a better-utilized network,
> > >> no question about that.
> > >>
> > >> Khaled
> > >
> > >
> > >The exception to the rule that "a connection of 2.48 Gbps is not
> > >likely to be a random event" is where a very major event, possilble
> > >external to one's own network results in a shift in traffic patterns
> > >that is significant enough to require that additional lambdas be added
> > >to existing paths.
> > >
> > >The real world example in the ISP world is a failure of a peering
> > >point of some sort, a provider interconnect, a NAP or NAP connectivity
> > >of some party.  Since all major ISPs are connected to each other at
> > >more than one geographically diverse peering point, the traffic will
> > >still flow, but the path will have changed.
> > >
> > >This may mean that a path that previously required 3 lambdas (for
> > >example), now requires 4 lambdas.  There are at least 3 ways to
> > >accommodate this requirement:
> > >
> > >  1.  An external management system adds a lambda to both the routers
> > >      at either end and the optical switches (demonstrated at OFC).
> > >
> > >  2.  The router signals the requirement/desire for an additional
> > >      lambda to the adjacent optical switch which sets up a path.
> > >      This is the overlay model.  It can be trivially implemented with
> > >      MPLS by having the router send a loose source hop in the ERO
> > >      allowing the switch to create the path or reject the request.
> >
> > Curtis,
> >
> > Am trying to understand the model here. Does the overlay model
> > as you put above imply that the optical devices need to be mini-routers
> > in their own right? They have to be able to set up end-to-end optical
> > paths.. perhaps some kind of binding between the end-host IP address
> > and an addressing scheme for Optical devices.. ala ATM?
> > What does the overlay model entail?
>
> The optical devices run the same IGP (ISIS or OSPF) and use RSVP (or
> CRLDP) in a manner similar to the ATM UNI setting up an SVC.
>
> Alternately, the lambdas can be set statically and the edge router
> simple advertises a Lambda-Switch Capable link ala
> draft-kompella-mpls-optical-00.txt (if I understand their intent wrt
> accommodating the overlay model).
>
> I don't think draft-kompella-mpls-optical-00.txt has all the details
> sufficiently ironed out for the case where the optical switch
> advertises the availability of an optical link.  If it does, then the
> details ar just not clear to me.  (Could be my careless reading).
>
> > >  3.  The router has enough information about the characteristics of
> > >      the optical devices to compute the path and so it does so.  This
> > >      is the peer model.
> > >
> >
> > What does this model need.. a protocol for exchanging information
> > between the router and the optical device?
>
> It needs a means to communicate OOB wrt the primary lightpath.  That
> means would again be running the IGP and RSVP.  Based on reading the
> draft-kompella-mpls-optical-00.txt draft, I'm not clear on how the
> optical switch exchanges this information OOB although I would imagine
> that it would be quite easy to maintian another interface (perhaps
> even an electrical, though gig-E would do fine) between the router and
> optical device in which the optical device advertises the optical
> links.  The router on either end of an optical link, seeing or having
> set up a Packet-Switch Capable link would then have to bring up an
> RSVP adjacency over it, though I think it would not need an IGP
> adjacency.  (I'm not clear on this last point.)
>
> The availability of certain types of links (Packet-Switch Capable,
> Lambda-Switch Capable, Fiber-Switch Capable) as defined in
> draft-kompella-mpls-optical-00.txt would be advertised via RSVP.  I'm
> not clear on whether the adjacent LSR should advertise a Forwarding
> Adjacency PSC after RSVP comes up over a set of optical links (it
> seems to be the intent) but maybe the authors can clarify the usage.
>
> The ongoing discussion and the topic of the (way too numerous)
> framework documents floating around has been what additional
> information would be needed in order to provide adequate constraints
> to set up optical paths, a particularly difficult problem for
> transparent paths.
>
> > -jagan.
> >
> > >The way this might manifest itself is LSPs that might take an optical
> > >path from A to C are going from A to B to C because A to C lambdas are
> > >too full.  If so, then A could in principle request an additional
> > >lambda, but in practice the means to signal this has not been defined.
> > >
> > >Curtis
> >
> > Jagannath Shantigram
> > Photonex Corporation
>
> btw- I exchanged some private email with one of the authors of
> draft-kompella-mpls-optical.txt and owe them some detailed comments
> (appologies to them for the delay, busy).  After some brief discussion
> and after a second reading, the intent seems a lot more clear.  The
> usage material is at the end so when reading the document from front
> to back the intent is not clear until the end and then a second
> reading is required.
>
> Curtis
>

---

From: "Krishna Bala" <[email-masked]>
Date: Fri, 24 Mar 2000 17:04:12 -0500

Jonathan,
Point 1: Let me clarify the "open model".

Open refers to the fact that this model supports the interconnection of
several types of clients to an optical network (server layer).
Examples of Clients:
IP Routers, ATM Switches, SONET ADMs, "Direct Wavelength Services"

The open model also allows the interconnection of other Optical Network
Elements to
each other.
Examples of other Network Elements:
Optical Add/Drop Muxes, Other OXCs, Wavelength Selective XC, Wavelength
Interchanging XC

In general, since it offers the capability to support ALL services (not just
IP)
it is an Open Model.

Point 2: Overlay Model vs. Open

The connotation that goes typically with the Overlay model is that the
optical
layer is quasi static and might require N^2 connectivity at the IP/client
layer.
Hence, I prefer to distinguish the open model from overlay.
Krishna Bala

> From: [email-masked] [mailto:[email-masked]]On Behalf Of Jonathan
> Lang
> Sent: Thursday, March 23, 2000 4:55 PM
> To: 'Krishna Bala'; [email-masked]; Jagan Shantigram

---

From: Tony Li <[email-masked]>
Date: Sat, 25 Mar 2000 13:48:50 -0800

> Elements to each other.
> IP) it is an Open Model.

The distinction that you make between the Open Model and the Peer Model is not
clear to me.

Certainly both models will support all services.  Both models should be using IP
as the basis of their routing and signalling protocols.

What is the substantive basis for a difference?

Tony

---

From: "Sid Chaudhuri" <[email-masked]>
Date: Mon, 27 Mar 2000 09:24:42 -0500

You may be right that both models can support all services provided
signaling and routing are IP-based.  However, there are two fundamental
differences between the Open and the Peer model: (1) In OPen model if an
operator wants to offer "optical Pipe" services regardless what svc is
carried within the pipes the operator would not like to share all its
network resource information to its clients.  Therefore what is needed for
information exchange between the client NE and the optical network is a
standard interface defining the minimum set of required parameters without
sharing optical netrwork resource info with the clinet NE.  That is what UNI
spec being developed by OIF. (2)We do not need to impose the routing and
signaling protocols to every client network elements for providing the
optical layer services.  Al they need to adhere to is the simplie UNI spec.
Rest is done by the optical layer using IP signaling and routing.  The
driver for using IP routing and signaling in the optical layer is simply
because these are well developed and well suited for the optical layer
functions and there is no need to reinvent the wheel.  Also, when
multi-vendor optical networks are to work together other protocols such as
BGP can be easily adopted.

S0 unless we assume that all services to be provided by an optical network
(inclcuing pipe svc) are accessed via routers that are within the opretor's
domain the peer model by itself is unworkable and once we have the open
model the need for peer model is diminshed to almost naught.

Sid

> From: [email-masked] [mailto:[email-masked]]On Behalf Of Tony Li
> Sent: Saturday, March 25, 2000 4:49 PM
> To: Krishna Bala
> Cc: Jonathan Lang; [email-masked]; Jagan Shantigram; Khaled Elsayed;
> [email-masked]; [email-masked]

---

From: Jagan Shantigram <[email-masked]>
Date: Mon, 27 Mar 2000 10:13:37 -0500

Krishna,

It seems like the above just described what people understand
by the overlay model. In this model the optical layer presents
itself as a layer that can provide a bunch of services to the
upper data/IP layer. These services could include point
to point clear channel, 1+1 protection, negotiable bandwidth
etc.. (just to give examples). How the optical layer
achieves these services is yet to be determined - which as you
mention will require standardized interfaces between the various
optical components and as well as a standardized API for these
services to be requested.

My question is what are these services that would be useful
for the optical layer to provide and what are the tasks that
have to be taken up to enable it?

In any case it seems risky to take up a model that requires
too much cooperation between the various layers - since that
will mean that there will be inter-dependence in the development
of that technology. Ofcourse there are others who have more
experience on questions like this.

>layer is quasi static and might require N^2 connectivity at the IP/client

Am afraid I missed the point here.

thanks,
-jagan.

Jagannath Shantigram
Photonex Corporation

---

From: "Krishna Bala" <[email-masked]>
Date: Mon, 27 Mar 2000 18:24:01 -0500

Jagan,
Just to beat a dead horse .. the difference between the open model
and the overlay is just that the overlay model typically suggests that
there would be N^2 connectivity (i.e., every router, for instance, is
statically connected to every other). In any case, the open model allows
for fully dynamic operation. The overlay model suggests static operation of
the optical layer.

As I see it there are only two architectures that are worth considering:
1. Peer
2. Open

I agree with you that there is no need to add the "overlay" model to
this list. The open model covers the static and the dynamic cases.

Krishna

> From: Jagan Shantigram [mailto:[email-masked]]
> Sent: Monday, March 27, 2000 10:14 AM
> To: Krishna Bala; Jonathan Lang; [email-masked]

---

From: "James V. Luciani" <[email-masked]>
Date: Mon, 27 Mar 2000 18:41:54 -0500

> and the overlay is just that the overlay model typically suggests that

That depends... see below.

> statically connected to every other). In any case, the open model allows

While there may indeed be some misunderstanding as to the meaning of the
"overlay model" (not to mention the meaning of the other models :-)), the
traditional definition of overlay is not one of static operation.  NHRP and
MPOA, for example, are overlay in my book (and most folks that I know).
They most certainly imply non-static connections by defintion (i.e., use of
SVCs).  This having been said, I believe that we can do one of two things
here.  One, keep the current terms and potentially risk an ad nauseum
inspection of the meaning of these terms; or two, come up with a term which
is satisfactory to all.  In the second case we would have models:
1) X
2) Peer
where X is the PC term for what we want to get at.  So my opine is that
X="augmented routing model"/ARM model.

Do I hear a hmmmm???
--Jim

---

From: Jagan Shantigram <[email-masked]>
Date: Mon, 27 Mar 2000 19:27:47 -0500

>this list. The open model covers the static and the dynamic cases.

o-oh.. I wasn't suggesting that we do away with the term "overlay"
at all.. But, your preference is noted ofcourse.

Additionally - from my reading it did not seem that "overlay" implies
static operation, or even a full connectivity between routers - N^2
as you mentioned. I was looking at some really old(?) IP/ATM debates
and it seems like the term overlay/peer were used there as well and
if I may, the debate was not much different either.

In any case I do think that the parameters and the trade-offs are
different than in the case of IP/ATM. I would like to see more discussion
on that so that we can draw a more educated line between those two
models in IP/Optical scenario. For example questions like - addressing,
dynamic path establishment, router/router-like behavior of optical
devices, L2-switch-like behavior of optical devices etc.. While the
questions seem to be the same as when people were discussing how IP
should be carried on ATM - will the answers be different in this
case?

One answer could be to let optics be stupid and simple and provide
point to point connectivity - just the plain-old-transport-network?
While we may be able to guarantee the behavior and correctly define
the network in that case - it will probably not use the current
technologies of configurability of wavelength paths and the
ability to condense more and more high speed interfaces into a single box
along with the switching intelligence that is required to make it
powerful.

-jagan.

Jagannath Shantigram
Photonex Corporation

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 27 Mar 2000 16:31:48 -0800

Jim,
 
> X="augmented routing model"/ARM model.

I think you do. And it comes from you - it is your own hmmm.

Yakov.

---

From: Grenville Armitage <[email-masked]>
Date: Mon, 27 Mar 2000 17:45:47 -0800

> for fully dynamic operation. The overlay model suggests static operation of

This isn't the definition of "overlay model" that has been used in
the IETF for awhile. Static linking of all routers" is simply one
instantiation. The key differentiator of an overlay model is the
topological independence of the underlying and overlaying 'layers'.
E.g. in an earlier century we talked about IP/ATM overlay models where
the IP topology was logical wrt the switch-link topology of the
underlying ATM network. The connectivity itself was static, soft,
or dynamic as needed - however, the model was 'overlay' in each case.

cheers,
gja
________________________________________________________________________
Grenville Armitage                    http://members.home.net/garmitage/
Bell Labs Research Silicon Valley

---

From: Tony Li <[email-masked]>
Date: Tue, 28 Mar 2000 00:48:31 -0800

> BGP can be easily adopted.

Based on this, the difference is that you're emphasizing is the use of another
protocol at the edge of a service providers network.  If this is an accurate
assesment of your position, then it would behoove us to distinguish between the
intra-domain model and the inter-domain model.

For example, one could reasonably say that the MPLS/TE model is currently a peer
intra-domain model and that we've completely blown off the inter-domain model.
So far, this seems to have a reasonable amount of appeal to the customer base.

> model the need for peer model is diminshed to almost naught.

If I follow that logic, it is impossible to get any services if multiple domains
exist.  I think the Internet is a small counterexample.

Regards,
Tony

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 28 Mar 2000 10:19:02 -0500

> this list. The open model covers the static and the dynamic cases.

In terms of visibility into the optical layer and control over path
selection, the proposals on the talbe can be characterized as follows:

  1.  Static Overlay Model - paths endpoints are specified through a
      network management system though the paths may be laid out
      statically (by the NMS system) or dynamically (by the network
      elements).  This is similar to ATM PVCs and SPVCs.

      [Note: networks built using the overlay model need not provide a
      full mesh contrary to misinformation provided on this mailing
      list.  Today ATM PVC based IP backbones are often not built as
      full mesh networks to reduce the nuber of routing adjacencies.]

  2.  Signaled Overlay Model (aka "Open" model) - paths endpoints are
      specified through signaling via a UNI.  Paths must be laid out
      dynamically since they are specified by signaling.  This is
      similar to ATM SVCs.

  3.  Peer model - The network elements are provided enough
      information such that they MAY attempt to set up path in
      addition to specifying their endpoints.  Paths may be laid out
      by the optical elements if the edge LSR provides only a static
      hop.  Paths may be laid out by the LSR.  Paths may also be laid
      out statically by having the NMS system configure explicit paths
      on the LSR and have those paths signaled.

It was my understanding that the MPLS WG traffic engineering work was
motivated largely by major Internet service provider's experience with
ATM and was making an effort to avoid repeating the mistakes of the
ATMF and therfore (among other differences between ATM and MPLS) is
interested in the peer model.  

Note - If the OIF wants to ignore the experience that the Internet
community has had with ATM and wants to ignore the feedback through
the IETF of people involved in building those networks and and build
IP routers with ATM interfaces that were constrained to make use of
the interfaces that the ATMF chose to provide (in some cases omiting
capabilities over the loud objections within IETF WGs such as IP over
ATM) then that is a matter for OIF.

If we are putting together a framework, then in addition to the
"static overlay model" and "peer model", a distinction should be made
and a separate "signaled overlay model" can be provided.  In the
interest of completelness the framework can point out that the OIF is
working on a UNI which is based on the signaled overlay model.

I prefer the term "signaled overlay model" over "open model" because
the former is descriptive and that latter seems motivated by the
desire to use the marketing buzzword "open" rather than provide a
descriptive term.

Some people had envisioned going directly from static overlay model to
peer model or going directly to the peer model with the understanding
that the LSR can still be configured with explicit paths from an NMS
as long as quantifying and signaling impairments remains slightly
beyond the state of the art and determining the impact of optical
impairments remains a black art.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 28 Mar 2000 10:21:20 -0500

In message <009e01bf9846$0cc47ec0$a4d0fea9@jluciani>, "James V. Luciani" writes
> X="augmented routing model"/ARM model.

cough.

---

From: "James V. Luciani" <[email-masked]>
Date: Tue, 28 Mar 2000 23:25:11 -0500

Yakov,
   Wow,  such rapier-like wit and technical depth all wrapped in a
one-liner.  Now if you would like to help clarify the issue rather than
snipe at someone who is trying to be helpful, I for one would like to hear
your input.
--Jim
----- Original Message -----
From: Yakov Rekhter <[email-masked]>
To: James V. Luciani <[email-masked]>
Cc: Krishna Bala <[email-masked]>; Jagan Shantigram <[email-masked]>;
Jonathan Lang <[email-masked]>; <[email-masked]>; Khaled Elsayed
<[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Monday, March 27, 2000 7:31 PM
Subject: Re: Comments on draft-ip-optical-framework-00.txt

---

From: "Krishna Bala" <[email-masked]>
Date: Wed, 29 Mar 2000 02:26:33 -0500

Jim,
Hmm!

The OIF is using the terms
1) Peer
2) Open

So, if possible ... so as to avoid creating yet another term for
the same thing (X in this case) I suggest we call it "open".

Krishna

> From: James V. Luciani [mailto:[email-masked]]
> Sent: Monday, March 27, 2000 6:42 PM
> To: Krishna Bala; Jagan Shantigram; Jonathan Lang; [email-masked]
> > > >> The optical layer is "fat & dumb". The lamda connections
> between the
> IP
> > > >> > > >> connection of 2.48 Gbps is not likely to be a
> random event or
> an

---

From: Grenville Armitage <[email-masked]>
Date: Tue, 28 Mar 2000 23:50:05 -0800

The OIF's use is hardly compelling. Curtis makes a good
observation that the word "open" isn't particularly descriptive
in this context. Are you *sure* you aren't really talking about
a form of overlay model (as clarified)? The word "overlay" (with
or without "signaled" as Curtis suggested) seems to be more
descriptive (naturally, IMHO).

cheers,
gja

> the same thing (X in this case) I suggest we call it "open".
	[..]

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 29 Mar 2000 12:42:33 -0500

In message <007a01bf9936$ca31ac80$3c03fea9@jluciani>, "James V. Luciani" writes

Jim,

Maybe Yakov just didn't like the suggested term "augmented routing
model".  I certainly didn't.

I suggested that we make the distinction between "static overlay" and
"signaled overlay".  What you describe as X would be signaled overlay.

Curtis

btw- NHRP and MPOA might be bad examples.

---

From: Yakov Rekhter <[email-masked]>
Date: Fri, 31 Mar 2000 06:39:27 -0800

Curtis,

> model".  I certainly didn't.

Yes, that was my point.

> "signaled overlay".  What you describe as X would be signaled overlay.

Agreed.

> btw- NHRP and MPOA might be bad examples.

just brain-damaged....

Yakov.

> > > > They most certainly imply non-static connections by defintion (i.e., us
e
> > of

---

From: Yakov Rekhter <[email-masked]>
Date: Fri, 31 Mar 2000 07:04:14 -0800

Grenville,

Agreed.

Yakov.

---

From: "Krishna Bala" <[email-masked]>
Date: Fri, 31 Mar 2000 10:56:14 -0500

Gja,
Yes, the "signaled overlay" and the "open" model are the same.
In terms of the "signaled overlay model" vs. "open" ... The open
model (the term itself) is well understood by people coming from
an optical networking background ... and I am sure that "signaled 
overlay" makes more sense to folks from the IP world.

In either case ... they are the same thing. 

Krishna

> From: Grenville Armitage [mailto:[email-masked]]
> Sent: Wednesday, March 29, 2000 2:50 AM
> To: Krishna Bala
> Cc: [email-masked]; [email-masked]

---

From: "Krishna Bala" <[email-masked]>
Date: Fri, 31 Mar 2000 10:56:06 -0500

Curtis,
I agree with most of your comments. Thanks for the clarification
on the Overlay Model also.
Yes, the "Signaled Overlay Model" is what I am calling the "Open Model".

Couple of Comments:
1. The OIF is not going to ignore the input of the internet community.
The fact that we (atleast Tellium and Sycamore .. I cannot comment for
the others) have stated clearly that they are going to use OSPF for routing
and MPLS for signaling at Layer 1! I think this suggests that we
are already in agreement with the IP community. We would like to
be a part of a multivendor IP Optical Network.
2. Regarding the marketing use of the term "Signaled Overlay Model"
versus the "Open Model". I am not sure how the term "Open" came to be used
among the "optics" community ... but it conveys the intent what we
are trying to accomplish, i.e., the interconnection of multiple network
elements and services to an Open optical layer that supports a multiplicity
of services (e.g. IP, Direct Wavelength, TDM, ATM.

Krishna Bala

> From: Curtis Villamizar [mailto:[email-masked]]
> Sent: Tuesday, March 28, 2000 10:19 AM
> To: Krishna Bala
> Cc: Jagan Shantigram; Jonathan Lang; [email-masked]; Khaled Elsayed;

---

From: "Krishna Bala" <[email-masked]>
Date: Fri, 31 Mar 2000 13:02:38 -0500

Tony,
In the extreme cases there need not be any distinction between the
peer model and the open models.

The peer model can clearly support the case where there are well defined
interfaces
to an optical network element and also between optical network elements.
The open model also can support the peer model.

However, in the general case these models are based on fundamentally
different
assumptions:
1. The peer model is based on the assumption that the IP router has full
visibility
into the optical layer. It is able to make wavelength assignment decisions,
it
can route lightpaths based on physical layer impairments (e.g. accumulated
SNR,
PMD, delay, fiber non-linearities ...). I strongly question the basis of
this model.
Yes, I concede that there is nothing that prevents the peer model from
supporting
the open model. But, I am not in agreement with the fundamental premise upon
which
this model is based. I think it is a mistake to assume that the IP router is
going to have such visibility into the optical layer ... at least initially.

2. The open model is based on the assumption that any "client" (e.g. IP
router,
ATM switch, direct wavelength services) can be supported over an optical
layer
that comprises network elements from multiple vendors via the use of well
defined
interfaces. The UNI from the client to the optical layer and the NNI between
the
optical network elements. Again, the open model clearly supports the peer
model also.
I believe that the open model allows us to start early and immediately
with something that gets us going in the right direction without all of
complications involved with the peer model.

Fundamentally I agree with you that each model can support the other. But in
practice
I do not see how we can achieve any interoperability without keeping it
simple
initially.

Krishna

---

From: Bala Rajagopalan <[email-masked]>
Date: Fri, 31 Mar 2000 19:25:41 -0500

There is one aspect missing in your description below. That is,
how routing information is passed between IP and optical
domains. Overlay models, static or otherwise, have no routing
protocol running between the two domains (IP and ATM or
in this case, IP and optical). The intent of the "open" model
(call it by another name if this isn't
suitable) is  to allow a
routing protocol to pass limited information between domains,
for example, reachability, and define standard signaling for
provisioning and (perhaps) restoration.

The real issue is to identify the service requirements at
the IP-optical interface. Currently, we see dynamic provisioning,
reachability determination and restoration as requirements.
None of these require passing detailed topology between
domains. If there are other specific operational requirements,
it'll be good to know about them.

regards,

Bala

--

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]