Re: Last Call for draft-ietf-rolc-apr-00.txt

Andrew Smith <asmith@baynetworks.com> Tue, 24 October 1995 23:57 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa24078; 24 Oct 95 19:57 EDT
Received: from guelah.nexen.com by IETF.CNRI.Reston.VA.US id aa24074; 24 Oct 95 19:57 EDT
Received: from maelstrom.nexen.com ([204.249.99.5]) by guelah.nexen.com (8.6.12/8.6.12) with ESMTP id TAA11493; Tue, 24 Oct 1995 19:19:33 -0400
Received: (from root@localhost) by maelstrom.nexen.com (8.6.12/8.6.12) id TAA17746 for rolc-out; Tue, 24 Oct 1995 19:29:38 -0400
Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom.nexen.com (8.6.12/8.6.12) with ESMTP id TAA17737 for <rolc@nexen.com>; Tue, 24 Oct 1995 19:29:35 -0400
Received: from lightning.synoptics.com (lightning.synoptics.com [134.177.3.18]) by guelah.nexen.com (8.6.12/8.6.12) with SMTP id TAA11489 for <rolc@nexen.com>; Tue, 24 Oct 1995 19:18:25 -0400
Received: from pobox.synoptics.com ([134.177.1.95]) by lightning.synoptics.com (4.1/SMI-4.1) id AA23591; Tue, 24 Oct 95 15:22:15 PDT
Received: from milliways-le0.engwest (milliways-le0.synoptics.com) by pobox.synoptics.com (4.1/SMI-4.1) id AA27004; Tue, 24 Oct 95 15:23:37 PDT
Received: by milliways-le0.engwest (4.1/SMI-4.1) id AA22044; Tue, 24 Oct 95 15:23:36 PDT
Date: Tue, 24 Oct 95 15:23:36 PDT
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Andrew Smith <asmith@baynetworks.com>
Message-Id: <9510242223.AA22044@milliways-le0.engwest>
To: kandlur@watson.ibm.com
Subject: Re: Last Call for draft-ietf-rolc-apr-00.txt
Cc: rolc@nexen.com
X-Orig-Sender: owner-rolc@nexen.com
Precedence: bulk
X-Info: Submissions to rolc@nexen.com
X-Info: [Un]Subscribe requests to rolc-request@nexen.com
X-Info: Archives for rolc via ftp://ietf.cnri.reston.va.us/ietf-mail-archive/rolc/

Dilip,

>  > The implication is that QoS requirements would be considered as a
>  > guide to setup SVCs.  Yes, there is also a belief that an SVC would
>  > provide better QoS (e.g. delay) since it avoids IP level handling
>  > costs at intermediate nodes.
> 
>  I don't think we should be making assumptions like that in an architectural
>  document: that is an implementation issue. I certainly know of some ATM switches
>  with higher latency (under some traffic conditions) than routers .... :-)
> 
> We can, however, make the assertion that the QoS characteristics of
> the ATM SVC would be based on the QoS requirements of the higher
> layers.  

Yes. Assuming a direct SVC were deemed to be the right mechanism to use for
that particular QoS at the time of the query.

> The belief that ATM SVCs are more desirable than multiple IP
> hops is one that is in line with the objectives of ROLC.

I disagree: I thought the objective of ROLC was to provide a protocol mechanism 
which would *allow* for shortcut VCCs. There is nothing in the ROLC charter (and
there is certainly nothing in the NHRP draft) about whether that is always 
the desirable outcome or not. The charter needs updating if you think that this
assumption is an implicit part of ROLC's work.

I repeat, this draft is an architectural draft with much wider implications
than the narrow focus of ROLC. That was the gist of my previous posting
asking that this draft be posted much more widely than just the ROLC group.
There is an implicit assumption being made that this draft represents the 
views of the IAB (same as 1620), not just the ROLC group. If its consumption
is limited to just the ROLC focus then it becomes a much less useful and less
relevant piece of work. 

I assume that Andy will be producing an updated list of goals/milestones 
in the charter to match the APR work: I apologise for having missed the discussions 
on the justification of why this work is in the ROLC group which must have occurred
in Stockholm.

> -- Dilip.
> 

Andrew


********************************************************************************
Andrew Smith					TEL:	+1 408 764 1574
Technology Synergy Unit				FAX:	+1 408 988 5525
Bay Networks, Inc.				E-m:	asmith@baynetworks.com
Santa Clara, CA
********************************************************************************