John Vollbrecht wrote:
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

Hey John-  
Two points: 
a)  The adjacency definition still works even for hierarchical topologies.
b) you cannot describe a "path" without some model of the topology (or graph) over which that path exists.

If two nodes are connected by a link, then they are adjacent.  By Definition.   This comes from our definition of a Link as being an edge in the topology graph and representing a "connection" between two nodes.   How you define the nodes or what topology they may hide/summarize is immaterial. And whether that link is predicated over some underlying infrastructure is also immateral.

In practice, a "hierarchical" node simply hides its internal topology and only expresses itself as a single virtual node (or a set of virtual nodes nodes with some abstracted topology.)    From a topological perspective, those virtual nodes are still "nodes" and still have "links" to other nodes.  And so, that virtual node is still adjacent to the other nodes at the ends of those links.  That single virtual node must still be consulted in order to reserve a path though it.   (Of course the NSA (or NRM) responsible for that virtual node must still consult the internal nodes that comprise the opaque internal topology - but that is invisible to the external agents.)  

Even in our multi-layer networks, adjacency is still defined by the existence of a link between two nodes.   The only precondition on this is that the link between those two nodes imposes no requirements on tours (pathfinding) through the topology.   In reality, the topology must often express more detail than simply physical hardware boxes - for instance, a Ciena CoreDirector would be expressed as several nodes in the topology - perhaps summarized into a single virtual node, but the pathfinding process must still consider, at some level, the functional elements/resources that exist inside the physical box (virtual node) that are necessary for establishing a connection through the node.  Indeed, we may need to define totally virtual topological elements that represent  protocol conversions and adaptations if path finding is to work end to end...but this can still be done within a very simple graph oriented, possibly hierarchical, topology model.

So, for NSI's part, we *do* need to make some assertions about how the NSAs relate to topology.  This will require a topology model.  IMO this should be a very simple high evel model, but one that nevertheless is very generalized and can scale well.  Details of the topology database or the syntax or structure of a topology description or distribution processes are not our role...but the basic topology environment in which we expect the NSA to operate is within scope.

If PathFinding is a concern for NSI, then we must necessarilly have some topological model that we subscribe to.   Topology and PathFInding are intricately linked - you can not speak of one without some implications for the other.   For instance, we can not even begin to discuss Tree vs Chain models without some assumptions about topology.   What are those assumptions?  We must stipulate a knowledge of and/or responsibility for some portion of the topology if we expect the NSA to do anything of substance.   And if you have anything less that one global Master Control NSA, then you introduce issues about how two or more NSA would interact to effect a global service - which again implies something about topology.   So NSI Architecture is fundamentally dependent upon some basic topology model - we should define and describe that model and then describe how the NSI protocol(s) operate in the context of that model.

Not to put too fine a point on this, even just specifying End Points for a connection request stipulates some notion of topology.  What is an "End Point" or a "Service Termination Point"?   Even just deciding if an STP is in our domain or a foreign domain implies some concept of what the topology looks like and how it functions...  Making any intelligent decision about breaking a connection request into component segments requires some knowledge of topology.  So what topological properties are necessary to allow the NSA to function in this manner?   We really can't talk about Paths or PathFinding without some associated topology model.

So in closing, we should perhaps have a section in the NSI Architecture doc that clearly and succinctly describes the contextual topology model over which the NSI is defined and operates.   This needn't be a long section, and should be fairly high level, but I think explicitly describing the topo model allows us to describe how NSAs and NRM and STPs relate to the transport plane we purport to manage.  Thoughts?

Jerry
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