Comments

Bill Manning bmanning at ISI.EDU
Wed Aug 31 12:42:27 UTC 1994


> >Perhaps.  My biggest concern was that the Merit paper would be construed as
> >the -only- way an ATM NAP would work. They clearly did not indicate there
> >were potential choices nor did they indicate the assumptions that were made
> >for their test.
> 
> Bill, now I doubt if you read the paper carefully or not.

Oh I read it. Several times. I even think I can claim to understand what 
you were saying.

> First of all, this paper does not design the ATM-NAP architecture BUT is a 
> ROUTING DESIGN for the planned ATM-NAP architecture.  Please don't confuse
> these two different issues.  

Your routing design is clever & solves a series of interesting issues that
are raised when level 3 activities are needed in a sub-optimal level 2 
environment.  Good Job.

> For the planned ATM-NAP architecture (i.e. RFC1490/AAL5) with the current
> availability of the RS's (i.e. SUN) ATM interface product, what other choices 
> do we have to connect the RS and do NAP routing at this time frame? 

Native implementation, while a bit fuzzier in the near-term (1-6 months)
has many longer term benefits (see the notes from Milo et al on this thread)
and does not present the ISP with the potential of "forklift" replacment
of (expensive) equipment in less than a year.  Some ISPs may see this 
cost a "noise" in comparison with the overall picture while many more
will see this as a major captial item with a 3-5 year payout.  Can we
afford to live w/ a 1490 implementation for that long?  I, for one,
give the net and its denizens the benefit of the doubt.  I would expect
the trafic loads on the infrastructure to exceed 45Mbps before 3 years.

Now the main problem I have is that there is a gap in product availablity.
There are only a handful of vendors looking at solving these problems for
people.  If Cascade is successful, then part of my argument folds. However,
this product is further behind the release curve than other vendors 
solutions.  No easy way out of the mess, but there are alternatives to
RFC1490 implementations that have much more flexability and are feature
rich.  I think we should be willing to experiment and test before we
foist a 1490 model onto the unsuspecting ISPs and hang ourselves with
a deadend technology for years.

Mind, I am willing to buy off on a crippled, brain-dead, solution IF
there is no other way. I just want it to be VERY clear that I won't go
willingly and I want others to know why.  After all, everyone is 
entitled to my opinion. :)

--bill





More information about the NANOG mailing list