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

[Curtis Villamizar <[e-mail]>]

In message <[e-mail]>om>, "Andrew G. Malis" writes:
> This is a Working Group Last Call for draft-ietf-rolc-apr-00.txt, for
> the purpose of publishing this I-D as an Informational RFC.  Please
> send comments to the list.
> 
> The Last Call period will last for two weeks (plus a weekend, since
> I'm sending this on Friday), and will end at 23:59:59 PST on Sunday
> 11/5/95.  Due to the clock change, you get an extra hour in the
> process! :-)
> 
> At the conclusion of the period, the comments will be addressed, and
> if necessary, a new revision of the I-D will be produced.  The I-D
> will then be submitted from the WG to the Area Director.
> 
> Regards,
> Andy
> __________________________________________________________________________
> Andrew G. Malis   Ascom Nexion                      voice: [phone]
> [e-mail]   289 Great Rd., Acton MA 01720 USA   FAX: [phone]


Andy,

I think that issuing a last call on this document was completely out
of line.  This is a 00 issue of the draft and I unless I'm mistaken it
should be issued for comment first before WG last call if it is to be
a WG draft.  That is at least the normal procedure if not mandated.  I
think is a terrible document.  It pretends to propose a new
architecture when it does nothing but define a new term and provide
some disjoint discusion of soem issues covered better elsewhere.
Detailed comments below.  Even though you called this a "last call",
I've provided more general comment than wording since this document
has not come up for comment before.

Curtis


First some general comments.

This document proposes that the IP architecture is somehow broken and
that a new architecture is being proposed to replace it.  This has
been thrashed out in great detail, probably more in the IP over ATM WG
that in ROLC, since in IP over ATM about two years a go there was an
abundance of claims that the IP architecture was broken and proposals
made to fix it or replace it.  Many of the proposed replacements were
poorly thought out.  In the end, the Classical IP over ATM
architecture emerged based on this being an architecture that is known
to work and known to scale.  The drawback was that it would
temporarily forgoe the "full benefit of ATM", though whether that was
good or bad is still debated today.

The problem is not that the IP architecture is broken and needs
fixing.  The IP architecture has what is viewed as a limitation by
some that requires hop by hop forwarding.  Work is in progress to
allow routers (or hosts) to cut across subnet boundaries where the
underlying media allows it.  (NHRP - though I disagree with the
approach, I don't oppose the idea of cut through - I just think the
protocol proposed to do so is broken in that it is unable to support
the router to router case).  Cut through is no more a scraping of the
IP architecture as subnetting was or as CIDR was.  It is an extension
and should be documented as such, without any counterproductive hype
of "replacing the IP architecture".

The extension of IP to accomodate cut through is described in the IP
over ATM Framework Document.  It may be that this extension requires
it's own document.  This document is seriously flawed and is not it.

This draft also dabbles in QoS issues, though discussion is somewhat
orthogonal to the issue of cut through.  QoS may be a motivation for
cut through, but that point is not made very clearly and a good deal
of misinformation about the state of IP and QoS is presented.  This
topic is already better covered by RFC1821.

The document proposes the the concept of subnet be replaced with APR,
where APR implies probably but uncertain direct reachability where
subnet implies direct reachability.  Removing the former definition of
subnet is inadvisable as it would throw prior discussions of IP into
terminology chaos.  There is no compelling argument for the
desirability of introducting the notion of a prefix region in which
direct reachability is probable based solely on the prefix match, but
is not certain.  The routing implications are not even considered in
this draft (or anywhere else).  We discussed schemes on the ROLC list
which involve sending a packet to determine direct reachability
without any prior indication that it was possible and serious scaling
issues were seen wrt the load of junk request packets.

   The original IP architecture assumes that each Data Link subnetwork
   is labeled with a single IP network number. 
   A pair of hosts with the
   same network number communicate directly  (with no routers); a pair
   of hosts with different network numbers always communicate through
   one or more routers. 
   As indicated in RFC1620, these assumptions may
   be violated for large data networks, and specifically for networks
   based on switched virtual circuit (SVC) based technologies (e.g. ATM,
   X.25).  The architecture works even when this assumption is violated,
   but it imposes constraints on communication among hosts and routers
   through a network, which in turn may preclude full utilization of the
   capabilities provided by the underlying SVC-based Data Link
   subnetwork.  This document describes extensions to the IP
   architecture that relaxes these constraints, thus enabling the full
   utilization of the services provided by SVC-based Data Link
   subnetworks. The document also specifies how the proposed extensions
   could be used for other types of subnetworks.

