The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2000-Oct> msg00282



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

[IP-Optical] RE: Optical link bundling. Was Re: Draft Minutes From Pittsburgh

  • From: Kireeti Kompella <kireeti@juniper.net>
  • Date: Fri, 20 Oct 2000 09:20:44 -0700 (PDT)
  • Cc: ip-optical@lists.bell-labs.com, mpls@UU.NET, neil.2.harrison@bt.com

Hi Darren,

> Perhaps you missed my point.  I didn't say the point of GMPLS is a peer
> model (I have read the draft) - I questioned the assumption that IP-centric
> control protocols will be appropriate for an optical (or indeed any) control
> plane.

Could you clarify what you mean by "IP-centric control protocols":
a) IP control protocols (such as OSPF, RSVP, CR-LDP), or
b) control protocols aimed at serving an IP infrastructure?

> As far as I can see (having read the IPO framework, the MPLambdaS,
> and the Generalised MPLS drafts I hasten to add), this assumption has been
> made without giving full consideration to the requirements of the particular
> networks the protocols will be applied to.  My interest is the OTN, so
> that's what I've been focussing on.

Why I ask the above question is that there is a UNI based on IP
control protocols (draft-gray-mpls-rsvp-oif-uni-ext-00.txt), which
caters to non-IP uses of the OTN, and whose underlying model is the
overlay model.  This draft is in response to the *OIF*'s requirements
for an optical UNI.

So, if your objection is to the IP-centricity of the GMPLS approach
(which is debatable), you may find the above UNI more suitable to
your needs.

However, if your objection is to the use of IP control protocols,
that's a different issue.  Note that the IETF is unlikely to be the
right venue for discussing say PNNI as a control plane for the OTN.

For what it's worth, the MPLS control plane is IP-based, but serves
non-IP uses quite well.  There is an upcoming foo-over-MPLS BOF that
illustrates this point.

[...]

> I think a new draft is in order,

Very possibly.

> but I get the feeling many won't like it.

That hardly matters.  If it makes sense to service providers, the
vendors will come around :-)

One thing though is to better articulate what is broken with the
current approach.  If it's not the "peer vs. overlay" model that's
the issue, then like you say, I've missed your point, and would
like to understand what the real problem is.

Kireeti.