comments

[[e-mail]]

Martha,
Here are few comments on "IDPR as a Proposed Standard".
Yakov.
-----------------------------------------------------------------------


****** IDPR as a Proposed Standard


Executive Summary

>With IDPR, we introduce a new network-layer protocol based on source-specified
>routing between administrative domains.

Do you think that design of a new inter-domain routing protocol can,
by itself, justify creation of a new network layer protocol ?

If the answer is yes, then we either:

(a) have to assume that IDPR will be THE inter-domain routing protocol, or
(b) assume that each inter-domain routing protocol may come up with its
    own network layer that needs not be compatible with network layers
	  introduced by other inter-domain routing protocols.

Which of these choices do you think are likely to happen in practice ?

Section 1.

>We expect that, over the next five years, the Internet will grow to contain
O(10) backbone domains....

There is a notion of transit and stub domains. How do you define a "backbone"
domain.  Even today we have well above 10 transit domains (likely on the order
of at least 30).  Do you expect that by 1997 (1992 + 5 years) the global
world-wide internet will have AT MOST 99 transit domains ? (99 is as far
as I can stretch O(10)).

>We expect application diversity encompassing electronic mail, desktop
videoconferencing, scientific visualization, and distributed simulation
>for example. Many of these applications have strict requirements on
>delivery, delay, and bandwidth.

Does that mean to imply that the major driving force behind IDPR is
to accommodate these new applications that have strict requirements
on delivery, delay, and bandwidth ?

What do you expect be the percentage of traffic/users who will need to support
these new applications ?

Do you assume that IDPR, on its own, will be able to accommodate these "strict
requirements" ?

In the next paragraph you said "We believe that IDPR
meets this goal... " (with respect to ensuring that traffic receives its
required service).  I think it needs to be explained in TECHNICAL
details how IDPR, on its own, will accomplish that, rather than
just "We believe...".

If, on the other hand, you do not assume that IDPR, on its own, can
accomplish	this, then you need clearly articulate what are the
dependencies, and how much support is needed (versus available today)
from other components.  Moreover, if not all the dependencies provide
the required support, you need to discuss whether the required support
is feasible, and if feasible, what needs to be done to put it in place.


>In such a large and heterogeneous Internet, the routing procedures must be
>capable of simultaneously ensuring that traffic receives its required service
>and that domain usage restrictions are not violated.

There are two issues: required services and usage restrictions.

Usage restrictions are unlikely to be applicable to commercial
service providers. Indeed, just look at who in the current Internet
has AUPs (which are nothing more than the usage restrictions documents)
and who doesn't. Thus, the only potential candidates for
usage restriction are government subsidized networks. Thus,
the issue of usage restriction is likely to be relevent only
to a subset of domains. This is especially true given "privatization"
and "commercialization" of the Internet.

Likewise, definition of required services is likely to be rather loose
for a wide variety of applications. For example, what is the meaning
of "ensuring required service" for e-mail, FTP, Telnet, NFS ?


>...if has been designed to accommodate an Internet comprising O(10^4)
>administrative domains with diverse service offering and requirements.

While I have no doubts that IDPR can theoretically accommodate an Internet
comprising of O(10^4) domains, we need to look at what are the practical
implications (in terms of storage, computational, etc overhead) of doing this.
For example, what would be the implications on overhead if we'll deploy
IDPR as a dominant inter-domain routing protocol in existing internet;
would it require less/more storage, CPU, etc..; what would be
the implications on overhead if we'll deploy IDPR as a dominant inter-domain
routing protocol in an internet twice the size of the current one, but
with addresses assigned in a hierarchical fashion.


There are two aspects in the design:
(a) ability to accommodate O(10^4) domains
(b) ability to accommodate domains with diverse offering and requirements

How relevant is the first aspect to the existing Internet ? How soon
the Internet would exceed the limit that the design claims to support ?
Likewise, how relevant is the second aspect to the existing Internet ?
How many diverse offering do you see in the Internet today, two years
from now ?


