nanog mailing list archives

Re: Comments


From: bmanning () ISI EDU
Date: Tue, 30 Aug 1994 08:07:28 -0700 (PDT)

Thank you for your insightful comments.  I would like to be enlightened
on exactly how a proposed migration from RFC1490 to RFC1483/1577 will
occur.  As I understand it, there needs to be a translation method
between NLPID and LLC/SNAP. There seem to be other locations in the
stack where translation must occur. Is there capability today or even 
planned that will do these translations?

            There is no clear migration path from this approach to
            a more correct/robust implementation using RFC 1577
            encapsulation over native ATM (OC3c).

My conversation with Cisco indicates that 1490/AAL5 software patch for
AIP is available and 1483/AAL5 for ADSU and 1483/AAL5 for T3-AIP should
be available withing about 6 months.  So, indeed ther are several migration
path available, not clear which is the best for all NAPs.  Perhaps different
NAP location may have different business needs based on what their customers
desire.

True. 

            There are additional points of failure and additional costs
            with the requirement for an ADSU.

I think HSSI is a proven technology.  HSSI/ADSU probably has lower
failure rate than AIP based on the typical bath tub curb for new product
reliablity.

The points of failure are the additional cables and connectors, not to mention
the electrionics of a seperate box (the ADSU) and power. These cost, plus
the extra rack space and potential co-location fees to accomodate this extra 
gear.  Your concerns wrt infant mortality on new hardware seem to apply 
to the ATM switches in general. Most of the equipment, while being 
"long in the tooth" as far as cell switching capability is concerned, has a 
-very- limited exposure to data transmission. Even the closed ATM Forum
has trouble standardizing specs that appear to be needed to support full 
interoperability (just when will UNI3.1 come out and when will the text
be available on-line?... but I digress)

            The listed approach requires manual configuration.

I like the flexibility of AIP, but how to configure AIP to avoid congestion
is still a research topic for me.

As it is for everyone.  The manual configuration specified here is the need
to code static routes and ARP entries to make BGP4 work. Traffic shaping
does not even come into this equation.

            This appears to lock the NAP into a top speed of 45Mbps
            or DS3 speeds.

Hopefully, we can unlock this as soon as we feel comfortable with other
approaches.

HISSI at faster than 45Meg?  I am very interested.
Please tell me more.


BTW, I think the Merit paper is useful and good work as you said.  Since
RFC1490 is the only viable option exposed to Merit, saying it is one of those
is a bit too harsh.


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
- - - - - - - - - - - - - - - - -


Current thread: