Subject: this just in from ip-atm 2/04/96 08:00:41

From: "Roch Guerin ((914) 784-7038)" <[email-masked]>
Date: Mon, 5 Feb 96 15:43:03 EST

Reference:  Your note of Sun, 04 Feb 96 08:00:41 PST

Yakov,
Just about to leave for LA (can talk some more about these issues there),
but I wanted to add a few things to Andrew's comments and your response.

>Andrew,
>
>> But your/Arthur's/Yakov's contribution then goes on to assert that because
>> one vendor's routers don't like altering AdSpecs that we should not bother
>> defining any sort of QoS service over ATM which needs them to do this and we
>> should limit RSVP-over-ATM support to just Guaranteed Bandwidth, Controlled
>> Load and Best Effort services. It would be a shame to waste all of that
>> work that the RSVP group has put into Guaranteed QoS, Controlled Delay
>> and Predictive services just for a few of your CPU cycles or gates.
>
>The problem of updating AdSpec is *not* specific to ATM. In fact, this
>problem is present in other Link Layer technologies as well (e.g.,
>switched Ethernet). This is covered in the 3rd and 4th paragraphs in the
>"Handling Adspec" section of our contribution to the ATM Forum.
>The issue goes *well beyond* "few of your CPU cycles or gates".
>

True, it's not specific to ATM, but as we discussed on the mailing list when
this problem was first brought up, the problems of *legacy* link layers are
present with all the service specs, including those that do not rely on any
Adspecs update, e.g, controlled load.  Bottom line is that a link layer that
provides no discrimination of packets and does not do some form of call
admission CANNOT provide any service guarantee.  Therefore, I don't really
consider that you can really use this as an argument against Adspecs.  Now,
I'll grant you that today it may be easier to supports over ATM, service
guarantees that do not involve Adspec.  However, the OPWA that the Adspec
allow is one of the strengths of the Int-Serv specs, and my view is that
we should rather try to figure out how to extend ATM to support it than do
the opposite.

This is what I meant in my note to Fred where I referred to the fact that
we should not strive for the lowest common denominator.  I understood his
response of *Of Course* as an indication that we may have some agreement
there.

>> I believe that it was Yakov himself who suggested to MPOA that devices might
>> want to run PNNI instead of being UNI devices in order for them to be more in
>> touch with the routing/QoS of the network: this would seem to help with the
>> problems you describe in the contribution.
>
>While this could help, one should question whether running PNNI would
>help *enough*.

I fully agree with Andrew and as we pointed out in our RC20250 that you
refer to, PNNI information can go a long way towards improving the
accuracy of the information used to update Adspec.  Clearly, one can
do better, but it is a start.
>
>> Of course, if devices were to
>> run an Integrated routing protocol this would help even more but, of course,
>> MPOA and IP-over-ATM devices don't use that routing model, do they?
>
>Could you please point to a document that describes *in details* why
>running an "Integrated routing protocol ... would help even more" ?
>
>Yakov.

There are three ATM Forum contribution (atm94-0789.txt, atm95-0649.txt,
and atm96-1070.txt), all authored or coauthored by
Ross Callon ([email-masked]) whom I'm sure can send copies to
folks who don't have access to the Forum mailing list, and that give
some indications of how that info could be used (in particular the
reachability info).  Granted, the I-PNNI spec are not *really* complete,
but they provide an indication on what may be available and, therefore,
leveraged to support some of the functionality that the Int-Serv specs
provide.

Roch