The big issue with this in my mind is that adjacency as you define depends on a particular topology. If the topology is hierarchical or perhaps different for different providers, then what is adjacent for one may not be adjacent for another. I don't think we want to define topology in order to define what we mean by path terms, at least if we can avoid it. Does that make sense? John On Jan 27, 2010, at 8:36 PM, Jerry Sobieski wrote:
Hi John-
I am deleting some of the text to make the email a bit more readable...
John Vollbrecht wrote:
Jerry wrote: Not sure what you mean here... From Jeroen's comments, we might have two indicator bits: one that says "This hop is strict", and a second that says "This hop is required". The former means that this hop should be and is expected to be adjacent to the previous hop within the service transport layer.
So adjacent needs to be defined. Do you mean ordered, in the sense that other hops might be inserted but the order must be correct? This might be the case where a high level set of POs might be requested and these might later include lower (hierarchically) paths. Or is there a definition of adjacent that requires lowest level POs (and what is lowest)?
"Adjacent" means "directly next to each other." I will get pedantic now(:-): Two vertices in a graph are adjacent if they are connected by an edge. Within our network topology model, two Nodes, A and B, are adjacent if there exists a Link in the toplogy that has one endpoint on A and the other endpoint on B. A Link, which represents an immutable transparent transport conduit between two Nodes in the topology, by definition, establishes adjacency between those two nodes.
In the PO, a "strict" hop means simply that the path from hop(k) to hop(k+1) transits no (zero) intervening nodes. i.e. hop(k) and hop(k +1) should be or are expected to be adjacent in the topology. The latter hop, the k+1 hop in this example, would be flagged as "strict" in this case. In the PO, the order of the hops is important, but the strict/loose tagging only implies something about the possible presence or absence of intervening nodes.
To be clear about adjacency, if a Link in the topology is realized over lower layer infrastructure - even if that infrastructure itself is part of the topologyDB - the Link still constitutes adjacency since the underlying supporting infrastructure is transparent to the layer at which the Link is defined in the topology (i.e. the nodes it connects). This allows us, for example, to allocate a GFP/SDH circuit over an SDH cloud and define the resulting ethernet connection in the topology as an Ethernet Link forming an adjacency between two Ethernet Nodes.
Jerry