Ann Arbor, Michigan
Converted 27 October, 1994 at Merit Network, Inc. by Ken Latta
Guest Editor: Stan Barber (sob@academ.com )
Notes Version 2 Here are my notes from the recent NANOG meeting. Please note that any mistakes are mine. Corrections, providing missing information, or further exposition of any of the information here will be gratefully accepted and added to this document which will be available via anonymous ftp later this month.
Thanks to Guy Almes and Stan Borinski for their corrections and additions to these notes.
See the document: Comments about October 1994 Meeting Notes
-Stan
Consider the case of telnetting across the Internet and getting what appears to be your machine's login banner. Doing a double check (host->address, then address->host) will help eliminate this problem. hosts.equiv and .rhosts are also sources of problems. Polluting the cache is a real problem. Doing UDP flooding is another problem. CERT says that doing rlogin is bad, but that does not solve the cache pollution problem.
2. There are a number of static validations of packet format that can be done. Adding some kind of cryptographic information to the DNS would help. Unfortunately, this moves very slowly because there are a number of strong conflicting opinions.
Paul may rewrite this server in the future, but it will still be called named because vendors have a hard time putting it into their releases if it is called something else.
Paul is funded half-time by the Internet Software Consortium. Rick Adams funds it via UUNET's non-profit side. Rick did not want to put it under GNU.
DNS version 2 is being discussed. This is due to the limit in the size of the udp packet. Paul M. and Paul V. are working to say something about this at the next IETF.
HP, Sun, DEC and SGI are working with Paul to adopt the 4.9.3 BIND once it is productional.
After this comes out, Paul will start working on other problems. One problem is the size of BIND in core. This change will include using the Berkeley db routing to feed this from a disk-based database.
There will also be some effort for helping doing load-balancing better and perhaps implementing policy features.
What about service issues? Providing name service is a start.
DEC and SGI will be shipping BIND 4.9.3 will be shipping it with the next release.
Paul has talked to Novell, but noone else....Novell has not been a helpful from the non-Unix side.
The Global Routing Registry consists of the RADB, various private routing registries, RIPE and APNIC. The RADB will be used to generate route server configurations and potentially router configurations.
1993 -- RIPE 81 1994 -- PRIDE tools April 1994 -- Merit Routing Registry September 1994 -- RIPE-181 October 1994 -- RIPE-181 Software implementation November 1994 -- NSP Policy Registrations/Route Server Configurations
The Route Servers are up and running on a testbed and have been tested with up to 8 peers and 5 views. Target ship date to 3 NAPS is October 21. The fourth will soon follow.
The Network Management aspect of the RA project uses a Hierarchically Distributed Network Management Model. At the NAP, only local NM Traffic, externalizes NAP Problems, SNMPv1 and SNMPv2 are supported. OOB Access provides seamless PPP backup & console port access. Remote debugging environment is identical to local debugging environment. The Centralizes Network Management System at Merit polls distributed rovers for problems, consolidates the problems into ROC (Routing Operations Center) alert screen. It was operational on August 1st, operated by the University of Michigan Network Systems at the same location as the previous NSFNET NOC. This group current provides support for MichNet and UMNnet. It is expected to provide service to CICnet. Currently, it provides 24/7 operator coverage.
Everything should be operational by the end of November.
Routing Futures -- Route Server decoupling packet forwarding from routing information exchange, scalability and modularity. For example, explicit routing will be supported (with the development of ERP). IPv6 will be provided. Doing analysis of RRDB and define a general policy language (backward compatible with RIPE 181). Routing policy consistency and aggregation will be developed.
Securing the route servers -- All of the usual standard mechanisms are being applied. Single-use passwords.... mac-layer bridges .... etc....How do we keep the routes from getting screwed intentionally? Denial of service attacks are possible.
There is a serious concern to sychronization of the route servers and the routing registries. No solution has been implemented currently. Merit believes that will do updates at least once a day.
The RADB has none of these features.
Migration will occur before April of 1995. The PRDB will be temporarily part of the Global Routing Registry during transition.
Real soon now -- Still send NCAR and it will be entered into PRDB and RRDB. Constancy checking will be more automated. Output for AS 690 will be compared from both to check consisteconsistancyncy. While this is happening, users will do what they always have. [Check ftp.ra.net for more information.]
There is alot of concern among the NANOG participants about the correctness of all the information in the PRDB. Specifically, there appears to be some inaccuracy (homeas) of the information. ESnet has a special concern about this.
RADB to generate AS690 on second week of December.
NACRs to die at the end of that week.
[I missed this, so this information is from Stan Borinski]
Peter provided some humorous, yet interesting observations on the status of the Internet in Europe.
To show the tremendous growth occurring in Europe as well, he gave an example. After being out of capacity on their Stockholm E1 link for some time, they finally installed another. It took one day for it to get it to capacity! Unfortunately, the E1 costs $700,000/year.
[Back to my notes.... -- Stan Barber]
But what about "MORE THRUST?" It's not a good answer. Drives the costs up, doesn't help with complexity of operations, eliminates small providers
Proxy aggregation -- A mechanism to allow aggregation of routing information originated by sites that are BGP-4 incapable.
Proxy aggregation -- problems -- full consensus must exist for it to work.
Local aggregation -- to reconnect the entity that benefits from the aggregation and the party that creates the aggregation. Bilateral agreements would control the disposition of doing local aggregation. Doing the aggregation at exit is better, but harder than doing it at entry.
Potential Candidates for Local Aggregation -- Longer prefix in presence of a shorter prefix, Adjacent CIDR Blocks, Aggregation over known holes.
Routing in the presens of Local Aggregation
Yakov also noted that 64Mb routers won't last as long as IPv4.
[More notes from Stan Borinski, while I was out again.]
[Back to my notes -- Stan Barber]
NSFNET/ANS connected via Hayward today.
MCINET via Hayward today.
PB Labs via Concord today.
Sprintlink connected via San Jose (not yet).
NETCOM connected via Santa Clara in the next Month.
APEX Global Information Services (based in Chicago) will connect via Santa Clara, but not yet.
The Packet Clearing House (consortium) for small providers connected via Frame Relay to PB NAP. They will connect via one router to the NAP. It is being led by Electric City's Chris Allen.
CIX connections are also in the cloud, but not in the same community yet.
Testing done by Bellcore and PB.
One Source-> One Sink
MSS Window Througput (out of 40Mb/sec) 4470 51,000 33.6 4470 25,000 22.33Two Source -> One Sink
4470 18,000 33.17 (.05% cell loss, .04%packet retrans) 1500 51,000 15.41 (.69% cell loss, 2.76% packet retrans)
Maximum througput will be higher when the DSU HSSI clock and data-rate mistmatch is corrected.
Cell loss rate is low (.02% -- .69%).
Througput degraded with the TCP window size is greater than 13000 bytes.
Large switch buffers and router traffic shaping are needed.
[The results appear to show TCP backing-off strategy engaging.]
March 1995 -- Variable Bit Rate, Sub-Rate Tariff (4,10,16,25,34 and 40Mbps on 51, 100 and 140Mbps on OC3c). At CPE: Static Traffic Shaping and RFC 1483 and 1577 support [Traffic Shaping to be supported by Cisco later this year in API card for both OC3c and T3.]
June 1995 -- Support for DS1 ATM (DXI and UNI at 128, 384 kbps and 1.4Mbps)
1996 or later -- Available Bit Rate and SVCs. At CPE: Dynamic Traffic Shaping
Notes on Variable Bit Rate:
RFC 1191 is very important as is RFC-1323 for these problems to be addressed.
RFC 1191 -- Path MTU discovery
RFC 1323 -- High Performance Extensions for TCP
The work that was done -- previous work showed that top speed for TCP was 30Mbs.
The new work -- TCP Single Flow, TCP Multiple Flow, using TCP RED modifications (more Van Jacobson majic!) to handle multi-size windows.
Environment -- two different DS3 paths (NY->MICH: 20msec; NY->TEXAS->MICH: 68msec), four different versions of the RS6000 router software and Indy/SCs
Conditions -- Two background conditions (no background traffic, reverse TCP flow intended to achieve 70-80% utilization)
Differing numbers of TCP flows.
Results are available on-line via http. Temporarily it is located at:
http://tweedledee.ans.net:8001:/
It will soon be referenced at http://www.ra.net/napinfo.html
It is important that vendors support RED and the two RFCs previously mentioned to handle this problem. Also, Curtis believes that the results presented by the NAP operators has little validity because there is no delay as a component of their tests.
MAGIC -- Gigabit TestBed
Currently Local Area ATM switches over SONET. Mostly FORE switches.
Lan encapsulation (ATM Forum) versus RFC 1537
Stan | Academ Consulting Services |internet: sob@academ.com Olan | For more info on academ, see this |uucp: bcm!academ!sob Barber | URL- http://www.academ.com/academ |Opinions expressed are only mine.