I feel strongly that we need to change the tone of this paragraph to
reflect and extension to the IP architecture rather than some sort of
architecture replacement.  Change "The original IP architecture" to
"The IP architecture".

We should use current IP terminology, which means it is OK to talk
about subnets and CIDR prefixes.  We should be able to say "A pair of
hosts covered by the same subnet prefix".  I don't think we need to
claim that an architectural assumption is violated.  The introduction
of subneting was an extension to the original class based network
architecture.  CIDR was a further extension.  Cut through is an
extension, which allows a direct connection across subnets and does
not violate assumptions of the IP architecure any more than subnetting
or CIDR or numbered or unnumbered point to point interfaces did in the
past.  There is a vast distinction between an architecture change and
a minor extension.

  1  Background

   The following briefly recaptures the concept of the IP Subnet.  The
   Internet architecture is based on the "Catenet model" [Postel:81].
   The topology is assumed to be composed of links (Data Link
   subnetworks) interconnected via routers.  Each link has a globally
   unique number. An IP address of a host with an interface attached to
   a particular link is a tuple <link number, host number>, where host
   number is unique within the link. When a host needs to send an IP
   packet to a destination, the host needs to determine whether the
   destination address identifies an interface that is connected to one
   of the links the host is attached to ("local" decision), or not
   ("remote" decision).  The outcome of the "local/remote" decision is
   based on (a) the source address, (b) the destination address, and (c)
   the subnet mask associated with the source address.  If the outcome
   is "local", then the host resolves IP address to Link Layer address
   (e.g. by using ARP), and then sends the packet directly to that
   destination (using the Link layer services).  If the outcome is
   "remote", then the host uses one of its first-hop routers (thus
   relying on the services provided by IP routing).

There is no sense bringing us all the way back to Postel:81.  We can
and should use CIDR terminology and describe what changes need to be
made relative to current routing and addressing practices.  You are
not changing the catenet model unless these multiple subnet regions
can not be concatenated with existing IP internetworks, which I assume
is not part of this proposal.

   To summarize, two of the important attributes of the IP subnet model
   are:

      hosts with a common network number are assumed to be attached to a
      common link (subnetwork), and thus communicate with each other
      directly, without any routers -- "local"

      hosts with different network numbers are assumed to be attached to
      different links (subnetworks), and thus communicate with each
      other only through routers -- "remote"

Please use "subnet address prefix" rether than "network number".
Class based network numbers as the sole means of addressing died a
long time ago.


  2  Motivations

   The diversity of TCP/IP applications results in a wide range of
   traffic characteristics.  Some applications last for a very short
   time and generate only a small number of packets between a pair of
   communicating hosts (e.g. ping, DNS). Other applications have a short
   lifetime, but generate a relatively large volume of packets (e.g.
   FTP). There are also applications that have a relatively long
   lifetime, but generate relatively few packets (e.g.  Telnet).
   Finally, we anticipate the emergence of applications that have a
   relatively long lifetime and and generate a large volume of packets
   (e.g.  video-conferencing).

This is an entirely different issue, covered much more accurately in
RFC1821 than in this section.

   The traditional IP subnet model provides a poor match for flexible
   and adaptive use of the SVC-based Data Link subnetworks  - the use of
   a subnetwork is driven by information completely unrelated to the
   characteristics of individual applications.  

This is too braod a statement and is not well clarified by the
example.  Why not just get to the point and state "The scaling
properties of internetworking routing protocols in use today, and
possibly routing protocols in general requires the subdivision of
large networks into smaller prefixes and the isolation of routers from
the inconsequential details of distant small changes in routing
through abstration.  With the current IP forwarding model IP traffic
follows the reverse path of the routing information, the traffic being
forwarded by each router that forwarded routing information.  This
does not lend itself to taking advantage of VCs which can be set up to
span multiple subnets.  There may be advantages to setting up direct
VCs between distant endpoints for certain classes of applications".

There really should be mention of RSVP in this section.  The whole
issue of subnet cut through stems not from the fact that there is no
provision for QoS with IP and RSVP, just that there is a feeling among
some that cell switching will somehow provide much "better" service,
where "better" may be better QoS guarentees, or the ability to scale
to higher traffic capacities (mostly stemming from the belief that
cell switching is fundamentally better than packet switching).

  3  QoS/Traffic Driven "Local/Remote" Decision

