A commentary on "A Routing Design for ATM NAPS" Bill Manning bmanning@isi.edu 23 August 1994 Abstract: Attempts to clarify the important points in this document and proposes an alternative that can be deployed in a reasonable timeframe. Commentary: This is an interesting and useful paper. It covers what was current technology in 2q94 and points out one of several methods for supporting ATM in the context of a Routing Registry/Route Server. Several clever approaches were used to overcome gaps in standards implementation by vendors. The approach indicated in section two of the MERIT paper is a common approach that was generally approved in both the NANOG meeting and a NAP participant meeting that was held during the Toronto IETF. The difficulties with the RFC 1490 approach were listed in the Toronto meeting. I list them here: There is no clear migration path from this approach to a more correct/robust implementation using RFC 1577 encapsulation over native ATM (OC3c). There are additional points of failure and additional costs with the requirement for an ADSU. The listed approach requires manual configuration. This appears to lock the NAP into a top speed of 45Mbps or DS3 speeds. In addition to these weaknesses, there were a number of assumptions regarding specific hardware implementations of ATM protocols (use of a very small selection of vendors and limited interfaces) and the ability and/or willingness of the attaching ISPs to work toward a more elegant, cheaper, robust solution at the possible expense of some time while vendors address the implementation gaps. Questions on the desirability of a native media support with RFC 1577 support were posted to the IP-ATM wg of the IETF and the email response was affirmative in recommending an approach with RFC 1483/1577 over AAL5 with LLC/SNAP coding. A brief review of the European PNO pilots seems to indicate that this is the desired approach in that arena too. Even the vendors who were not invited to either meeting have expressed an interest in fixing these problems in the near term, where near term is the next 2 to 6 months. So, I suggest the MERIT paper should not be viewed as the only or desired method of connecting to an ATM NAP. It should be carefully read as the documentation of a successful experiment. --bill
The approach indicated in section two of the MERIT paper is a common approach that was generally approved in both the NANOG meeting and a NAP participant meeting that was held during the Toronto IETF.
And this is the approach two of the NAP providers are planning to implement their NAPs initially.
So, I suggest the MERIT paper should not be viewed as the only or desired method of connecting to an ATM NAP. It should be carefully read as the documentation of a successful experiment.
This paper describes a solution to connect the RS and do routing on the currently planned ATM-NAP technology (i.e. RFC1490/AAL5) based on the availability of the products. If we want to connect to the planned ATM-NAP now, that is the approach. The paper does not address the issue of selecting protocol stacks for the ATM-NAPs. It is beyond the scope of the paper. We have a revised version which clarifies this point. --jessica
participants (2)
-
bmanning@ISI.EDU
-
Jessica Yu