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