[Nsi-wg] NML topology

[Jerry Sobieski]

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 at 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 at ogf.org
> http://www.ogf.org/mailman/listinfo/nsi-wg
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/nsi-wg/attachments/20100222/fe84ec94/attachment.html