The first two paragraphs deal with the "when to set up a direct VC".
That seems to be covered by RFC1821.  Maybe cut the text and reference
the RFC.

   The ability of a host to establish an SVC to a peer is predicated on
   its knowledge  of the Link Layer address of the peer. This document
   assumes the existence of mechanism(s) that can provide the host with
   this information. Some of the possible alternatives are NHRP, ARP, or
   static configuration; other alternatives are not precluded.  The
   ability to acquire the Link Layer address of the peer should not be
   viewed as an indication that the host and the peer can establish an
   SVC -- the two may be on different Data Link subnetworks, or may be
   on a common Data Link subnetwork that is partitioned. Only the actual
   SVC establishment is sufficient to enable direct communication. If a
   host can not establish an SVC, the host may default (depending on the
   application) to sending data through routers.

Solid advise, but not central to "the change in IP" being discussed.

   One important implication of this proposal is that in contrast with
   the conventional IP environment, the "local/remote" decision may no
   longer be time invariant. While at one moment a pair of hosts (e.g. A
   and B) may have an SVC between them (e.g. when there is a video-
   conference running between the hosts) and thus will be viewed as
   "local" to each other, at some later point in time communication
   between exactly the same pair of hosts (e.g. A and B) will be done
   through one or more routers (after the video-conference ends, and
   someone would decide to run ping) and thus will viewed as "remote".

Routing information never has been time invariant.

   In addition to being time dependent, the "local/remote" decision may
   yield both "local" and "remote" outcome simultaneously. This is
   because a set of hosts may concurrently run multiple applications,
   where some of these applications could justify an SVC establishment
   (thus resulting in a "local" outcome), while others will rely on
   router-based infrastructure (thus resulting in a "remote" outcome).

This has always been an implication of QoS.

   Even if when applications yields "local" outcome, depending on the
   nature of the applications a pair of hosts should be able to either
   multiplex several applications over a single SVC, or establish
   dedicated SVCs on a per application basis or both.  In the case where
   an SVC is shared among several applications care must be taken to
   ensure fair sharing of the resources provided by the SVC. For
   example, while it may be acceptable to share a single SVC for
   multiple FTP sessions between a pair of hosts, sharing an SVC for an
   FTP session and a video-conference is likely to be more problematic.

You mave simply state that the cut through decision isn't time
invariant, isn't dependent solely on destination, and may involve
shared or individual VCs.  Stating this without further explanation,
does not clarify anything, but rather may lead to further confusion.

  4  Address Prefix Region (APR)

The unfortunate conclusion of the proposal...

   To provide flexible and adaptive use of SVC-based Data Link
   subnetworks we proposed to replace the concept of a traditional IP
   subnet with the concept of an Address Prefix Region (APR).

You had better have a real good reason.  As far as I can see you don't.

   An Address Prefix Region (APR) can be formally defined by the
   following properties:

      An APR is a set of routers and hosts

      Every element in the set (either a host or a router) can establish
      direct communication (an SVC) with every other element in the set

      IP addresses of the hosts in the set are assigned in such a way
      that they can aggregated into a single IP address prefix; each
      element in the set knows the prefix

      All routers in the set advertise direct reachability to all the
      hosts in the set -- any router in the set is 1 IP hop away from
      any host in the set

Consider what you would have if you drop "IP addresses of the hosts in
the set are assigned in such a way that they can aggregated into a
single IP address prefix; each element in the set knows the prefix".

You would have a region in which direct VC reachability is possible,
with no definition of how the direct reachability is determined and
without the restriction that it be covered by a single prefix.  Adding
the IP prefix implies that using the IP prefix to determine whether a
direct VC is possible is A Good Idea.  Previous discussion on this
list have indicated that using the prefix to determine direct
reachability is not a good idea for large networks and that some other
mechanism should be used.  

For small networks, it might be that using the address prefix to
determine direct VC reachability is very simple and proves adequate.
The term APR may be fine for this purpose.  This is hardly grounds to
label APR as an IP architecture change.

   For the purpose of IP unicast forwarding the role of the APR is to
   act as a mechanism to associate a set of hosts with one or more
   routers that these hosts could use to establish connectivity
   (reachability) with (a) destinations that are not on a common fabric,
   or (b) destinations for applications that don't justify an SVC. An
   APR would identify for a given set of hosts the set of routers that
   these hosts can use as their first hop (first-hop routers).

