Draft minutes for IETF Network Status Reports. - please comment.
Gene Hastings <hastings@psc.edu> Wed, 10 August 1994 12:01 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01761; 10 Aug 94 8:01 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01757; 10 Aug 94 8:01 EDT
Received: from merit.edu by CNRI.Reston.VA.US id aa04233; 10 Aug 94 8:01 EDT
Received: from mailer.psc.edu (mailer.psc.edu [128.182.62.100]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id HAA12187; Wed, 10 Aug 1994 07:40:37 -0400
Received: from gene61.psc.edu by mailer.psc.edu (5.65/Ultrix3.0-C 11/12/92 nydick) id AA06128; Wed, 10 Aug 1994 07:40:24 -0400
Message-Id: <9408101140.AA06128@mailer.psc.edu>
X-Sender: hastings@b.psc.edu (Unverified)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 10 Aug 1994 07:40:36 -0400
To: njm@merit.edu
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Gene Hastings <hastings@psc.edu>
Subject: Draft minutes for IETF Network Status Reports. - please comment.
Cc: nanog@merit.edu
GREAT THANKS to Marsha Perrott for chairing the meeting in my absence and Rob Reschly for the notes. There are a couple places where the note-taker was not sure of the details, please corroborate places with (?). Thanks, Gene > Minutes of the Toronto IETF'30 Netstat Working Group > ================================================================ > submitted to perrott@prep.net > submitted by reschly@arl.mil > > ================ > CoREN: > Scott Bradner > > The status of the CoREN Network Services Request for Proposals (RFP) > process was briefed. Scott emphasized one key feature of this RFP: it > will result in a contract to provide services to the regionals, not in a > contract to build a backbone to interconnect regionals. Since they are > buying a service, CoREN expects to be one customer among many using > the same service. > > CoREN does not want to have to rely on the NAPs for everything. CoREN > feels NAPs and RAs are a good idea, but.... > > Scott observed that dollars flow from the NSF to the Regionals to fully > connected network service providers (NSPs) to the NAPs. The only NSPs > eligible to provide connectivity paid for by NSF funding are those which > connect to the all primary NAPs (NY, IL, CA). > > The CoREN provider will establish connectivity to all primary NAPs, > MAE-East, and the CIX. > > Scott was asked about planned NOC responsibilities: NOC integration > and coordination is being worked on. Discussion points are relative > responsibilities, e.g. NEARnet vs CoREN provider hand-off. > > When asked for information on non-CoREN American provider plans, Scott > knew of at least two providers who will be at other NAPS. Scott > indicated MCI will be at the Sprint NAP soon. Others later. > > As for the CoREN RFP evaluation, more than one of proposals was pretty > close from a technical perspective, and they were close financially. > The selected provider came out ahead in both measurements and > additionally offered to support a joint technical committee to provide a > forum for working issues as they arise. In particular, early efforts > will focus on quantifying QOS issues as they were intentionally left out > of the specification so they can be negotiated as needed (initially and > as the technology changes). > > The circuits are coming in and routers (Cisco 7000s) are being installed > in the vendor's PoPs this week. First bits will be flowing by 1 August. > Line and router loading and abuse testing is expected to commence by 15 > August, and production testing is should be underway by 15 September. > Cutover is expected before 31 October. > > Someone noted there may be some sort of problem related to route cache > flushing in the current Cisco code which could impact deployment. > > ================ > NC-REN (formerly CONCERT): > Tim Seaver > > CONCERT is a statewide video and data network operated by MCNC. > - primary funding from State of NC > - currently 111 direct, 32 dialup, and 52 uucp connections > - 30K+ hosts > - 4.5Mbps inverse multiplexed 3xDS1 link to ANS pop in Greensboro, NC > > Replaced by NC-REN > - expands to North Carolina Research and Education Network > - DNS name is changing from concert.net to ncren.net > > Service changes: > - dropping commercial services > - concentrating on R&E > - focus on user help > > Main reason for name change: > - British Telecomm and MCI wanted the CONCERT name. MCNC never > registered CONCERT. > > In return MCNC management wanted: > - NC service community more prominent > - alignment with NREN > - emphasis on R&E > > Press release 15 April > Conversion to ncren.net in progress > - Domain registered February 1994 > - Local changes simple but time-consuming > - Remote changes hard and time consuming > - Targeting 1 October completion fairly sure of conversion by 31 > October > - Decommission CONCERT by 1 January 1995 > > Existing service problems: > - Help desk overloaded from dialup UNIX shell accounts > - Commercial providers springing up everywhere > - The Umstead Act (a NC state law) says state funds cannot subsidize > competition with commercial services. > - CONCERT had sufficient non-governmental funding to cover commercial > services, but accounting practices could not prove separation so > they just decided to just stop. > > Service changes > - Turned over dialup UNIX shell connectivity to Interpath March 1994 > - Planning to stop providing commercial IP and UUCP services by > October 1994 > - Planning to stop providing commercial direct services by 1 January > 1995 > - Will continue direct connects, IP, UUCP for government, research and > education customers. > > Plans: > - Pursuing new R&E customers: > Remaining private colleges > Community colleges > K-12 schools > State and local government > Libraries (?) > - Providing security services: > firewalls, Kerberos, PEM, secure DNS, secure routing. > - Expanding information services: > m-bone, NC state government documents, WWW services, and > consultation -- to provide more access > - Internet connection will be upgraded to 45Mbps October, 1994 > - Work on a NC Information Highway (NCIH) > > In response to a question about NC microwave trunking he noted that the > Research Triangle Park area is at 45Mbps and remote areas are at 25Mbps. > > In passing he noted ATM interaction with research community is an > interesting opportunity, indicating Southern bell GTE and Carolina > telephone working ATM infrastructure > > In response to a question about the number of sites changing to NC-REN > he stated there were about 20 R&E direct connections which would move, > and that the narrowed focus of the NC-REN would not change the cash flow > model significantly. > > > ================ > "Transition from NSFnet Backbone to the NAPland": > Sue Hares > > Available via WWW at URL: http://rrdb.merit.edu > > If mid-level networks want to send Sue information concerning any > aspects of plans to transition, please do. Also indicate what can > be published (this second permission is hard) -- Sue will respect > confidentiality requirements. They desperately need information about > local and regional plans so they can manage the transition for NSF. > > NOTE: The following is incomplete because Sue went through it very > quickly. However, as a teaser if nothing else, some of the information > on the slides available at the above URL is included below, as well as > most of the significant discussion.... > > NAP online Dates: > Sprint NAP 11 August > PacBell mid-September > Ameritech 26 September > > Currently scheduled NSFnet service turn-down. Note this does not say > anything about tangible infrastructure changes, only NSFnet service > plans. That is, NSF says they intend to stop paying for the forwarding > of traffic via the indicated ENSSs, no more, no less: > > Category 1 CoREN (numbers are ENSSs): (first round) > BARRnet 128 > SURAnet 138 136 > SESQUInet 139 > MIDnet 143 > CICnet 130 129 131 > NYSERnet 133 > NEARnet 134 > NWnet ??? Sue missed this one on her slide > > In conversation it was reported that PREPnet is not to use PSC > connection for access after 1 October. > > The real message is that these and following numbers are "official > notification" for management planning. It was recommended to "flick the > lights" before actual turn-off -- i.e. install the replacement > connectivity and turn off the NSFnet connection to see what breaks. > > Again Sue pleaded for information as it becomes available and permission > to announce it as soon as possible. > > Category 2 Regional ENSSs > Argonne 130 > PREPnet 132 > CA*net 133 143 137 > ALTERnet 134 136 > PSI 136 133 > JvNCnet 137 > THEnet 139 > > Category 3 Regional ENSSs > MICHnet 131 > > > NOTE: More complete information concerning the above is available > online. > > Sue reiterated that the "decommissionings" are simply organization's > status as recipient of NSFnet services. It would be a good idea for > each affected organization to talk to any or all service providers > between the organization and the NSFnet for details about other aspects > of the connection. > > As for the differences between between the categories; category 1 > is primarily CoREN, category 2 is the other regionals, and category 3 > includes supercomputer sites and less firmly planned sites. > > More information welcomed: > Anyone got a contract from NSF? > Anyone want to tell Sue their NSP? > Got some private announcements, need more. > > Want information to forward to NSF even if not public. Will respect > privacy, but important to inform NSF even if caveated by "may change > because..."... > > When asked about the time-lines for the various categories, it was > stated that NSF wants to have the category 1 sites switched off the > NSFnet by 31 October. Beyond that, it is currently phrased as a best > effort task. > > There was some discussion about CoREN test and transition plans: Note > that load and trans-NAP plans are still being worked. There appears to > be significant concern about not taking any backwards steps. > > One proposed working bilateral testing agreement. This provoked > discussion of a tool called offnet (?) (and some nice tools Hans-Werner > Braun has written). Some or all of these tools will be made available > by Merit, however it was stress that use by the regionals is intended to > instrument local sites, and cannot Merit allow additional to connections > NSFnet backbone monitoring points. > > ================ > NSFnet statistics: > Guy Almes > > Traffic is still doubling! Traffic topped 70 Gigapackets per month in > May and June. > > Guy noted that December 94 chart will be interesting -- how to measure, > and what makes sense to measure, new in backboneless regime. There will > be a transition from traffic into backbone to traffic into multiple > whatevers. Should any resulting numbers be counted? It was observed > that it would be hard to avoid double counting in such an environment. > > The general consensus was that there is a need to pick an appropriate > set of collection points: e.g. transition from BARRnet to/from NSF to > BARRnet to/from CoREN provider. > > One position contends that we really want customer to BARRnet data > rather than BARRnet to CoREN provider. However it was observed that this > is not tractable or trackable. > > Other statistics show: > 952 Aggregates currently configured in AS690 > 751 announced to AS690 > 6081 class based addresses represented > > There were two additional slides depicting: 1)IBGP stability: solid line > is percentage of IBGP sessions which have transitions during the > measurement intervals, and 2) Eternal route stability: solid line is > external peers. > > Data collection is once again in place on backbone and has been > operational since 1 June. > > In conversation, it was noted that the Route Servers will be gathering > statistics from the NAPs. The Route Servers will be gated engines and > will be located at the NAPs > > > UPDATES: > ANS router software activity > Software enhancements: > RS960 buffering and queueing microcode updated > > - increased number of buffers, also went from max MTU sized buffers > to 2+kB chainable buffers (max FDDI will fit in two buffers with > room to spare. > > - dynamic buffer allocation within card > > -- two together really improve dynamic burst performance > > Design for improved end-to-end performance > > - Based on Van Jacobson and Floyd random early drop work. > > - End-to-end performance is limited by bandwidth delay product > > - current protocols deal gracefully with a single packet drop but > multiple packets dropped push algorithm into slow start. With > "current" van Jacobson code, even brief congestion in the path will > cause things to back off under even low end loadings. > > Work shows that Random Early Drop slows things just enough to avoid > congestion without putting particular flows into slow-start. > > In passing, Guy noted that he figures the speed of light as roughly > 125 mi/ms on general phone company stuff. > > The conditions and results were summarized on two slides: > > + Single flow Van Jacobson random early drop: > > 41Mbps at 384k MTU cross-country (PSC to SDSC?) > > This code (V4.20L++) is likely to be deployed in a month or so. > > By way of comparison Maui Supercomputer center to SDSC was 31Mbps using > an earlier version of code with 35 buffers. Windowed ping with the same > code did 41Mbps. > > + Four flow Van Jacobson random early drop: > > 42Mbps at 96kB MTU. > > All the numbers are with full forwarding tables in the RS960s > > In other news...: > + SLSP support for broadcast media completed > + Eliminated fake AS requirement for multiply connected peers. > + Implemented IBGP server. > ... > > Pensalken (the SPRINT NAP) is a FDDI in a box. > > ================ > CA*net: > Eric Carroll > > All but three backbone links are now at T1 and there are dual T1s to > each US interconnect. > > Pulled in Canadian government networks. Using Ciscos to build network. > > Still seeing 8-10x US costs for service. CA*net will grow to DS3 when > can get and afford (!). > > Numbers on map slide are percentage utilization. Note that 12 routers > were installed between mid-March and the end of April and these are > early numbers. Note that the British Columbia to NWnet link T1 went to > saturation in 5 hours. Appears to be due to pent up demand, not > particular users or programs. > > 7010 roll-out had a lot of support from Cisco. Ran into some problems > with FT1 lines in queuing discipline. > > Still doing NNSTAT on an RT for now, but working with a RMON vendor to > get stuff for new implementation. > > When asked about using inverse multiplexors for increased bandwidth, > Eric indicated CA*net was currently just using Cisco's load sharing > to US, however they would be considered when needed. > > A question was raised about CA*net connectivity plans in light of the > impending NSF transition. Currently international connectivity is just > to US, specifically to the US R&E community. There is some interest > and discussions for other international connectivity, but cost and other > factors are an issue. > > CA*net hopes to place NSF connectivity order by next week. > > Biggest concern is the risk of becoming disconnected from what Eric > termed the R&E affinity group. > > CA*net currently carries ~1000 registered ~900 active networks in > CA*net. > > CA*net is not AUP free, instead it is based on a transitive AUP > "consenting adults" model. If two Canadian regionals or providers agree > to exchange a particular kind of traffic then CA*net has no problem. > > CA*net just joined CIX which prompted a question as to whether Onet is > a CIX member. In response Eric characterized CA*net as a cooperative > transit backbone for regional members. Therefore CA*net joining CIX is > somewhat meaningless in and of itself, and, by implication, is only > meaningful in the context of the regionals and providers interacting > via CA*net. > > In response to another question, Eric indicated that CA*net is still > seeing growth. > > > ================ > MAE-East Evolution: > Andrew Partan > > (MAE == Metropolitan Area Ethernet) > > Andrew volunteered to conduct an impromptu discussion of MAE-EAST plans > > There is an effort underway to install a FDDI ring at the MFS Gallows Rd > PoP and connect that ring to MAE-East using a Cisco Catalyst box. > > MAE-East folks are experimenting with GDC Switches > > Is there a transition from MAE-East to the SWAB?: Unknown > > (SWAB == SMDS Washington [DC] Area Backbone) > > MFS DC NAP is proposing to implement using NetEdge equipment. > > Any MAE-East plans to connect to MFS NAP?: Unknown. > > ALTERnet is currently using a Cisco Catalyst box and is happy. > > Time-frame for implementing MAE-East FDDI?: Not yet, still need > management approval. Hope to have a start in next several weeks.. > > Those interested in MAE-EAST goings-on and discussions with members > should join the mailing list MAE-East[-request]@uunet.uu.net > > For what it may be worth, they "had to interrupt MAE-LINK for 5 seconds > this week to attach an MCI connection". > > In summary (to a question) one would contract with MFS for connectivity > to MAE-East. Then one would need to individually negotiate pairwise > arrangements with other providers with which there was an interest in > passing traffic. As far is as known there are no settlements currently, > but cannot say for sure. > > ================ > Random Bits: > > SWAB (SMDS Washington Area Backbone): In response to point of confusion, > it was stated that the SWAB bilateral agreement template is just a > sample, not a requirement > > CIX: The CIX router is getting a T3 SMDS connection into the PacBell > fabric. ALTERnet and PSI are doing so too. CERFnet currently is on. > > Noted in passing: Each SMDS access point can be used privately, to > support customers, to enhance backbone, etc.... This could have serious > implications for other provider agreements. > > CERFnet: Pushpendra Mohta (? --not at the meeting) is reported to be happy, > but the group understood that most CERFnet CIRs are at 4Mbps over T3 > entrance facilities. PacBell was reportedly running two 2OOMbps (is > this the really correct, seems rather low?) backplane capacity switches > interconnected with single T3. Planning to increase provisioning -- > already have a lot of demand. > > >
- Draft minutes for IETF Network Status Reports. - … Gene Hastings
- Re: Draft minutes for IETF Network Status Reports… Susan Hares
- Re: Draft minutes for IETF Network Status Reports… Pushpendra Mohta
- Re: Draft minutes for IETF Network Status Reports… Martin Lee Schoffstall
- Re: Draft minutes for IETF Network Status Reports… Curtis Villamizar