Subject: RE: Optical IP activities

From: John Drake <[email-masked]>
Date: Fri, 17 Mar 2000 09:38:23 -0800

Bala,

I think that the extensions outlined in draft-kompella-mpls-optical-00.txt
and draft-lang-mpls-rsvp-oxc-00.txt are either straightforward
generalizations (e.g., additional label types) or of general utility (e.g.,
bi-directional LSPs).

Clearly, there are requirements to support the peer model, so I don't think
we should continue to debate whether it is a good idea or not.  What you're
describing as your personal preference is the overlay model, and we've seen
the limitations of it in the context of ATM.

Thanks,

John
-----Original Message-----
From: Bala Rajagopalan [mailto:[email-masked]]
Sent: Friday, March 17, 2000 8:53 AM
To: John Drake
Cc: Yakov Rekhter; [email-masked]; [email-masked]; Luc Ceuppens
Subject: Re: Optical IP activities

Hello:

Looking at all the drafts on RSVP and CRLDP "extensions" for
optical networks, and the issues outlined in draft-rstb-optical-signaling-
framework-00.txt, we already have sufficient reason
to believe that optical networking signaling has many features which
are different from signaling within an IP network. Which is why
the "single instance" model is not very clear to me.

Also, it is possible to export any sort of information from within an
optical cloud to outside, but whether this makes life easier in any
manner is not clear. In fact, my personal preference is a clean interface
between
IP and optical networks while isolating the idiosynchracies of
each. This can still be a peer model with limited information
exchange.

Regards,

Bala

John Drake wrote:

> Bala,
>
> In the network model proposed in draft-ceuppens-mpls-optical-00.txt, the
> DWDM equipment, with its associated line systems, would measure various
> optical performance parameters, some of which are suggested in the draft.
> There would then be a standardized protocol, perhaps based on LMP
> (draft-lang-mpls-lmp-00.txt), which would be used to transfer these
> measurements from the DWDM system to the PXC.
>
> The PXC then synthesize these measurements and report them in link state
> updates, encoded as new TLVs.  Source nodes, either PXCs if the overlay
> model is used, or routers, if the peer model is used, could then take this
> information into account when computing routes.
>
> However, since the source has already computed the route, it doesn't seem
as
> though signalling has to be modified.
>
> Thanks,
>
> John
> -----Original Message-----
> From: Bala Rajagopalan [mailto:[email-masked]]
> Sent: Thursday, March 16, 2000 3:38 PM
> To: Yakov Rekhter
> Cc: [email-masked]; [email-masked]
> Subject: Re: Optical IP activities
>
> Yakov Rekhter wrote:
>
> > Agreed.
> >
> > And to address this I would suggest we'll add the following to the
> > WG charter:
> >
> >    Use of MPLS control plane with OXCs should allow two basic
> >    architectural options:
> >
> >     - One option is to use different instances of the control plane
> >       in the OTN (OXC) and IP (LSR) domains. In this situation, each
> >       instance of the control plane will operate independent of the
> >       other.
> >
> >     - Another option is to use a single instance of the control
> >       plane that subsumes and spans LSRs and OXCs.
>
> Given the specific requirements in optical networks (leading to possibly a
> different
> flavor of signaling procedures), I'm not sure what the "single instance"
> model
> means.
>
> 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]

--

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: Bala Rajagopalan <[email-masked]>
Date: Fri, 17 Mar 2000 14:00:30 -0500

Hello:

> generalizations (e.g., additional label types) or of general utility (e.g.,

Sorry to prolong the agony, but all extensions proposed so far are
straightforward.
But taken together, we have established a different signaling environment.
Here, labels are interpreted differently, bi-directionality is introduced (which

was not there at all previously), reliability is a big deal, new
restoration-related
features introduced, and we're not even sure this is the end of it.
Indeed, now that we have a number of  "extensions", I'd like to see an
enumeration
of what can be thrown out the basic RSVP or CR-LDP in the optical
network setting (of course, I'm too wimpy to say in open that RSVP
soft state model is no good for optical networks).
To summarize, I think "the single instance" model is a bit of a stretch.

> the limitations of it in the context of ATM.

Just curious, I'm not sure whether any "requirements" for peer model
have been articulated anywhere. I've seen desires or opinions expressed.
(Of course, under the rough consensus model,
strong opinions become working group requirements), but
are there any real requirements? If so, where are they coming from?

Also, I didn't advocate an overlay model, but only a preference to limit
the amount of information exchange between the IP and optical sides.

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]

