Possible IAB workshop on routing and addressing participants?
David Meyer
dmm at 1-4-5.net
Mon Jun 19 15:19:00 UTC 2006
Folks,
The IAB is considering holding a routing and addressing
workshop, perhaps in the fall 2006 time frame (see the
draft invite below). We're in the process of collecting
potential participants, so please pass along any the
names of folks that that you think would be productive
participants.
Thanks,
--dmm (for the IAB)
----
Greetings,
The IAB is sponsoring a workshop on "Scalable Routing and
Addressing Architectures for the Internet" in order to
foster interchange between the operator, standards,
vendor, and research communities on this important
topic. You are being invited to participate in this
effort.
This workshop effort will consist of mailing list
discussions in advance of, and after a face to face
meeting. The technical goals of this effort are outlined
below. We believe these are the critical elements to
fostering a constructive discussion of important routing
and addressing technical work going forward and are
soliciting workshop participation to work towards those goals.
Should you decide to join us in this workshop, you will
be expected to attend the face to face meeting [0],
contribute to (and possibly present at) that meeting, as
well as follow and participate in the mailing list
discussions.
The most important objective of the workshop is to foster
and encourage innovative thinking in an area where there
has been little fundamental change for the last twelve
years. As such, the primary goals of the workshop include
the following two items:
(i). Produce a concise problem statement that will
serve as the input to future work on this
topic. This problem statement will include, among
other things, a list of the problems with the
current routing and addressing architecture.
These include (but are not limited to):
- The difficulty in changing provider due to
PA/CIDR addressing schemes
- The lack of effective multi-homing support
- Limited capability to protect against either
the spoofing of individual host IP addresses or
entire IP address blocks
- The limited ability to secure the routing
system itself, and
(ii). Produce a prioritized list of requirements, all
of which must be met by a next generation routing
and addressing architecture. A sample list might
include (in no particular order):
- Retaining the connectionless datagram model of
IP routing
- Allow users (small and large) to freely switch
between providers without substantial service
interruption
- Include survival of higher-layer connections
and associations when connectivity to
individual providers changes
- Allow both users and ISPs to influence path
selection according to traffic management and
classification requirements
- Provide better support for mobility and nomadicity
- Provide architected instrumentation facilities
- Allow at least one-to-many multicast
- Prevent source address spoofing
- Provide a rational economic basis for deployment
- Secure the routing infrastructure, including
the authentication of updates and the
unauthorized injection of information into the
routing system
- Define scalability requirements for a next
generation routing system
- Have architected transition mechanisms
and be incrementally deployable (where possible)
During the workshop, scribes will be assigned to
summarize the discussion. Post-workshop, scribes will be
expected to participate in finalizing the workshop
report. All participants will be expected to review the
draft workshop report before publication.
The workshop is <date, <logistics.
Please reply within the next week indicating your
willingness to participate in this workshop. Please
indicate whether (and to what extent) you'd be able to
participate (we'd like an explicit 'no' if you will not
be able to), and what you feel is your area of
expertise. If you can not participate, please suggest
potential alternatives or substitutes.
[0] Attendees will also need to arrange and pay for their own
travel and accommodations.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20060619/387e0ba4/attachment.sig>
More information about the NANOG
mailing list