-----Original Message-----
From:
darren.freeland@bt.com [mailto:darren.freeland@bt.com]
Sent: Friday, October 20, 2000 3:40 AM
To: kireeti@juniper.net
Cc:
ip-optical@lists.bell-labs.com; mpls@UU.NET; neil.2.harrison@bt.com
Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re:
Draft
Minutes From Pittsburgh
Hi Kireeti,
>> However, the point of GMPLS is NOT a peer
model. It is an IP-based
>> control plane,
leveraging existing work, and the flexibility of a
>> peer or overlay or hybrid model.
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. 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.
The IPO framework document starts out in the introduction by
saying that
"there is wide consensus in the industry
that the optical control plane
should be
IP-centric". I would question this 'wide consensus'. There is
a
few (very basic) requirements set out in the
introduction, but nothing that
justifies thoroughly
the choice of IP-centric control protocols for the OTN.
The MPL(ambda)S document does the same - we're told in the
intro that the
optical control plane will be based on
the MPLS TE control plane model. The
only
justification that is given for this is the reuse of existing
protocols. Cool - why not reuse PNNI then? I'm not
advocating one or the
other yet - what I am saying is
that the requirements of the OTN (or any
other network
in the case of GMPLS) should be fully considered in the first
place. The choice (and extensions) of control plane protocols
should then
be made to fit these requirements.
The other problem I have with the MPL(ambda)S philosophy is
its clear bias
towards the 'peer' option. Sure,
the 'overlay' option is described, but it
is not fully
discussed - we are simply told that "to understand the
drawbacks of this approach ... one need look no further than the
experience
with IP over ATM". This is a whole
discussion in itself which Neil Harrison
has touched
on in his reply to you. ATM is not the OTN. This aside, my
point is that the peer model is clearly advocated over the
overlay model -
but there is no mention to the effect
the peer model would have on an
operator who has a
multi-client environment. There is also a clear
reluctance on this list to recognise the problems the peer model may
bring.
I think a new draft is in order, but I get the feeling many
won't like it.
Regards,
Darren.
_______________________________________________
IP-Optical mailing list
IP-Optical@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/ip-optical