This paragraph implies that you are simply replacing the term subnet
with APR but not changing the meaning at all.  That would serve no
purpose except to confuse discussions.  Which is it?

   The APR could serve as a useful migration tool from the current
   (traditional IP subnet model) environment, as it provides backward
   compatibility for hosts that support only the traditional IP subnet
   model (e.g. hosts that support only "classic" IP over ATM model),
   while allowing the intermix of these hosts with modified hosts that
   support application driven "local/remote" decision.

If it is a subnet, then it certainly provides compatibility since you
just continue to use the same subnet model, you just give the term
subnet a new name and declare a new architecture when in fact nothing
has changed at all.  If APR means something larger than a subnet,
meaning that IP forwarding can occur within an APR, then you have a
new term but not a new architecture.  The only thing new about any of
this is you are introducing the possibility of doing cut through.

  4.1 Host Modifications

This section is completely worthless.  It does not take into account
hosts that are one or more hops off the VC cloud.  For that, the host
must use some sort of signalling to a router a few hops down to get
QoS.  If there is no router, this can just be passed down the protocol
stack.  (Hey - why not use RSVP for the signalling :)

  4.2 Router Modifications

   When a router associated with a given APR (as defined in this
   document) receives an IP packet from a host in the APR that is
   destined to another host in the same APR, the router should forward
   the packet (if possible), and refrain from sending an ICMP Redirect
   message to the originating host.

That's it!?!  Routers will never need to do anything wrt SVC setup,
they just need to avoid sending ICMP Redirect?  This section seems as
worthless as the previous, if not more so.

  5  Transition for ATM-based subnetworks

I disagree entirely with this section.  I see transition from RFC1577
are following a different course.

  RFC1577 hop by hop, one SVC between adjacent routers for all traffic

  RFC1577 hop by hop, RSVP used to control queueing and where
  appropriate set up separate SVCs for a class of traffic, a set of
  flows, or an individual flow.

  RFC1577, most traffic flowing hop by hop, some one alternate VCs,
  some traffic taking cut through VCs.

Reagardless, I don't see how APRs contribute toward a migration.

  6 Conclusions

   Different approaches to SVC-based Data Link subnetworks use by TCP/IP
   yield quite different results with respect to the ability of TCP/IP
   applications to efficiently exploit the functionality provided by
   such subnetworks.  For example, in the case of ATM both LAN Emulation
   and "classical" IP over ATM (RFC1577) localize host changes below the
   IP layer, and therefore may be good first steps in the ATM
   deployment.  However, these approaches are likely to be inadequate
   for full utilization of functionality that ATM is expected to
   provide.

   It seems that any model that doesn't allow SVC management under
   direct control of applications (QoS) is likely to curtail efficient
   use of SVC-based Data Link subnetworks.  Enabling direct connectivity
   for applications that could benefit from the functionality provided
   by SVC-based Data Link subnetworks, while relying on routers for
   other applications, could facilitate exploration of the capabilities
   provided by the subnetworks.

It is entirely possible that RFC1577 and RSVP will serve the needs of
all traffic types.  The only argument in favor of considering an
alternate have to do with efficiency and QoS capability of cell
switching vs packet forwarding.

Any proposal that puts SVC management at the host but provides no
means to communicate QoS requirements from the host to an router one
or two hops away is shortsighted.

   Essential to the deployment of the proposed approach is to develop
   migration strategies that would provide graceful transition based on
   small incremental changes from the current environment to the
   environment proposed in this document.

There is no proposed architecture change.  There isn't enough defined
here to transition to anything.  There is nothing here more than
disjoint discussion and an unclear proposal for a new term, which may
be usefull in describing an ill advised idea.

   The proposed model utilizes the SVC-based infrastructure for the
   applications that could benefit from the capabilities supported
   within such infrastructure, and creates a router-based overlay for
   all other applications. As such it provides a balanced mix of
   router-based and switch-based infrastructures, where the balance
   could be determined by the applications requirements.

   The approach proposed in this document combines switch-based
   infrastructure with router-based overlay and uses each for that which
   it is best suited: switch-based infrastructure for applications that
   can justify an SVC establishment; router-based overlay for all other
   applications.

   The concept of APR proposed in this document could be also applicable
   in a non-SVC based environment.