Re: GGF-NMWG: "Hop" definition?

[Martin Stoufer <MCStoufer@lbl.gov>]

I think leaving layers out of the discussion would really limit 
ourselves in including specific knowledge of devices.
Having layer as an attirbute for the path allows us to make a clean 
lateral definition of each level without having to bridge the layer levels.

path := src, dst, hoplist, layer
hoplist := hop1, hop2, hop3...
hop :path

An exhaustive example:
path :=131.243.2.93, 131.243.64.2, hoplist, 3
hoplist := hop1, hop2, hop3
hop1 := path1
hop2 := path2
hop3 := path3

path1 :=131.243.2.93, 131.243.2.1, hoplist1, 3
hoplist1 := hopW, hopX
hopW := pathA
hopX := pathB

pathA := 131.243.2.93, 01-00-5E-0A-08-05, hoplistG, 2
hoplistG := {}

pathB := 01-00-5E-0A-08-05, 131.243.2.1, hoplistH, 2
hoplistH := {}

path2 := 131.243.2.1, 131.243.128.40, hoplistL, 3
hoplistL := hopY, hopZ
hopY := pathC
hopZ := pathD

pathC := 131.243.2.1, 01-00-5E-0A-07-11, hoplistJ, 2
hoplistJ := {}

pathD := 01-00-5E-0A-07-11, 131.243.128.40, hoplistK, 2
hoplistK := {}

path3 := 131.243.128.40, 131.243.64.2, hoplistL, 3
hoplistL:= hopM, hopN, hopP
hopM := pathE
hopN := pathF
hopP := pathG

pathE := 131.243.128.40, 00-02-7D-00-15-0F, hoplistM,2
hoplistM := {}

pathF := 00-02-7D-00-15-0F, 00-1A-6A-00-10-0A, hoplistN, 2
hoplistN := {}

pathG := 00-1A-6A-00-10-0A, 131.243.64.2, hoplistP, 2
holistP := {}

Dan Gunter wrote:

> 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
> > > >
> > > >
> > > >     

--
* Martin C. Stoufer              *
* DIDC/DSD/ITG                   *
* Lawrence Berkeley National Lab *
* MS 50B-2215 510-486-8662       *