Regional Techs Meeting Agenda
Thu Dec 24 04:02:23 UTC 1992
Hi. As Sheri said we are working on setting up a meeting of the NSFNET
Regional Techs in Boulder on January 21-22. We realize that there is
a FARNET meeting at the same time, and our idea was that while there
wouldn't be formal overlap of meeting topics or agenda, it might be
nice to create possibilities for informal get-togethers. For example,
evening meetings or weekend skiing including both FARNET (regional net
management types) and Regional Tech people.
The reason for this meeting is that we thought the regional techs should
have some time to get together outside of the more general IETF context
for more focused discussion, perhaps leading to specific actions.
There were agreements in ORAD, NJM, and BGPD that we should target
June 1993 as the timeframe for implementation of BGP-4 and route
aggregation. This raises a host of issues and operational questions,
and led in our discussions to proposed agenda below. Our idea was that
we could nominate one or two people to lead each session, and also
"pack" the audience with some friendly experts on the respective
So far we've heard from WestNet, SDSC, BARRnet, UIUC, Sprint/ICM,
SESQUInet, NorthWestNet, Merit, ANS, ESnet and NEARnet, that they can
indeed attend at this time. We'd like to hear some more confirmations
before we send out the final invitation, just to make sure the date and
place is ok with everyone. The US West folks have made a generous offer
to provide conference facilities at no cost to us, and NCAR and WestNet
are also participating in hosting sessions and activities.
Following is the first cut at the proposed agenda. Happy Holidays
Topics for the Seminar:
Focus of the the seminar is Operational planing for 6-8 months.
1.) Implementation of CIDR and Supernetting
CIDR is billed as a short term solution, and to get started there are
immediate operational actions needed. To quote V. Fuller, J. Yu and T.
Li, what is needed are "strategies for address assignment of the
existing IP address space with a view to conserve the address space and
stem the explosive growth of routing tables in default-route-free
routers run by transit routing domain providers." Subtopics to be
- Phase-in of route aggregation
- Policy configuration for aggregation
- BGP-4 test plan
- Requirement for renumbering
2.) Address allocation strategies with CIDR
This session should cover the address administration aspects of CIDR.
We will need to be prepared to handle configuration of address blocks,
and to do this there should be good communication between the
network operators and those handing out the network numbers. Thus
we are inviting the folks from the NIC and possibly the IANA.
3.) GIX, NAPs, Route Servers
There have been several experiments to verify the technology that is to
be used in the "Network Access Points" proposed by NSF, including tests
of route server configurations and the "MAE-East" distributed network.
The IEPG has proposed that the MAE-East be used as a Global Internet
Exchange to allow European networks to connect in a common subnet in
Washington DC. Since it is likely that more prototype or even production
NAPs might be created in advance of the 1994 timeframe, it seems
necessary for the network operators to understand the internet
routing implications that may result. The purpose of this session
will be to discuss upcoming activities to support routing on this
network, and to solicit ideas on how the system should work.
4.) Current Status /Problems
This session will cover the NSFNET network status, including recent
events such as dismantling the T1 backbone, current status and future
plans. In addition to a status report we would like to have a discussion
of Merit's performance, what general problems have been encountered,
and how service quality can be improved.
5.) Transition to "Next Generation NSFNET"
Major transitions of internet operations need quite a lot of planning
in order to happen smoothly. If nothing else, Merit has learned this
over the last few years:-). Though it is too soon to know who the
new players will be for the NSFNET vBNS, RA and NAP providers,
probably enough is known to project some of the potential problem areas,
forecast changes that may occur as a result of the new architecture,
and suggest some preparations that can be made in advance.
More information about the NANOG