Hi,
I've had an exchange of emails with Jerry off the list, to see if I
understood him correctly. I'm replying back to the list, because we had
some interesting ideas.
On 25/01/2010 18:46, Jerry Sobieski wrote:
> Jeroen van der Ham wrote:
>> Let me try to summarise what you just said, so that I understand. If
>> that's the case, perhaps we can send this to the list, and I can
>> respond to it ;)
>>
>> - You assume that hops in Path objects will always be checked before
>> they are actually implemented.
> I had assumed that would be the case. However, the "check" is a function
> of how the agent uses the PO. The provisioning process will need to
> (should) always do some level of check as it configures the switches, or
> it must trust that the PO is accurate (is it trustworthy?)
Crossreferencing to some comments John brought up: I think there should
be a Connection object, of which the Path object is a part.
The Connection object should be checked, and once that's done, the Path
object should be implemented.
At some point there has to be a translation between what is in the Path
object and what actually will be implemented in the data plane. That is
where the check should be, and not in each of the hops.
>> - You propose to implement the strict hop by saying that everything is
>> a loose hop unless specified otherwise.
> Yes. We should consider this more - I only came up with it this
> morning:-) Would this be sufficient? There is a possibility that we
> could also define STPs that represent a group or domain. Specifying such
> a hop would say "transit any more specific STP in this region/domain".
> You could define a [group] STP that represents a whole transit network
> and then declare that STP (hop) to be "required" (must transit) in the PO.
I thjink there should be a flag for each hope defining whether it's
strict or loose. I would not use a "default unless specified otherwise"
in this case.
> "adjacent" means: For a node A and a node B, there exists a single link
> that directly connects A and B with no intervening nodes.
I think this is a pretty sensible definition, perhaps only with the
addition "... no intervening nodes which must be provisioned/configured."
> In my world (:-), I contend we build [user] "connections" over a
> topology of "nodes" and "links". At any layer, the topology is the lower
> layer infrastructure over which we construct the high layer connection.
> I differentiate between a "connection" and a "link". The latter being an
> object in the topology database, the former being an object that is
> constructed over the topology for a higher layer entity. A "connection"
> is just a user conduit until that connection is inserted into the
> topology database and becomes a link that Path Finding can use to
> allocate other user connections.
Yes.
> There are two basic operations to build a connection: concatenation, and
> encapsulation. /Concatenation /is the process of linking two connections
> such that the egress PDU of one is fed directly into the ingress PDU of
> another at some switching point. Concatenation can really only be done
> when the egress and ingress framing are identical. If not identical,
> then an "adaptation" function must be mapped into the connection to
> convert the egress framing/PDU to the ingress framing/PDU. (Think of
> what GFP does). /Encapsulation /is the process of moving the entire
> transport frame (PDU *and* framing information) transparently from the
> ingress point of a connection to the egress point. Encapsulation is
> often called tunneling.
I think that we use the term Adaptation for Encapsulation, but otherwise
I agree.
Jeroen.
