The IP over ATM Mailing List Archive by date

[Curtis Villamizar <curtis@ans.net>]

In message <199601301607.SAA25589@lohi.dat.tele.fi>, Juha Heinanen writes:
> i'm defending philippes arequia proposal (or any other implemented
> concrete proposal) to gain experience with direct atm connectivity
> between hosts not sharing a common lis.  the reason is that this
> community has now tried to solve this direct connectivity issue for
> about three years without any results.  it has been extremely
> frustrating for everyone who has hosts conencted directly to the atm
> fabric.  
> 
> the main reason for this delay has been the rouetr-to-router
> connectivity issue that is very difficult to solve.  anyone who has been
> following the mailing lists during the past couple of weeks has realized
> that instead of reaching a conclusion we are drifting further and
> further away from it.  to me this is a sign of weakness in the ietf
> process which will eventually lead to industry solutions becoming de
> facto standards.
> 
> -- juha


Juha,

If you are talking about NHRP, I think we are drifting towards a
consensus not away.  Maybe we've even arrived:

Proper use of NHRP in some topologies requires the use of an
underlying inter-as and intra-as routing protocol (or an intra-as
outing protocol that carries attributes required by the inter-as
routing protocol used at routing borders).  If used properly, NHRP
does not introduce loops.

Failing to pass inter-as routing information or intra-as routing
information can result in routing loops.  The remaining argument is
whether this is improper use of NHRP or broken underlying routing
(broken by configuring the wrong protocols for the job, ie: improper
usage).

NHRP is moving along.  Documenting its limitations is better than not
documenting it and having things break.  You can buy NHRP
implementations, even though NHRP is a draft.  It might be that the
NHRP server to server protocol changes significantly in future to
overcome other NHRP shortcomings, while the client/server protocol
remains the same to support existing host implementations.

RSVP is also moving along.  RSVP-1 may become a draft standard soon.
You can buy RSVP implementations.  Once controlled load gets rolling,
there will also be a baseline service.

The fact that the IETF does not standardize on the first somewhat to
very broken thing to come along or go with the PC trends is not
indication that the process doesn't work.  If we carried that to an
extreme, we'd all have shut our eyes to the technical limitations and
run NetBIOS and bridging in the mid 1980s.

Curtis