---

From: Yakov Rekhter <[email-masked]>
Date: Fri, 17 Mar 2000 11:32:22 -0800

Bala,

> Here, labels are interpreted differently, bi-directionality is introduced 
> which was not there at all previously), reliability is a big deal, new
> restoration-related

As John suggested, let's look at the extensions described in
draft-kompella-mpls-optical-00.txt and draft-lang-mpls-rsvp-oxc-00.txt,
and examine some facts (rather than claims):

1. Link Type sub-TLV - this is useful in non-optical domain as well
2. Link Media Type sub-TLV - this is optical-domain specific
3. Path sub-TLV - this is useful in non-optical domain as well
4. Share Risk Link Group TLV - this is useful in non-optical domain as well
5. The concept of forwarding adjacency - this is useful in non-optical domain
   as well
6. Link Media Type in the Label Request object - this is optical domain
    specific
7. Failure notification/Notify message - this is useful in non-optical domain
   as well
8. Bi-directional LSP - this is useful in non-optical domain as well
9. Label suggestion - this is optical domain specific.

So, out of 9 items we have 3 items that are specific to optical domain.

> soft state model is no good for optical networks).

Please spare the rest of us the "soft vs hard" religious debate. 

Yakov.

---

From: "Peter Ashwood-Smith" <[email-masked]>
Date: Fri, 17 Mar 2000 14:39:47 -0500

> soft state model is no good for optical networks).

  As somebody with a strong opinion on this, let me be the first to
propose that we try to keep optical stuff above the RSVP/CR-LDP
debates. Clearly we want to signal optical cross connections for
fibers, wavebands, wavelengths and timeslots and these requirements
can be functionally met by either protocol. We will make more progress
if we can concentrate on WHAT we are shipping about and WHAT it means
rather than how it gets there.

> the amount of information exchange between the IP and optical sides.

  I can't resist. That's a bit like saying "we want to limit the amount of
information exchange between IP and the electrical sides". Everytime you
catch yourself talking about optical in a "special" sense, turn the
phrase around and replace "optical/light" with "electrical/electricity" and
see if it makes sense. For example "IP on light" becomes 
"IP on electricity" ;)

  As far as topology abstraction is concerned, we abstract topology 
because we have to, not because we want to. We may need to abstract 
because the size is simply too large and N^2 unmanagable. We may need to
abstract because the other domain administration simply won't exchange
information with us, or, with ATM, we need to abstract because the 
two formats are incompatible.

  We will almost certainly treat optical LSRs the same way. We will
abstract them and their links for size / scalability reasons, for
administrative reasons and possibly (if we evolve many protocols that
can talk optical MPLS) for incompatibility reasons ;) 

  Abstraction in general is not good for traffice engineering. The further
you get from knowing exactly how much bandwidth you have and where it is
the worse the job of computing, establishing and laying down routes you 
can do. The more accurately the topology database reflects exactly the
resources you have to allocate, the more accurate a job you can do of 
engineering your network. 

  Cheers,

  Peter

---

From: Bala Rajagopalan <[email-masked]>
Date: Fri, 17 Mar 2000 15:06:33 -0500

Hello:

> So, out of 9 items we have 3 items that are specific to optical domain.

What does this really say? That 6 items were invented suddenly to cater to
non-optical needs? All 9 were motivated by optical needs, and presumably
will be used only in optical networks in the near future. Or, are you suggesting
that  RSVP implementations outside optical networks will be changed
to put to use the 6 items that have general use?

Now, let us look beyond draft-kompella and see what we have in
draft-rstb-signalling...
and draft-saha-rsvp-...  These cover specific objects for restoration, protection
and the soft state model. And, these are specific to optical network needs.

> Please spare the rest of us the "soft vs hard" religious debate.

I'm not surprised by this knee-jerk reaction. I expected that it would
be hard to talk about this issue objectively even within the limited scope
of optical signaling needs.  Perhaps I should say "refresh-reduced"
instead of "hard state"?

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: Yakov Rekhter <[email-masked]>
Date: Fri, 17 Mar 2000 12:11:22 -0800

Peter,

Agreed.

> engineering your network. 

Well said.

Yakov.

---

