New Internet Routing and Addressing Architecture BOF (NIMROD) Reported by J. Noel Chiappa and Isidro Castineyra/BBN The objective of this BOF is to design NIMROD: a hierarchical, map-based, routing architecture. NIMROD's stated purpose is to manage, in a scalable fashion, the trade-off between the amount of information about the network and the route quality. A rough draft architecture document was distributed to the group's mailing list in preparation for this meeting. The main purpose of the meeting was the review of the draft architecture document and the preparation of the work plan for the next meeting scheduled to take place at the next IETF. The group met on the Tuesday and Wednesday. On Tuesday, Isidro Castineyra presented the contents of the draft architecture document. The presentation covered the stated objectives of NIMROD, its main features and presented an overview of its mechanisms. The following are among the issues raised by the attendees: 1. Mobility The question that was raised was whether internetworks (nodes in NIMROD parlance) are mobile. In response to this it was said that in NIMROD nodes are mobile, but that NIMROD does not propose, at this time, a mechanism to support mobility. The draft architecture suggests ways in which NIMROD can support current approaches to mobility. 2. Node expansion In NIMROD, a node in a map can be expanded, substituting the node for its internal map. The question was raised of when should one look inside a node for more information. This question was added to the open issue list. 3. What is an endpoint The draft says that an endpoint represents a user of the network layer---a transport layer entity. The question was if this means that TCP/UDP are two endpoints. Chiappa answered that the an entity that has an end-to-end connection is an endpoint. It was noted that the concept of entity in the draft should be better defined. 4. EIDs and ELs The draft proposes two forms of endpoint identifier: the EID (endpoint identifier), and the enpoint labels. The first one is a relative short bit string, while the second one is more like a DNS name. The question was raised whether both of these forms are necessary. It was noted that though the ELs are necessary to perform a distributed look-up, they should not be part of the architecture proper. ELs can be considered a user-interface problem. 5. Multiple EIDs per endpoint The draft permits an endpoint to have more than one EID. The questions was raised whether this was necessary. It was pointed out that there is no apparent way to enforce a single EID per endpoint. 6. Arc's attributes The draft defines maps as consisting of arcs and nodes. The arcs are later defined to have attributes. The question is whether it is necessary for an arc to have attributes, as it is more common to have the attributes residing in nodes. It was noted that both models have the same power of representation and that the distinction was cosmetic, but it was agreed that the next version of the draft would try to conform to the more common representation. 7. Connectivity specifications dynamics Connectivity specifications describe the capabilities of a node. The question was raised whether these specifications are dynamic---that is, whether, for example, they indicate the current load of an element of the network. It was pointed out that dynamic specification might not scale. It was also pointed out that a specification could have different parts with different degrees of dynamism, and that each part could be distributed differently. 8. Border points Nodes have border points to which arcs attached. The question was raised of why are border points necessary. It was answered that border points are used to be able to separate the internal description of a node (its internal map) and its connection to the outside. 9. Bidirectional arcs The architecture uses both unidirectional and multipoint arcs. The question was raised of why were bidirectional arcs not included. It was pointed out that a bidirectional arc can be represented with either unidirectional or multipoint arcs. On Wednesday a set of issues was chosen for discussion by the group: o Arcs and nodes: different representations o When to look inside of a node o Dynamics of connectivity specifications o Work plan The group decided to continue refining the architecture document using the output of this meeting and discussions in the mailing list. Work on the protocols should also start in this period. Attendees Edward Allen eallen@wellfleet.com Michael Anello mike@xlnt.com Bashir Ashrafi bashraf@chipcom.com Ute Bormann ute@informatik.uni-bremen.de Michael Bradley bradley@mdd.comm.mot.com David Bridgham dab@epilogue.com Jerry Burchfield burchfiel@bbn.com Randy Bush randy@psg.com Ken Carlberg Carlberg@tieo.saic.com John Carlson johnc@cac.washington.edu Isidro Castineyra isidro@bbn.com Brett Chappell bchappe@relay.nswc.navy.mil Luo-Jen Chiang ljc@lsnhbu1.lincroftnj.ncr.com J. Noel Chiappa jnc@lcs.mit.edu Roger Cyganer cygander@telebit.comm Avri Doria avri@proteon.com Havard Eidnes havard.eidnes@runit.sintef.no Robert Elz kre@mulga.cs.mu.oz.au Jerome Freedman jfjr@mbunix.mitre.org Shoji Fukutomi fuku@furukawa.co.jp Vince Fuller vaf@barrnet.net Dragan Grebovich dragan@bnr.ca Joel Halpern jhalpern@newbridge.com Dimitry Haskin dhaskin@wellfleet.com Kenneth Hays hays@scri.fsu.edu Ian Heavens ian@spider.co.uk Roland Hedberg Roland.Hedberg@umdac.umu.se Jan-Olof Jemnemo Jan-Olof.Jemnemo@intg.telia.se Bent Jensen bent@cisco.com Frank Kastenholz kasten@ftp.com Sean Kennedy liam@nic.near.net Edwin King eek@atc.boeing.com Jim Knapik knapik@mdd.comm.mot.com John Krawczyk jkrawczy@wellfleet.com Robert Kummerfeld bob@cs.su.oz.au Joshua Littlefield josh@cayman.com Peter Lothberg roll@stupi.se Charles Lynn clynn@bbn.com Jamshid Mahdavi mahdavi@psc.edu Gerry Meyer gerry@spider.co.uk Kim Morla kmorla@pucp.edu.pe Kenneth Mueller ken@cmc.com Sandra Murphy murphy@tis.com Brad Parker brad@fcr.com Andrew Partan asp@uunet.uu.net Michael Patton map@bbn.com Maryann Perez perez@cmf.nrl.navy.mil James Philippou japhilippou@eng.xyplex.com Rex Pugh pugh@hprnd.rose.hp.com Murali Rajagopal murali@mitre.org Ram Ramanathan ramanath@bbn.com Robert Reschly reschly@brl.mil Duncan Rogerson d.rogerson@nosc.ja.net Joshua Seeger jseeger@bbn.com William Simpson bsimpson@morningstar.com Frank Solensky solensky@ftp.com Martha Steenstrup msteenst@bbn.com Bernhard Stockman boss@ebone.net Dan Tappan tappan@lightstream.com Jerry Toporek jt@mentat.com Jost Weinmiller jost@prz.tu-berlin.de Walter Wimer ww0n+@andrew.cmu.edu Shian-Tung Wong shian@dcsd.sj.nec.com Kwang Yao kwang@cup.hp.com Kisong Yoon kysoon@garam.kreonet.re.kr Lixia Zhang lixia@parc.xerox.com