Re: Comments

[ltwu () faline bellcore com (Liang T. Wu)]

> From bmanning () ISI EDU Tue Aug 30 11:08:01 1994
> Subject: Re: Comments
> To: ltwu () faline bellcore com (Liang T. Wu)
>
> 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?

I understand Cascade claims to have such boxes.

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


We need to separate out issues regarding ATM switches and ATM interfaces
for routers.  We have been dealing with ATM switches since 1982, at that
time we call it Fast Packet Switch.  So, we know much more about it and
have trained scores of experts to deal with it.  The commercial grade
ATM switch that we are dealing with now for NAP are designed based on
CO requirement, meaning it is overbuild and modularized based on certain
engineering practice and has been tested extensively by telcos.  The biggest
issue now is to regineering the equipment for AAL5 type traffic since most
of the switches were designed for "isochronous" traffic at the beginning.

Router interface is another story.  They are new and they interface
with heterogenous network world.  So, new rules have to be established
jointly by data networking and telecomm communities.

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

We/NAP people are knowledgeable on "layer 2" and are eager to learn about
the layer 3 problems.  We like to help if we can.  Let me know how
can we get involved with the BGP4 development from layer 2 point of view.

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

I did not mean that.  But HISSI at SONET rate may have some nich in the
market.  It is a marketing decision for router guys.

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