Subject: Re: Draft Minutes From Pittsburgh

From: "Frank Hujber" <[email-masked]>
Date: Tue, 17 Oct 2000 16:49:02 -0400

Bala, Kireeti, et al,

My perspective is naive, but as I understand it, the current proposals
require a control link to "overlay" an optical link exactly, and for the
control path(s) to be associated with groups of optical links according to
their characteristics (i.e. bandwidth - OC-48 vs OC-192).

Some of us in the optical world, growing from the telephony (SONET/SDH)
world do NOT assume that this overlay occurs. We prefer to offer the
provider (in my case, my customer) to have management networks that are not
the same as the transport networks. This is because in-band signaling is not
yet available (though OIF is working on it) and because providers may not
want to dedicate a wavelength to relatively low-speed management traffic.

I'm new to this forum, and I'm sure this was explained months ago. So if
this is repetitious, I apologize.

Frank Hujber
[email-masked]

---

From: [email-masked]
Date: Wed, 18 Oct 2000 09:58:19 -0500

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, October 18, 2000 7:12 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: Draft Minutes From Pittsburgh
> 
> 
> Kireeti, et al,
> 
> Consider three routers as a small segment of a larger optical 
> network, A, B,
> and C. A and B areOXCs and are directly connected by a DWDM 
> with some number
> of lightpaths. However, their control plane connection is 
> through C, which
> is a pure IP router, not an OXC. We've made the (painful) 
> assumption that
> the customer/provider has such demand for his lightpaths that 
> he does not
> want to sacrifice a wavelength for control. It would seem 
> possible to manage
> optical links A-to-B with a LSP A-to-C-to-B as along as A and 
> B knew their
> optical connectivity and C knew that it was not part of the 
> optical path.

Keereti, Yuangguang, Frank, 

Isn't this precisely out-of-band non-associated signaling?
(The signaling between OXCs A and B happens via an LSP that goes
through C, and does not share resources with the data channel [fibers,
lightpaths] between A and B, so it's out of band.
 Moreover, the topology of the signaling
path does not coincide with that of the data path, so the signaling
path is "not associated" with the data path.)

Thanks,
-Vishal
> ----- Original Message -----
> From: "Kireeti Kompella" <[email-masked]>
> To: <[email-masked]>; <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>
> Sent: Wednesday, October 18, 2000 12:58 AM
> Subject: Re: Draft Minutes From Pittsburgh
> 
> 
> > Hi Yangguang,
> >
> > > One implication Frank hinted is that:
> > >
> > > For A----B, even there could be many bundles between A 
> and B, there
> needs only
> > > one control channel (no need for physical channel, a TCP 
> session is
> enough)
> > > between them. Bundle in circuit network is different from 
> "interface" in
> IP
> > > network in the sense that a bundle can be included in one 
> LSA, but only
> send to
> > > neighbor once.
> >
> > You have a good point.  In section 3.2 of the bundling document, it
> > says that a bundle must have a control channel, but is not very
> > clear that multiple bundles can share a control channel.  We will
> > make this clearer in the next revision.
> >
> > Meanwhile, let me say this explicitly: between a pair of 
> GLSRs (i.e.,
> > LSRs, OXCs, SXCs, ...), the requirement is that there must be at
> > least one control channel; the requirement is *not* one per bundle.
> > Corresponding to this control channel, one routing adjacency is
> > needed.
> >
> > The routing module can generate LSAs for all the bundle(s) assigned
> > to a control channel when both the control channel adjacency is up
> > and the bundles are up (LMP can be used to say when the bundles are
> > up).  If a bundle changes, the LSA corresponding to that 
> bundle alone
> > is re-flooded.
> >
> > This addresses the issue of flood optimization: having multiple
> > bundles does *not* mean having multiple adjacencies, so flooding
> > optimization is not a requirement.
> >
> > Kireeti.
> >
>

---

From: John Drake <[email-masked]>
Date: Wed, 18 Oct 2000 10:32:09 -0700

Frank,

Control channels between adjacent GMPLS devices may be direct lambdas or
fibers.  They may also be IP tunnels, GRE tunnels, or LSPs, across a router
network.  This is fairly well understood and spelled out in the LMP draft as
well as the other drafts (or should have been).

There's no issue doing what you describe.

Thanks,

John

-----Original Message-----
From: Frank Hujber [mailto:[email-masked]]
Sent: Wednesday, October 18, 2000 4:12 AM
To: Kireeti Kompella; [email-masked]
Cc: [email-masked]
Subject: Re: Draft Minutes From Pittsburgh

Kireeti, et al,

Consider three routers as a small segment of a larger optical network, A, B,
and C. A and B areOXCs and are directly connected by a DWDM with some number
of lightpaths. However, their control plane connection is through C, which
is a pure IP router, not an OXC. We've made the (painful) assumption that
the customer/provider has such demand for his lightpaths that he does not
want to sacrifice a wavelength for control. It would seem possible to manage
optical links A-to-B with a LSP A-to-C-to-B as along as A and B knew their
optical connectivity and C knew that it was not part of the optical path.

We do regard this as a degerate case, but one that we must (here in NJ) be
prepared to support.

