Draft minutes for IETF Network Status Reports. - please comment.
Gene Hastings
hastings at psc.edu
Wed Aug 10 11:40:36 UTC 1994
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 at prep.net
> submitted by reschly at 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.
>
>
>
More information about the NANOG
mailing list