From: Yakov Rekhter <[email-masked]>
Date: Fri, 17 Mar 2000 12:18:57 -0800

Bala,

> will be used only in optical networks in the near future. Or, are you 
> suggesting that  RSVP implementations outside optical networks will be changed

That will be determined by customers.

> and draft-saha-rsvp-...  These cover specific objects for restoration, 
> protection and the soft state model. And, these are specific to optical 
> network needs.

As I said before, one could make this as different as one want
from MPLS. The Internet Drafts you mentioned certainly seems like
trying to accomplish this.

Yakov.

---

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

Hello:

> rather than how it gets there.

I believe the point was different. Whatever you do (a version of RSVP
or CRLDP), whether you are essentially catering to a different set of
requirements inside an optical network. In that regard, you may not
only want to add "extensions", but may also find that you're either not
using "standard" features or finding out some features to be
inappropriate.

> see if it makes sense. For example "IP on light" becomes

Not quite. There are specific operational procedures inside an optical
network and the question is how much of this must be characterised
to the outside world. For example, should a router know about wavelength
conversion limitations?

> can talk optical MPLS) for incompatibility reasons ;)

Precisely.

> engineering your network.

The question is, whether in practice you would engineer paths across
two different networks (IP and optical) or do the engineering (and
capacity planning) in each network.

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: Bala Rajagopalan <[email-masked]>
Date: Fri, 17 Mar 2000 15:56:27 -0500

> trying to accomplish this.

In all earnestness, there is no intent or desire to do something deliberately
"different". As an optical vendor, we're trying to solve specific problems
and raising real issues. These may not match abstract views, ideologies,
or opinions expressed in other drafts. Too bad.

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: "Peter Ashwood-Smith" <[email-masked]>
Date: Fri, 17 Mar 2000 16:15:02 -0500

> using "standard" features or finding out some features to be

  What has happened is a general realization that no matter what we 
switch on, be it spacecial (fiber), time (TDM), frequency(lambda) or 
shim (statistical), the requirements on the signalling and routing
protocols are VERY similar with variations caused by certain physical
properties of each switching mechanism. These variations are probably 
not sufficient to warrant completely independent protocols. About the
most serious of these differences is the merge/non merge ability and
even that existed in the statistical (ATM) domain. As a result we are 
in the process of rationalizing and distilling out what the common 
properties are of all of these mechanisms and trying to build a common 
mechanism to deal with them all. We may or may not succeed however
since we rarely all agree on anything.

> to the outside world. For example, should a router know about wavelength

   Wavelength conversion limitations can be abstracted into constraints
we already deal with in existing constraint based routing systems like
ATM/PORS. For example, maximum reach is similar to maximum acceptable delay.
If we can find generic ways to express the constraints that optics imposes
a generic constraint based routing system should be able to deal with 
the problems. Besides, the constraints imposed by current optical 
technologies are being stretched every day. Reach, for example, gets 
longer and longer every year and may one day be a non issue.

   Even constraints like the desire to limit the number of wavelength
conversions to a minimum to reduce distortion/chirp, or even to reduce to
a single wavelength for equipement that cannot do a conversion, can
be expressed in abstract forms such as a label set, as in the draft-yanhe
or a suggested label as in the lang draft. Are these specific to the
optical domain? Probably, although one can see the immediate benefits
of a fixed shim label for a span of hops since it reduces read/write
operations and hence would improve forwarding performance in the
statistically multiplexed domain.

> capacity planning) in each network.

   I argue that given the choice you would pick one network since a
single level global/distributed optimal placement problem is "easier" to 
solve than a two level global/optimal placement problem. Actually I 
think the two level problem is unsolvable because it lacks exact 
data at the second level. A fact I'm sure many operators of existing
overlay networks will attest to.

   Cheers,

   Peter

---

From: Debanjan <[email-masked]>
Date: Fri, 17 Mar 2000 17:20:07 -0600

Peter, 
 
> statistically multiplexed domain.

I am sure you can abstract physical limitations/properties and use them
as
constraints in routing algorithms. The real issue here is whether you
want
all the routers to know about these "optical constraints"
(distortion/chirp,
wavelength conversion capability). The other option would be to keep
these
two domains separate and use an abstraction where the routers view the
optical 
network as a cloud (overlay model). I'm not sure which one is the better
approach
and think that we need a better understanding of the optical networks
and their
specific requirements to make that determination.

Debanjan