Do you have an example of an environment for which the protocol is not suitable,
or is it suitable for any environment ?


Section 4.

>IDPR provides policy routing among administrative domains and has been
>designed to accommodate an Internet containing tens of thousands of domains....

Again, the issue is not how many domains the design is capable of accommodating,
but what are the implications of the design on the storage and processing
capabilities required by routers. For example, for an internet of 10,000
domains how many forwarding entries need to be maintained simultaneously at
various routers within the internet ?



>With IDPR's domain-level routing, intra-domain routing changes are less likely
>to force inter-domain routing changes.

"Less likely" compared to what ?
This assumption may not be correct, as IDPR aims at providing routes consistent
with "required services", and services provided by a domain may be
a function of intra-domain routing.

>We expect that a pair of IDPR entities within a domain will normally be
>connected such that when the primary intra-domain route fails, the
>intra-domain routing procedure will be able to use an alternative route.
>This temporary intra-domain failure will therefore, be invisible at the
>inter-domain level.

That assumes that a domain is at LEAST 2-connected. First of all, this may, or
may not be the common case. Even if the topology is 2-connected, switch failure
may cause inability to select an alternative route. For example, in T3
NSFNET Backbone if an E-NSS that is used to attach a regional network
fails (E-NSS is just a single machine), then the regional network
loses its connectivity altogether. Similar situation exists on T1 NSFNET
if an E-PSP crashes. Thus, even single temporary intra-domain failures will
be quite visible at the inter-domain level, contrary to your assertion.

Even if you have the redundant connectivity, the services provided by such
connectivity may be quite different from the services provided via primary
connectivity.  For example, an E-NSS may have T3 connection to the C-NSS as
its primary link, but only T1 connection as its secondary. Obviously, that
services provided via T1 (in the case when T3 fails) are quite different that
the one provided via T3 (primary).  Thus, if the IDPR route selection is
sensitive to bandwidth, then temporary intra-domain failure will be visible
at the inter-domain level, contrary to your assertion.

Based on these facts your expectations may not be correct. What are the
implications of these expections on the performance of the protocol ?


>Policy gateways distribute routing information only when detectable
>inter-domain changes occur and may also elect to distribute routing
>information periodically as a backup. Thus, policy gateways do not
>often need to generate and distribute routing information messages,
>and the frequency of distribution of these messages depends only
>weakly on intra-domain routing changes.

The frequency with which policy gateways need to generate and distribute routing
information messages depends on:

(1) stability of inter-domain links
(2) stability of inter-domain switches
(3) stability of services provided within a domain

Why do you think that even if the distribution of routing information is
triggered only by detectable inter-domain changes, these changes are not going
to occur often.  Moreover, what does it mean "often" (e.g. once a day,
once per hour) ?


>With domain-level routes, many different traffic flows may use not only the
>same policy route but also the same path, as long as their source domains,
>destination domains, and requested services are identical. Thus, the size
>of the forwarding information database depends on the number of domains
>and source policies and not on the number of hosts in the Internet.

Conceptually this sounds fine, but I wonder how important this feature is in
practice.  I heard several comments that suggest that if there is a traffic
between domains A and B, then the average number of hosts involved in this
traffic is equal to 2 (one source and one destination).  If, indeed, this
is the case, then it does not matter whether "many different traffic flows
may use ... the same policy... and the same path", since on average there
will be only ONE traffic flow.




Section 5:

What is the relation between the prototype implementation and the gated
version ?


*************** An architecture for inter-domain policy routing

As you indicated, there is a new version of the document dated March 1992.
I think you need to give members of the group a chance to read it before
submitting it to IESG.
If this version is identical to the one you posted in July 1991,
then I have quite a few substantial comments on it which I would like to discuss
within the WG (we can do it over e-mail).
If it is different, then I would like to read it, before making any comments.

************** Inter-Domain policy routing protocol specification: version 1

This is again was dated March 1992. Again, I think you need to give members
of the group a chance to read it before submitting it to IESG.