Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/93nov/nimrod-minutes-93nov.txt

Text File | 1994-02-17 | 14KB | 307 lines

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              [e-mail]
Susie Armstrong          [e-mail]
Jim Barnes               [e-mail]
Jim Beers                [e-mail]
Nutan Behki              [e-mail]
Ram Bhide                [e-mail]
Jim Bound                [e-mail]
Monroe Bridges           [e-mail]
David Bridgham           [e-mail]
Steve Buchko             [e-mail]
Ross Callon              [e-mail]
Ken Carlberg             [e-mail]
Isidro Castineyra        [e-mail]
J. Noel Chiappa          [e-mail]
Matt Crawford            [e-mail]
Michael Davis            [e-mail]
Chuck de Sostoa          [e-mail]
Avri Doria               [e-mail]
Havard Eidnes            [e-mail]
William Fenner           [e-mail]
Eric Fleischman          [e-mail]
Dan Frommer              [e-mail]
Eugene Geer              [e-mail]
Atanu Ghosh              [e-mail]
Robert Gilligan          [e-mail]
Ramesh Govindan          [e-mail]
Regina Hain              [e-mail]
Dimitry Haskin           [e-mail]
Marc Hasson              [e-mail]
Kathy Huber              [e-mail]
Phil Irey                [e-mail]
David Johnson            [e-mail]
Matthew Jonson           [e-mail]
Frank Kastenholz         [e-mail]
Hiroshi Kawazoe          [e-mail]
Lee Kilpatrick           [e-mail]
Stev Knowles             [e-mail]
Sundar Kuttalingam       [e-mail]
David Marlow             [e-mail]
Jun Matsukata            [e-mail]
Wayne McDilda            [e-mail]
Greg Minshall            [e-mail]
Randy Miyazaki           [e-mail]
Sath Nelakonda           [e-mail]
Vijayaragavan Pandian    [e-mail]
Laura Pate               [e-mail]
Michael Patton           [e-mail]
Eric Peterson            [e-mail]
Ram Ramanathan           [e-mail]
Eddie Renoux             [e-mail]
Robert Roden             [e-mail]
Shawn Routhier           [e-mail]
Michal Rozenthal         [e-mail]
Hal Sandick              [e-mail]
Martin Schulman          [e-mail]
Isil Sebuktekin          [e-mail]
Michael See              [e-mail]
Frank Solensky           [e-mail]
Karen Sollins            [e-mail]
Tae Song                 [e-mail]
Martha Steenstrup        [e-mail]
John Stewart             [e-mail]
Vladimir Sukonnik        [e-mail]
Larry Tepper             [e-mail]
Michael Thatcher         [e-mail]
Dean Throop              [e-mail]
Panos Tsigaridas         [e-mail]
Keisuke Uehara           [e-mail]
Taehwan Weon             [e-mail]
Gerry White              [e-mail]
Walter Wimer             [e-mail]
Jane Wojcik              [e-mail]
John Wroclawski          [e-mail]
Weiping Zhao             [e-mail]