Frank Hujber
[email-masked]
----- Original Message -----
From: "Kireeti Kompella" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Wednesday, October 18, 2000 12:58 AM
Subject: Re: Draft Minutes From Pittsburgh

> > For A----B, even there could be many bundles between A and B, there
needs only
> > one control channel (no need for physical channel, a TCP session is
enough)
> > between them. Bundle in circuit network is different from "interface" in
IP
> > network in the sense that a bundle can be included in one LSA, but only
send to
> Meanwhile, let me say this explicitly: between a pair of GLSRs (i.e.,
> up).  If a bundle changes, the LSA corresponding to that bundle alone
> is re-flooded.
>

---

From: John Drake <[email-masked]>
Date: Wed, 18 Oct 2000 11:16:18 -0700

Yangguang,

Have you been following the work on Generalized MPLS (nee MPL(ambda)S) which
has been going on since late last year?  As I said in my note to Frank, we
already do what you're describing (to the extent that I understand what
you're describing), we just don't use a TCP session; instead an IP, GRE, or
IPSec tunnel, or an LSP is used.  

As Kireeti points out, there are practical problems associated with using a
TCP session.

Thanks,

John
-----Original Message-----
From: Yangguang Xu [mailto:[email-masked]]
Sent: Wednesday, October 18, 2000 10:58 AM
To: Kireeti Kompella
Cc: [email-masked]
Subject: Re: Draft Minutes From Pittsburgh

Kireeti,

I guess I didn't address clearly about using TCP session.

There are two ways to distribute transport network topology. Either way has
pros
and cons. 

1) Piggyback through standard OSPF Opaque LSA
   If we want to apply OSPF/ISIS, CR-LDP/RSVP directly to circuit switched
transport network, you are absolutely right. There should be a one-to-one
correspondence of routing adjacency and control channel. 

   However, there is a fundamental problem here, folks (including me) always
try
to apply existing protocols directly to other applications. Protocols are
always
designed for a certain problem with unique features, assumptions and
requirement. For other "similar" problems which may have different
assumptions
and requirement, "Here it is and use it" isn't always a good solution. We
should
first understand the correct assumption and requirements of optical network
and
then tune routing and signaling protocols for them.

   Using existing solutions, protocols to define problem, application and
assumption seems to be not quite right. 

2) An independent application 
   You don't need a dedicated control channel in this case. A TCP session is
enough. 

Thanks,

Yangguang

Kireeti Kompella wrote:
> 
> > The key point is that routing adjacency in circuit switched network data
plane
> > has nothing to do with control channels (the control plane). At least
there
> > shouldn't be any assumption about their co-existence.
> 
> Actually, there is a one-to-one correspondence (for GMPLS, anyway):
> one routing adjacency for each control channel.
> 
> There is the issue of OSPF-incapable OXCs.  In this case, there may
> be a proxy intelligent device that handles OSPF/signalling/LMP;
> however, that device still needs to have an OSPF adjacency, so the
> problem doesn't go away, it just moves to this device.  However, here
> what you say may apply: the OXC may just need a simple TCP session to
> the proxy device, depending on their (private) API.
> 
> > For each routing adjacency (in data plane), you only need a TCP session
as Frank
> > hinted. Not necessary a physical control channel.
> 
> You don't need a physical control channel, but you do need more than
> a TCP session.  You need a routing adjacency (OSPF doesn't run over
> TCP, and certainly ISIS doesn't), a path for signalling messages and
> (probably) a path for LMP control messages.  Fortunately, a GRE tunnel
> will do exactly this.
> 
> > BTW, I had a feeling that LMP suggest control channel for each bundle.
(I read
> > it long time ago, can't remember exactly). If this is the case, it's
simply not
> > right. For example, a OXC has 10 neighbors, between each neighbor there
are 2
> > bundles, then do you need 20 control channels? NO!
> 
> The next rev of LMP will address this issue.  We basically realized
> that this is an issue for fast Hellos, failover and OSPF, but this
> applies to signalling as well.  So, we'll try to bring this down to
> one control channel per pair of neighboring GLSRs.
> 
> Kireeti.

---

From: [email-masked]
Date: Mon, 23 Oct 2000 11:16:48 +0100

Hi Kireeti,

Back to the bundling debate (my apologies for being late to contribute) ...

> > I would invite others to participate; so far, the argument has gone
> > back and forth between the authors of the drafts, who are
> > understandably biased (apart from one comment from Curtis

<..snip..>

> > The point is that "link groups" don't
> > add value.  At best, they appear to remove the need for flood
> > optimization; however, since multiple bundles are needed anyway, this
> > is a false notion.

In my opinion, SRLG's will do value to an OTN simply because they make it
easier for an operator to guarantee physically diverse working and
protection paths.

While it's obvious that your draft covers bundling in a general sense,
Bala's draft focuses on the specific case of bundling for the OTN.  I
believe that it does provide something extra that your draft doesn't
support.  I'd therefore like to see both of the drafts merged, with a
specific 'optical' section in the draft, and the concept of link groups
incorporated.

Regards,
Darren.

---

From: [email-masked]
Date: Mon, 23 Oct 2000 11:18:57 +0100

Jim Boyle wrote:

> I find no reason why the IGPs and interfaces between telecommunications
> gear should remain closed and proprietary.

I agree!

Regards,
Darren.