CURRENT_MEETING_REPORT_
Reported by Noel Chiappa
Minutes of the New Internet Routing and Addressing Architecture BOF
(NIMROD)
The Nimrod BOF met on Thursday, November 4, 1993. The discussion was
lead by Noel Chiappa. Isidro Castineyra, co-chair, took notes on the
discussion.
Agenda
o Agenda bashing.
o Review of proposed charter.
o Review of existing and proposed new terminology.
o Debate on some items from ``open architectural issues'' list.
o Work plan for immediate future.
No changes to the agenda were proposed. Also, there were no comments on
the charter and the terminology listing. This was an introductory
meeting intended to start the group's work, as such it consisted of the
discussion of basic open issues. The rest of these minutes record the
discussion on the open issues and the work plan agreed to.
Open Issues Discussion
o Can clusters overlap?
The argument was made that overlapping clusters would be necessary
for re-organization of cluster boundaries to provide a better
abstraction hierarchy as the physical topology changed. In this
situation, interoperation and updating would be much easier if both
the old structure and the new could co-exist for a while. Once
this mechanism---overlapping clusters---is available, it could be
used for other---unspecified---means.
It was also pointed out that overlapping clusters will result in
endpoints possibly having multiple locators, this could be
(mis?)-used for biasing the route generation mechanism. Some
people favored this, saying that having multiple locators allowed
clients to select which one gave the desired routing behavior.
Others maintained that this was exactly the wrong way to do policy,
and the locator should simply uniquely name the location of the
endpoint, and preferred that other mechanisms---within the routing
component---be defined for the purpose of policy, route
optimization, etc. Route suffixes, as proposed by David Clark, are
one example of such a mechanism.
It was argued that overlapping clusters would make difficult the
enforcement of transit policies. An alternative mechanism to
overlapping clusters, to allow re-organization, would be to have
multiple hierarchies at different levels. If a simpler
re-organization mechanism could be found, overlapping clusters
might be unnecessary, resulting in a simpler architecture.
o Are abstraction levels identified explicitly?
It was argued that explicit levels would prevent growth of the
network map at different levels of the network. (In some sense,
this is the same question as ``Do locators grow up, down, and can
they be expanded in the middle?'')
In other words, if an endpoint were located at A.B.C.D.E (to invent
a representation of a multi-level hierarchical locator), and
cluster A.B.C became too large, so that it had to be split up into
C1 ... CN, (resulting in locators of the form A.B.C.C5.D.E), this
process would be made more difficult if the cluster A.B.C.D was
known to be at the fourth level (counting from the top; the
equivalent is A.B being at the fourth level, if counting from the
bottom).
It was also argued that if locators are given from the top,
explicit levels are not necessary. (Another way to put this is
``Are partial locators possible?'') On the other hand, if the
locators can grow on the top end (as the network expands, say), a
locator which used to start at the top level no longer does so.
Since these old locators are likely to be around for a while after
a new level is added, some way has to be found to deal with them.
o Are the labels of locators globally unique?
This question is obviously related to the previous question of
partial locators. If the label of each element in a locator is
globally unique, it is not necessary to specify which context
(i.e., location in the abstraction hierarchy) to use to interpret
any partial locator.
It was pointed out that globally unique labels, while theoretically
attractive, would make locators very long. The consensus was that
this was probably not necessary.
o Do we have a hop-by-hop mode, or just source routed packets and
flows?
It was argued that a hop-by-hop mode is, in a sense, inherent in a
hierarchical network, because intermediate points might have to
supply additional route detail not contained in the original source
route, when this has been generated using a map without the
necessary detail. Such detail might have been unobtainable, if a
cluster has an information-hiding policy which prevents any
information about the internal topology of that cluster from going
outside the cluster.
Strictly speaking, this does not have to be handled by a hop-by-hop
mode, since the entry point into the closed area could generate the
rest of the path on entry, and either add it to the flow path (for
a flow setup), or the source route in the packet (for a
source-routed packet). However, such a cluster could run
hop-by-hop mode inside the cluster without anyone outside being any
the wiser. (In fact, Nimrod imagines that exactly such an
operational mode will be used during Nimrod deployment, to handle
areas of non-converted old-style routing.)
However, this does not fully answer the original question, since a
hop-by-hop mode would mean that all routers in the system have to
support such a mechanism, not just those in closed areas. The
question really is ``How little detail can a source give in a
source route?'' If the minimum source route consists of only the
destination locator, then the system does have to support
hop-by-hop mode, or at least something which looks a lot like it,
in the sense that the source just labels the packet with the
ultimate destination, and lets the routers work out how to get the
packet there.
o Do we retain the EGP/IGP split?
The consensus was that the EGP/IGP split cannot be eliminated, as a
given cluster that does not give out its internal organization can
always operate internally using any routing architecture it wishes,
as pointed out above. However, the notion of a single defined
level which is ``the'' EGP/IGP boundary does appear to be
counterproductive.
o When do we tackle multicast?
It was suggested that multicast should be made the fundamental
mode, with unicast as a special case of multicast. It was also
pointed out that multicast affects only route generation and
forwarding, the other components of routing---i.e., network
connectivity representation, map distribution, etc.---are
independent of the existence of multicast.
o Do the nodes in the graph representation of the network represent
interfaces or routers/networks?
This debate went on for a while, but no definite conclusion was
reached. Those in favor of the former pointed out that it provided
the most flexibility, and avoided situations like the difficulty of
modeling a router which fell on an administrative boundary. Those
in favor of the latter pointed out that interfaces and routers are
the basic physical constituents of the network, and the map needed
to be able to model them in a way that was both efficient (i.e.,
not in a way that needed N2 arcs to model the internal connectivity
of a network or a router) and easy to understand (since we need to
build a system that many, many people will need to be able to work
with).
o What is the smallest thing which can be a cluster?
This point is obviously closely related to the one above. There
were arguments in favor of interfaces, in favor of routers, and in
favor of networks.
o Do routers have locators?
Some think that routers can have locators, but, depending on the
level of abstraction, these might not be available.
The problem with routers having locators is that if a router is
connected to two widely separated points in the abstraction
hierarchy, which branch of the abstraction hierarchy do you place
the router in? Alternatively, you can provide it with a locator
which is at the same level as that at which the two branches join,
but if there are many such routers, this may present a problem.
Yet another alternative is to assign such a router several
locators, one for each place where it is connected, but if this is
done, perhaps it makes more sense to think of the locators as
naming the interfaces, not the router.
A related question is ``Can we tell by looking at a locator whether
it names an interface, a network, a router, or a cluster?''
o Do we have separate namespaces for interfaces and endpoints?
Mobile endpoints are easier to handle if the endpoint has a name
which stays constant while it moves. It is hard to see how to
provide the latter without having a separate, non-topologically
oriented, namespace for endpoints.
The question then becomes ``Do the topologically oriented names
(i.e., locators) name endpoints or interfaces?'' This is related
to the question above. If an endpoint is in a host which has two
widely separated interfaces, exactly the same set of options are
available for dealing with the situation.
Action Items
The following action items were decided on:
o We will try to schedule the next IETF meetings for Tuesday and
Wednesday morning.
o All new open issues raised during the working group meeting are to
be sent to the working group mailing list.
o The chair will include the new points, re-sort the list into
priority order, add a new category of ``local'' for issues, and
resubmit.
o A document showing the outcome of the discussions on the open items
will be prepared and sent to the list.
o A moderated list discussion will take on remaining open issues.
o Scheduling a Boston interim meeting will be investigated.
o The working group agreed to have a draft of the architecture RFC
prepared by the end of January, 1994, for final examination at the
March IETF.
Attendees
Nick Alfano alfano@mpr.ca
Susie Armstrong susie@mentat.com
Jim Barnes barnes@xylogics.com
Jim Beers Jim.Beers@cornell.edu
Nutan Behki nebhki@newbridge.com
Ram Bhide ram@nat.com
Jim Bound bound@zk3.dec.com
Monroe Bridges monroe@cup.hp.com
David Bridgham dab@epilogue.com
Steve Buchko stevebu@newbridge.com
Ross Callon rcallon@wellfleet.com
Ken Carlberg Carlberg@cseic.saic.com
Isidro Castineyra isidro@bbn.com
J. Noel Chiappa jnc@lcs.mit.edu
Matt Crawford crawdad@fncent.fnal.gov
Michael Davis mike@dss.com
Chuck de Sostoa chuckd@cup.hp.com
Avri Doria avri@locus.com
Havard Eidnes havard.eidnes@runit.sintef.no
William Fenner fenner@cmf.nrl.navy.mil
Eric Fleischman ericf@atc.boeing.com
Dan Frommer dan@isv.dec.com
Eugene Geer ewg@cc.bellcore.com
Atanu Ghosh atanu@cs.ucl.ac.uk
Robert Gilligan Bob.Gilligan@Eng.Sun.Com
Ramesh Govindan rxg@thumper.bellcore.com
Regina Hain rrosales@bbn.com
Dimitry Haskin dhaskin@wellfleet.com
Marc Hasson marc@mentat.com
Kathy Huber khuber@wellfleet.com
Phil Irey pirey@relay.nswc.navy.mil
David Johnson dbj@cs.cmu.edu
Matthew Jonson jonson@ddn.af.mil
Frank Kastenholz kasten@ftp.com
Hiroshi Kawazoe kawazoe@trl.ibm.co.jp
Lee Kilpatrick leekil@bbn.com
Stev Knowles stev@ftp.com
Sundar Kuttalingam sundark@wiltel.com
David Marlow dmarlow@relay.nswc.navy.mil
Jun Matsukata jm@eng.isas.ac.jp
Wayne McDilda wayne@dir.texas.gov
Greg Minshall minshall@wc.novell.com
Randy Miyazaki randy@lantron.com
Sath Nelakonda sath@lachman.com
Vijayaragavan Pandian vjp@proteon.com
Laura Pate pate@gateway.mitre.org
Michael Patton map@bbn.com
Eric Peterson elpeterson@eng.xyplex.com
Ram Ramanathan ramanath@bbn.com
Eddie Renoux elr0262@newsit2.mcdata.com
Robert Roden roden@roden.enet.dec.com
Shawn Routhier sar@epilogue.com
Michal Rozenthal michal@fibronics.co.il
Hal Sandick sandick@vnet.ibm.com
Martin Schulman schulman@smtp.sprint.com
Isil Sebuktekin isil@nevin.bellcore.com
Michael See mikesee@vnet.ibm.com
Frank Solensky solensky@ftp.com
Karen Sollins sollins@lcs.mit.edu
Tae Song tae@novell.com
Martha Steenstrup msteenst@bbn.com
John Stewart jstewart@cnri.reston.va.us
Vladimir Sukonnik sukonnik@process.com
Larry Tepper ltepper@compatible.com
Michael Thatcher thatcher@rahul.net
Dean Throop throop@dg-rtp.dg.com
Panos Tsigaridas Tsigaridas@fokus.gmd.de
Keisuke Uehara kei@cs.uec.ac.jp
Taehwan Weon weon@cosmos.kaist.ac.kr
Gerry White gerry@lancity.com
Walter Wimer walter.wimer@andrew.cmu.edu
Jane Wojcik jwojcik@bbn.com
John Wroclawski jtw@lcs.mit.edu
Weiping Zhao zhao@nacsis.ac.jp