Good idea Guy...I have a couple of posts...here is the first:.

I suggest we focus on which NSI service request parameters or semantics have topological significance and what those are. For instance:

1. NSI:    A Connection request must, at a minimum, specify the ingress point and the egress point. The Connection request may also specify intermediate transit points for the connection. The semantics of loose hop request is PO={A,B,C}, is equivalent to Connection A>B concatenated with Connection B>C.

Topo Requirement:    Each of these "point" identifiers must uniquely determine and map to a location in the transport topology. What is the NSI definition of a "point"used in this context? It seems to correspond to our STP discussion...so we need to decide what a point in the Path Object really refers to topologically.

2. NSI: A Provider NSA is responsible for decomposing the Connection request (into piecewise segments defined by the PO) and forwarding sub-requests to other service agents as it deems appropriate or necessary, and insuring the returned sub-segments can be assembled into a single fully satisfied Connection and returning that Connection result to the Requesting NSA.

Requirement: Define how the NSA handles Connection requests.
    a) The NSA decomposes the request into a set of sub-segments as defined by the PO.
    b) The NSA must forward each sub-request to/towards the NSA that owns the ingress STP of the sub-request, [Here is where topology comes into play - how do we know where to send a request? Must map STP to NSA owner or have reachability in the topology..]
    c) If an NSA receives a request whose ingress STP is in the local Domain, the NSA invokes the PathFinder to reserve a Path towards the next STP [NSA must be able to recognize STPs in its local domain]
    d) Upon successful reservation, the returned POs of the sub-requests are merged into a single PO and returned to the originating Requester.

3. NSI: Upon successfull reservation, a Path Object is returned to the user describing the resulting Path. This PO will contain the STPs stipulated by the originating request, and will contain either a) STPs of the as-built Connection, or b) named Path Object(s) for opaque as-built information.

Requirement:   Path Object definition.   Including opaque Named POs that are only revealed to authorized requesters. A PO must contain STPs, but must also include a Named PO - which must carry some authorization policy. How do these Named POs get resolved? what do they look like, how are names constructed, etc.

The above notion that we forward requests from one NSA to another based upon some ownership means we must define that ownership concept. Therein lies the notions of grouping resources into Networks, and a single NSA King for each Network kingdom :-) If STPs are part of that group, what are they and how do we summarize such info?

However, we do not have a trust relationship with all NSAs - its scaling problem.   We must assume that we will connect directly with some neighbor Networks, and have a trusted relationship with them. But we will not (cannot) directly connect to every network, and therefore some such "far-away" networks will not recognize and trust our local NSA. For these latter cases, the only way we will know of that far-away domain is if one of our direct neighbors offers to act as transit to to Far-Away domain by announcing all or some of Far-Away's topology.   In this case, we see far-away, but we must rely on our neighbor to forward any requests to Far-Away.   If our NSA encounters an STP that lives in Far-Away, and our peering table has no trust with Far-Away, then we must send our request to our neighbor who acts as intermediary. (In point of fact, our neighbor acts no differently than it would for any other request - it sees the Far-Away STP and forwards the request likewise.)

This may generate another topology requirement- that of reachability. I.e. how do we describe the set of points (STPs) reachable within (or through) a given domain?   We have to recognize that our reachable end systems or STPs will almost immediately be counted in the thousands.   We probably need some sort of hierarchichal naming scheme.

thoughts?
Jerry

Guy Roberts wrote:

I suggest the following 10 requirements as a starter:

Requirement 1: The model should be able to describe a grouping of network resources that are owned and controlled by a single provider or NSA. (I will call this a NETWORK for the moment)

Requirement 2: The model should be able to describe a grouping of NETWORKs. (e.g. a federation of providers with shared policy)
Requirement 3: The model should be able to describe resources (ports/points) in a NETWORK that are available for connecting to other NETWORKs.  (I will call this a network connection point NCP for the moment)
Requirement 4: These NPs should be able to be performed at the end of a link that is internal to the domain as well as to ports on a device.  (in my opinion the NCP on a link requirement needs a use-case)
Requirement 5: The model should be able to describe an arbitrary number of layers of logical ports within a NCP.
Requirement 6: The model should be able to describe connectivity between NETWORKs. (I will call this inter network connection (INCs) for the moment) 
Requirement 7: The model should be able to describe groups of INCs.
Requirement 8: The resources that make up INCs should have ownership by a clearly identifiable provider. (i.e. resources without NSA ownership are not allowed).  (note: Does this also include the patch cord between providers?)
Requirement 9: The model should allow policy to be assigned to INCs, even where the INC is wholly or partly made up of passive resources.
Requirement 10: The model should be able to fully describe a circuit (i.e. NSI service) that transits the topology. 

Any thoughts on these and other requirements would be helpful.

Guy


-----Original Message-----
From: Freek Dijkstra [mailto:Freek.Dijkstra@sara.nl] 
Sent: 22 February 2010 13:52
To: NSI WG
Cc: Guy Roberts; Jeroen van der Ham; John Vollbrecht
Subject: Re: [Nsi-wg] NML topology

Can I summarize this discussion as follows?

Requirement: It should be possible to assign a policy to an
(interdomain) link.

Of course, I can think of a solution (e.g. make that link part of a
topology, like John's second picture, assign the topology to a
networkdomain, and assign a policy to that networkdomain). However, this
seems out of scope. I think the best way forward is to describe this and
other requirements and forward them to the NML and ask the NML folks to
come up with a solution for the requirement. I also wholeheartedly
invite all NSI group members to become a "NML folk" too by joining the
NML list!

Regards,
Freek
_______________________________________________
nsi-wg mailing list
nsi-wg@ogf.org
http://www.ogf.org/mailman/listinfo/nsi-wg