Subject: RE: Optical link bundling. Was Re: Draft Minutes From Pittsburgh

From: [email-masked]
Date: Thu, 19 Oct 2000 00:08:15 +0100

Alex Zinn wrote:
>I wouldn't oversimplify this [NH=> that is, against this statement from
Yangguang "In circuit switched network, there should be no assumption about
the relation of data plane topology and control plane topology at all."]
	Don't forget about IGPs and signaling.

Alex can you please expand on what you mean by this....taking the following
into account line of reasonong?

-	the OTN is cct-sw/CO/client-layer PDU-structure transparent
-	the OTN has no practical buffers
-	IP, ATM, FR, SDH, or whatever is irrelevant as far as the OTN
user-plane is concerned.
-	"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.
-	above implies no congruent addressing between any pair of client
layers or any client layer and the OTN........this implies that the
addresing scheme used by the OTN is not related to any clients (ie not from
the same addressing space in terms of possible trail connectivity at layer
network access points)
-	it therefore follows (at least to many I speak to who are working on
OTN topics) that the signalling protocol and the routing/discovery protocol
used in the OTN can be chosen as 'best of breed' to suit its nature, ie
cct-sw/CO/user-plane transparent.  Obviously different people will have
different views of what is best-of-breed here.......and this has not to my
knowledge has not even been openly debated so far.
-	further, the signalling network of the OTN needs to be designed with
very high availability/survivability requirements.  To achieve this its
topology and operating mode are a completely independent facet to how the
user-plane is specified for the normal 'client traffic'.

regards, neil

---

From: Alex Zinin <[email-masked]>
Date: Wed, 18 Oct 2000 17:02:05 -0700

Neil,

> into account line of reasonong?

I believe it was explained in the thread quite thoroughly already.
In short, we have protocols in the generalized MPLS control plane
that will not work over a TCP connection, but will require direct
connectivity (through a physical link, LSP, or a GRE tunnel) between
boxes.

See my comments below as well.

> -       the OTN has no practical buffers

There's no requirement for buffering of transit traffic.
However, in the case where control channels are allocated
from the same pool of fibers (or lambdas), an optical box
will have to be able to terminate them. This is also a requirement
if you want to implement LMP link testing.

> -       IP, ATM, FR, SDH, or whatever is irrelevant as far as the OTN

Well... If you use OTN in the overlay model with no dynamic
circuit provisioning, then yes. If OTN is a part of your network
(i.e., peer model is used) or if dynamic lightpath provisioning is required,
then IP becomes very much relevant, since (as far as we are talking about
generalized MPLS or MPLambdaS) OTN nodes are going to use IP/MPLS-TE control
plane (or its rudimentary version in case of UNI).

> time...including some large BW servives directly off the L1 fabric.

Not sure I follow the logic here. Can you elaborate a bit.

> the same addressing space in terms of possible trail connectivity at layer

Correct.
It does not mean, however, that we need to invent another
addressing system.

> knowledge has not even been openly debated so far.

I believe it has been discussed in a number of forums for quite
a long time by now and the de facto consensus is that MPLS-TE control
plane with required extensions is the one to go with, where
one of the reasons is the presence of implemented and standardized
protocols and interoperability.

It does not mean, of course, that somebody can develop their own
set of proprietary protocols ;)

> very high availability/survivability requirements.

Right, and this is what IP routing provides us with.

> To achieve this its

Correct, but again, this does not mean we have to invent another
set of protocols.

Regards,

Alex.

---

From: Yangguang Xu <[email-masked]>
Date: Wed, 18 Oct 2000 22:49:50 -0400

Alex,

I thought about it. It's actually not true. 
> connectivity (through a physical link, LSP, or a GRE tunnel) between

Our only concern is OSPF. For example, the transport plane is as below.

       A------------B
       | \          |
       |  \         |
       |   ------\  |
       |          \ |
       C------------D

The control plane can be:

       A------------B
       |
       |
       |
       C------------D

Optical topology are discovered by LMP and disseminated through OSPF Opaque LSA.
Even A and D has no direct connectivity in control plane, it still can get
optical topology through C.

I guess I shouldn't say TCP session (what I was thinking???). They only need IP
reachability. This is true for both OSPF and LMP.

Yangguang

---

From: Alex Zinin <[email-masked]>
Date: Wed, 18 Oct 2000 20:26:57 -0700

Yangguang,

> I thought about it. It's actually not true. 

The whole thing is not true or something in particular? ;)

> Our only concern is OSPF. For example, the transport plane is as below.

[...]

> optical topology through C.

Just in case below ;)

> Wednesday, October 18, 2000, 11:05 AM, Alex Zinin <[email-masked]> wrote:
>> Yangguang,
>> One thing that seems interesting to me in the context of optical
>> networks is potential possibility to prune the topology of IGP
>> adjacencies to minimally necessary (e.g., redundant spanning tree),
>> while still announcing TE information about all optical links.
>> The state of the links would be defined with protocols like LMP
>> or mechanisms integrated into lower layers. This is possible
>> because in case of p2p links (valid for ONs), we do not use
>> IGP topology database for CSPF. However, we do use it in other
>> networks when calculate the paths through multi-access segments.

Note, however, that a) no connectivity between A & B, b) direct
connectivity between A & B and c) a TCP session between A & B
are three "a bit" different things.

Also note, that this quite realistic to imagine a box with gmpls
control plane but without LMP.

Alex.