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

From: [email-masked]
Date: Fri, 20 Oct 2000 11:39:50 +0100

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.

---

From: Bala Rajagopalan <[email-masked]>
Date: Fri, 20 Oct 2000 12:52:13 -0400

Hello:

> that's what I've been focussing on.

Our practical experience so far (w.r.t product development)
has been that IP centric control protocols are both appropriate and
also practical for controlling dynamic provisioning. We are able to reuse
available protocol  implementations (of course,
some degree of customization is needed). We have not found it suitable
(yet) to utilize an IP-centric protocol for restoration under our tight
time constraints. Note that this is a control plane inside a single vendor
network. Models for multi-vendor interoperability using IP-centric
protocols are still evolving, IMO.

> justifies thoroughly the choice of IP-centric control protocols for the OTN.

The statement on consensus is true to the degree that  optical network
equipment vendors would like to use IP-centric protocols for control within
their network. As for requirements, there are three aspects. First, the
requirements
for control within a network: these are met by the IP-centric control plane in
the view of many vendors (other than restoration for which IP-centric
control may not be a choice for all vendors). Second, the requirements for
controlling
interoperability: the premise is that an IP-centric control plane will be
suitable for this also. The debate is on the type of control and this centers on

 the peer and overlay. Finally, the service requirements: these are the
least articulated requirements. There is some effort in the OIF to involve
service providers in formulating these requirements, and these will be
reflected in the IETF also.

> be made to fit these requirements.

The rationale for choosing an IP-centric control plane (as opposed to
say, PNNI) is the focus on IP clients. I don't think there is any secret here.
There is a hope that an IP-centric control plane inside an optical network
would make it possible to achieve flexible interaction with IP client networks
(leaving aside the peer and overlay issues for the moment).

> reluctance on this list to recognise the problems the peer model may bring.

I am personally not a  fan of peer model, but I accept that there are many
who believe in it strongly. I agree with you that no (optical) service
provider (to my knowledge)
has made a statement about deploying a service to IP clients using the peer
model.
Neither have I seen any statement from any network operator as to their
intention on using the peer model for an IP-optical intranet. It has also not
been quantified (in any scientific manner) what the traffic engineering
advantages
of the peer model are. But this is irrelevant now, since the signaling
developments
in GMPLS and OIF are towards using a common framework for peer and
overlay models, with a path for evolution from overlay to peer. The IPO
framework document has tended to be very balanced in its view with
regard to the interoperability models and it describes the evolution
approach. In particular, it describes how an IP-centric control plane
in the optical network eases IP-optical interaction even for establishing
overlays (under the routing models section).

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: Grenville Armitage <[email-masked]>
Date: Fri, 20 Oct 2000 09:56:56 -0700

[..]
> ATM is not the OTN.

When MPLS first burst onto the ATM scene, there was much talk of being
able to run ATM switches in a ships-in-the-night mode, partitioning
the VCI/VPI space into blocks for allocation by PNNI and LDP(et al).

The analogy with IP/ATM is pertinent in so far as we all thought ATM
networks would be primarly built for other 'telco' services (migrating
across from wherever...) and that IP would be just another client.
For some ATM installations this was no doubt quite true, and the
'overlay' model a compelling solution. Yet for those people buying
ATM gear primarily to haul IP traffic around their region(s), it
seemed equally likely that optimizing the ATM control plane for a
single 'client' (IP) was acceptable.

I'm not sure it is constructive to insist there is an absolute
either/or case to be made for IP/optics. Certainly for work coming
out of the IETF environment it is hardly surprising the focus is
on IP as the client layer. But this isn't the same as saying an
OTN must be built as the IETF wants it. Ships-in-the-night is
still feasible on boxes that switch lamdas, timeslots, ...

cheers,
gja
________________________________________________________________________
Grenville Armitage                    http://members.home.net/garmitage/
Bell Labs Research Silicon Valley

---

From: Sanjeev Rampal <[email-masked]>
Date: Fri, 20 Oct 2000 14:36:00 -0400

Even if we only care about IP clients,  other issues (stemming from
the fact that ATM switches can peer into per-packet (cell)
headers, do merge operations etc) could impact the peer versus
overlay issue perhaps differently in the ATM than in the optical case ...

---

From: Grenville Armitage <[email-masked]>
Date: Fri, 20 Oct 2000 11:53:09 -0700

aside from the usual caveats of taking analogies too far...

Sanjeev Rampal wrote:
> headers,

_ATM_ switches do not look inside packet headers (regardless
of what ATM-packet hybrids you might have seen), and packets are
not cells. Looking inside cell headers? Well, that's the point
isn't it...

> do merge operations etc)

In the early days of MPLS, ATM switches couldn't all be relied
upon to support VC merge either. The analogy to optical switches
(despite the loud stretching sounds) is somewhat germane.

cheers,
gja

---

From: Sanjeev Rampal <[email-masked]>
Date: Fri, 20 Oct 2000 15:34:00 -0400

Grenville

Of course ATM switches do not look at *IP* packet
headers from the payload and my note did not say that
either ...

This was just a way of saying that cells are in fact special
"packets" and the VPI/VCI label allows the switch to
have some representation of the headers of the packets
(IP/ ethernet/ whatever) being transported in that
ATM-LSP/ VCC. This enables merging operations
etc.

In contrast optical switches work at the granularity of
optical channels/ lambdas/ STSs which are not
"mergeable"

---

From: Grenville Armitage <[email-masked]>
Date: Fri, 20 Oct 2000 14:59:57 -0700

Sanjeev Rampal wrote:

	[..]
> This enables merging operations
> etc.
> 

And my historical note is that "merge" wasn't even
a mandatory requirement in MPLS when we first started
bringing it into the ATM world. So this is not a point
of fundamental difference, and does not invalidate the
(now highly overstretched) analogy.

Stepping  back a little....

What also seems to be missed here is that the analogy
between IP/ATM history, and IP/optical today isn't the
technical details. It is that some class of operators
emerged in the IP/atm world who believed their ATM nets
served only one client (primarily) and therefore it
made sense (for them) to optimize the ATM control for the
IP 'client' (aka MPLS/ATM).

Does this support or detract from arguments for the peer
model? The absence of large operators stating on these lists
that they're rolling out IP-only switched optical nets would
seem to favor development of the overlay model for data/optics.

cheers,
gja