Subject: Comment on draft-doria-gsmp-req-olsr-01.txt

From: Papadimitriou Dimitri <[email-masked]>
Date: Fri, 09 Mar 2001 15:34:09 +0100

Dear all,

Please find some discussion i had with Avri Doria and that we would like

to share on the mailing list:

The draft mentions (section 1 - overview)...
> This draft is intended to describe the required changes to GSMP
> for support of optical, SONET/SDH, and spatial switching of IP
> packets and flows.

[DP] Wouldn't be preferable to support optical (transparent and
all-optical),  G.709, SDH/Sonet and Spatial Switching ?

[AD] I don't know G.709.  But in general I think GSMP support all forms
of  switching.  I will read up on G.709 in the draft you refer to.

[DP] Any other thought about this issue ?

The draft mentions (section 7 - encapsulation)...
> The working group needs to decide whether a new encapsulation is
> required.  In other words, will all optical switches used in
> either the MPLS over Optics and the IP over optics applications
> require that IP be implemented on the control channel connecting
> the GSMP controller and Optical switch (the GSMP target).  If a
> raw wavelength control connection is to be allowed, a new
> encapsulation SHOULD be defined.

[DP] The definition of the encapsulation of IP packets is in the
scope of the IPO WG. Note that fixed or variable length packet
encapsulation could be applied.

[AD] Indeed.  And if the only encap we support is IP (whatever the encap

of the IP itself) we have nothing to do here.  There have, however,
been occasional requests for raw encap modes as in ATM and Ethernet.
I did not want to preclude these without discussion.  Though I tend
toward sticking with the current requirement for IP encap for IETF
work.

[DP] To be more accurate IPO WG Charter mentions
> Document the use of existing framing methods for IP over optical
> dataplane and control channels, and as necessary specify
> additional framing methods.
However the target timeframe is December 2002. So the first point
is: encap IP over optical control channels is mandatory, optional
or out of scope and if mandatory/optional within the timeframe ?

Further comments and discussion to follow very soon...

Thanks,
Dimitri.

---

From: Hans Sjostrand <[email-masked]>
Date: Sun, 11 Mar 2001 11:58:37 +0100

I get kind of hung up on this encapsulation issue. It's on the agenda for
minneapolis but I would like to start it already now.

It's of course nice to have these raw encapsulations. But when it comes to
reality I cant se the big benafit.

I remember when we did the GSMP controller on Ericsson, we had GSMPv1.1
which even had single cell messages to be efficient, wow. But since
the mode is raw and the controller most often where co-located withe the
switch, we use an entire STM-1 for that sole purpuse. The same will probably
apply for ethernet or any below-ip encap. You really have to work to fill up
a whole link just with control traffic, you can afford the extra overhead.
And atleast in that specific application we could probably also have
afforded
the extra clock cycles it takes to do tcpip.

And you get the reliable transfer of tcp.

I think it's a sound requirement for a GSMP switch to have to have the IP
stack and to carry GSMP in tcp/ip encap. I think it's GSMPs roots in IP
switching that haunts us.

But are there anyone out there with other experience or opinion? This
also boils down to how extensible we want to make todays set of specs
(well, hrmm, the mib ;-) for new encapsulation formats.

IMHO
/// Hasse

---

From: Peter Newman <[email-masked]>
Date: Mon, 12 Mar 2001 10:20:55 -0800

At Sunday 3/11/2001, you wrote:

>which even had single cell messages to be efficient, wow.

Impressive huh!  :-)

>switching that haunts us.

Very true ... but at least something useful came out of IP Switching...

When we were building an IP switch it seemed unacceptable to require an IP 
stack to process the control messages. Minimizing the delay in the control 
path was essential. Therefore using an IP stack in the control path would 
have wasted precious time. Minimizing the delay in the control path was 
also the reason for using single cell messages for the most commonly used 
messages. They also looked neat and tidy that way.

I guess things have changed some.

Peter

---

From: Hans Sjostrand <[email-masked]>
Date: Mon, 12 Mar 2001 23:41:02 +0100

comments inline

> >which even had single cell messages to be efficient, wow.

unfortunately those single cell messages disappeared with the deletion of
short format labels.

> Very true ... but at least something useful came out of IP Switching...

yapp, I always liked GSMP.

> I guess things have changed some.

The requirements on the GSMP agent in the switch changed quite a bit when
the project changed from IP switching to label switching. The performance
requirements decreased adn the demand for reliable transfer came instead.
But that was that project, and that was then.

But I'm rather imressed how much is still remains. Nice to see that you
still are with GSMP.

Regards
/// Hasse