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

[Yakov Rekhter <[e-mail]>]

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 is to respond to your general comments. I'll send a separate note
replying to your specific comments.

The major point made in the document is that the choice between "local"
and "remote" decision should be totally decoupled from the addresses of
src and destination.

The NHRP model forms a subset of what is described in the document, as
the NHRP model allows to have "local" outcome regardless of the
addresses. But there is yet another point that is not covered by the
NHRP model (but is covered by the document) - "remote" outcome should
also be possible regardless of addresses (even if hosts are on a common
IP subnet).

I have no problems of describing the decoupling the "local/remote"
outcome from the addressing information as "an extension" (or probably
"evolution").

Yakov.