RE: GGF-NMWG: "Hop" definition?

[Bruce Lowekamp <lowekamp@CS.WM.EDU>]

	I think the hard issue here is selecting a model that captures the 
specific knowledge when available.  Personally, I think that a definition 
with specific types for layer 3 and layer 2 hops would cover a lot of 
cases, but it isn't general, and it doesn't allow all systems to use their 
current working representation.

	Remember that the goal here was to develop a system that could express the 
representation used by other

	For example, there are at least two systems (one of which being Remos, 
which I helped develop) that routinely express paths as hops of both layer 
2 and layer 3 devices.  If we restrict end-to-end paths to being composed 
of layer 3 hops only, we lose the ability to represent the output of those 
systems, at least without some work converting.  Actually, if we restrict 
the hops composing a path to be all at a particular layer---any layer---we 
have a problem representing those.

	So the essential objection I have to the proposed new approach is that it 
involves proposing a "right" way to represent topology, rather than 
maximizing the flexibility.  I think that runs counter to the goal of the 
document.  Now, I think that it should be possible to take the proposed 
flexible representation and represent the "right" way of modeling topology 
without any more information loss than strictly necessary.

	So I make the following assertions:

- our representation should be as flexible as possible
- the description in the text needs to be clarified to reflect out 
intentions, and the most common uses

- paths are composed of hops.  we require at least one subtype of path: 
host-to-host path
- the key issue we are discussing is "what is a hop?"
- it needs to be clear how to express the layer at which the path is defined

options:
- maintain Fig 2 as it is now.  Add an additional attribute to "hop" such 
that it is still a path with the added notation of the layer at which it is 
a hop.
- go back to the recursive definition where path has an element "hoplist" 
which is an ordered set of paths.  Personally I like this, but others 
strongly dislike this.  Possibly need to add more attributes.
- maintain Fig 2 as it is now, but add an additional attribute to "hoplist" 
which allows a layer to be specified (or possibly multiple layers).  So if 
a system is reporting only layer 3 hops, it sets that flag.  If it's 
reporting both layer 2 and layer 3, it either sets no flags or sets both 
flags.
- I'm not sure that a real representation would have this confusion.  Since 
Fig 2 suggests that nodes can be "router" or "switch", isn't it always 
clear what layer a path/hop is at?  Possibly we should add an attribute to 
virtual node to deal with routing/bridging hosts and VPN issues, but I 
think it's already possible to determine the layer at which any path is 
reported at.

I am strongly prejudiced against any approach which does not have "hops" 
being paths.  As I see it, the only options to implement this are to have 
no actual data type of "hop", with hoplist just containing elements of type 
path, or of having hop inherit from path.  If we decide that hop needs to 
have additional information such as the layer, then I think there should be 
an additional type.  Otherwise, maybe not.

I don't see a benefit to using terms like "indivisible."  I mean, if it's 
important, certainly it could be added as a parameter.  Certainly it should 
be explained as the goal behind the concept.  But I'm not sure what is 
gained by enforcing "all hops must be indivisible at their reported layer." 
If nothing else, few tools can say they are sure of that.    I'm open to 
suggestions, however.

Bruce