Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/94jul/eid-minutes-94jul.txt

Text File | 1994-11-01 | 6KB | 153 lines

Endpoint Identifier BOF (EID)

Reported by Robert Elz/University of Melbourne

A BOF was held at the Toronto IETF to consider the concept of endpoint
identifiers.  The meeting was nominally chaired by Robert Elz.  Frank
Solensky took notes for the minutes and Dave Clark also supplied his
notes of the meeting.

Before the BOF, a proposed agenda was sent to the Big-Internet list
(subscription requests should be sent to
[e-mail], which formed the starting point of
the meeting.  The agenda was:


   o Administrative tedium
   o EIDs - definition
   o Terminology - what name should these things have
   o Uses - certain, likely and possible
   o Structure
      -  including or excluding manufacturer provided tags (e.g., MAC
         addresses)
      -  structure for directory lookups
   o Allocation (including autoconfiguration)
   o Is a working group required
   o Draft a charter if so
   o Are EIDs useful?  Do we need them?


This agenda fell by the wayside quite quickly after the administrivia
was dealt with.

The meeting opened with Noel Chiappa, as the inventor of the concept,
giving his definition of an EID, which amounted to the name of an
endpoint---being something that can form one end of a connection, which
might be a host, but need not be.  The term ``fate sharing region''
applies.

Discussion on exactly what this meant followed, without making any
significant progress.

It was suggested that a better approach might be to construct a list of
the uses to which the attendees believed that EIDs might be put, with
the aim that from this list the essence of what is required might be
distilled.  The list constructed contained:


   o Realign existing end-to-end context and transport connections
   o Maintain connections during fail-over or instability
   o Identify a ``security context,'' even when no connection present
   o ``Index'' into database
   o Transition abstraction
   o Provider-independent identifier of host interface
   o Re-acquire path (underlying connection) after service disruption
   o Use, e.g., within a MIB, for referring to an end-point
   o Labelling a connection (independent of movement)
   o Cluster aliasing
   o Better software fastpath
   o Avoid semantic overload
   o Accounting
   o Transport (and above) completely independent of network layer
   o Selectors shorter (and still globally unique)


It should be pointed out that this list does not represent the opinions
of any particular individual, nor of the meeting itself, but was merely
compiled from suggestions from the floor.

Discussion of these points, as they were added, continued for some time.
Many points in the list were felt to be merely special cases of other
points, others were felt to simply be inappropriate.

As this discussion was also getting nowhere particularly useful, a third
approach was tried.  This comprised building a list of the
distinguishing attributes that may apply to EIDs, and asking particular
people to indicate which of the attributes applied to their model of
EIDs.

The attributes were


  1. Are EIDs short (generally perceived as no longer than about 64
     bits)?

  2. Are EIDs binary (as opposed to printable text)?

  3. Are EIDs globally unique?

  4. Do EIDs exist at the network level?

  5. Do EIDs exist in the transport layer?

  6. Are EIDs used to identify transport connections?

  7. Are EIDs used as a key into any kind of database?

  8. Do EIDs have any internal (administrative) structure?  It was
     assumed that EIDs have no topological or geographical meaning.

  9. Are EIDs present in every packet ?


Without attribution, the models suggested were:

                  model  1  2  3  4   5  6  7  8  9

                  A      ?  ?  Y  Y?  N  Y  N  N? ?
                  B      ?  Y  Y  Y?  N  Y  Y  Y  ?
                  C      N  N  Y  N   ?  Y  Y  Y  N
                  D      Y  Y  Y  N   Y  Y  Y  Y  Y?
                  E      Y  Y  Y  Y   Y  Y  Y  Y  Y
                  F      Y  Y  Y  Y   N  Y  Y  Y? Y
                  G      Y  Y  N  Y   N  Y  N  N  ?
                  H1     Y  Y  Y  N   Y  ?  Y  Y  N
                  H2     N  Y  Y  N   Y  ?  N  N  N
                  J      Y  Y  Y? N   Y  Y  Y  Y  Y
                  K      Y  Y  Y  Y   N  Y  Y  Y  Y


For comparison, treating IPv4 addresses as EIDs, and noting that they
have topological significance, the model for IPv4 was constructed as:


                  IPv4   Y  Y  Y  Y   N  Y  Y  Y  Y


In the above, ``Y'' indicates a ``yes'' answer to the corresponding
question, ``N'' indicates ``no,'' ``?''  one of ``don't know'' or
``uncertain,'' or ``either way would work,'' or ``sometimes,'' or
similar.  ``Y?'' indicates ``probably yes,'' or ``something like that,''
``N?'' probably no.  Respondent H believed that two different forms of
EIDs were required, with different attributes, the two sets listed as H1
and H2.

This list was constructed comparatively quickly, as no discussion of the
models was entertained.  Instead their proponents, or some of them, will
write a short submission supporting their view of what an EID should be
like, and why, and submit it to the Big-Internet mailing list for public
review.  Some of those may become Internet-Drafts.

It was decided that a new mailing list was not warranted immediately,
and that [e-mail] will continue to be used, however a
specific list may be established at some later time.

The submissions on this topic to the list will be considered, and from
those, if it seems necessary and useful, a charter for a working group
will be created and submitted.  It was noted however that IPv6 (or IP6,
or IPng as desired) is currently planned to be to Proposed Standard
stage by the time of the next IETF, if EIDs are to play any part in IPv6
the work needs to be done well before then.