Subject: this just in from ip-atm 2/01/96 20:35:48

From: "Roch Guerin ((914) 784-7038)" <[email-masked]>
Date: Fri, 2 Feb 96 09:15:15 EST

Reference:  Your note of Thu, 1 Feb 1996 20:35:48 -0800

Fred,
Don't mean to be picky, but since you made some rather strong statement
on where things stood wrt to the RSVP <-> ATM mapping, I felt the need
to put things in a maybe different perspective.

I don't intend to get into the discussion on respective merits of ST-II
and RSVP over ATM, although it is true that ST-II is closer in design
to ATM than RSVP, but I agree that this does not mean that you cannot
run RSVP efficiently across ATM.  The part I feel needs some "qualifying"
statement is the reference to Yakov (and yours) contribution to the
ATM Forum.

This contribution brings out a number of valid and informative points
on the problem of mapping the RSVP and Int-Serv semantics onto
corresponding ATM quantities.  These are useful inputs to the technical
discussion that needs to take place in order to ensure that both sides
are aware of each others requirements, and do their best to ensure the
most efficient inter-operability.  However, they certainly do NOT make
for a DEMONSTRATION.  In particular, I'll disagree with your statement
"that the only thing that doesn't map rather cleanly is the Int-Serv
AdSpec."  I think there are a few other things for which the mapping
is not particularly clean and improvements are desirable.  The AdSpec
certainly represents one of the non-trivial issue, but I'm not sure
enough thoughts has been given to the problem, and there are nevertheless
a number of things you can do to deal with AdSpecs even today.

In any case, I would think that the purpose of bringing these issues
out is not to categorize them a priori in doable and non-doable, and
stop there.  Instead, the goal is to start resolving these issues so that
inter-operability is improved without dropping functionality.  We may
not agree on that, but I think that the Int-Serv AdSpec is a very
useful and key component to deliver functionality.  Actually, it is one
thing that I believe would be useful to add to the ATM signalling.
This may obviously be difficult to achieve in its entirety, but we can
make some progress there if the goal is to mend differences and not
default to the lowest common denominator.

Roch
*************** Referenced Note ***************
Date: Thu, 1 Feb 1996 20:35:48 -0800
To: [email-masked]
From: fred at cisco.com (Fred Baker)
Subject: Re: this just in from ip-atm
Cc: [email-masked]

At 5:01 PM 2/1/96, Steve Jackowski wrote:
> I just submitted a proposed informational RFC reflecting an
> implemetation of reservation protocols across ATM that we did for a
> major PTT.  Since rsvp does, indeed, map poorly to ATM, we used ST-2
> (ST-2+ would have been even better).
> [...]
> If we can step back from politics, I think you'll find that ST-2 (or
> better yet, ST-2+) makes more sense than rsvp in the ATM scenario.

I wonder if he has read Yakov's recent contribution to the ATM Forum, which
maps ATM <-> RSVP, and demonstrates that the only thing that doesn't map
rather cleanly is the Int-Serv AdSpec.

Since the only comment Steve has ever made about RSVP was that he prefers
ST-II, and that since his company already has ST-II products it's not
necessarily in his business interest to foster a competitive standard, and
since he is technically incorrect here, I wonder about the degree of
objectivity in the statement.