Re: GGF-NMWG: "Hop" definition?

[Dan Gunter <dkgunter@lbl.gov>]

Yeah, I guess. This sort of goes against the definition of "layer", but 
I guess it's what we've been talking about. Really we're using shorthand 
for two connections, one between layers and one at the same layer from 
source to dest. Maybe we should leave layers out of this document for 
now. i.e.:

path := source, destination, hoplist?
hoplist := hop(1) hop(2) .. hop(n), n >= 1
hop := path

Alternatively we could make "layer" an attribute of an endpoint.

- Dan

p.s. anyone willing to bet on the next time this comes up? maybe we 
should get a little pool going ;)

Martin Stoufer wrote:
> To handle the edge condition when the path describes edge connectivity 
> between to diferent layers:
>
> path := soure, source_layer, destination, dest_layer, hop_list
>
>
> Dan Gunter wrote:
>
> > Hmm, good points.
> >
> > I think I'm getting convinced that the orig. def'n. was best. Just 
> > needed to be explained better.
> >
> > This is all we're talking about, right?
> >
> > path := source, destination, layer, hoplist?
> > hoplist := path(1) path(2) .. path(n), n >= 1
> >
> > the key point being that "hop" is really just  an alias for 
> > "sub-path", and has no attributes of its own. I guess the little 
> > grammar could make this explicit:
> >
> > path := source, destination, layer, hoplist?
> > hoplist := hop(1) hop(2) .. hop(n), n >= 1
> > hop := path
> >
> > I tried to repr. this in UML (attached) but I don't know how to draw 
> > an "alias", so I just showed hop inheriting from path.
> >
> > I agree that explicitly naming the leaves of the tree isn't too 
> > useful, since we can infer this information.
> >
> > - Dan
> >
> > p.s. we could simplify the terminology by simply calling it a 
> > "pathlist"  and using the first little grammar, but I think it's 
> > confusing to talk about "paths in a path".
> >
> > Bruce Lowekamp wrote:
> >
> > >     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
> > >
> > >
> > >