[Nsi-wg] NML topology
Jerry Sobieski
jerry at nordu.net
Tue Feb 23 07:47:22 CST 2010
Yup - I will be there - wouldn't miss it for the world:-)
J
Guy Roberts wrote:
>
> Jerry,
>
>
>
> I like what you have done here -- the point is to first state clearly
> what the NSI 'Connection Service' needs to do, and then to derive the
> topology requirements from these service functions.
>
>
>
> Will you be able to make tomorrow's call? I would like to make this
> make this a topic for discussion.
>
>
>
> Guy
>
>
>
>
>
>
>
>
>
>
>
> *From:* Jerry Sobieski [mailto:jerry at nordu.net]
> *Sent:* 23 February 2010 04:46
> *To:* Guy Roberts
> *Cc:* Freek Dijkstra; NSI WG
> *Subject:* Re: [Nsi-wg] NML topology
>
>
>
> 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 <mailto: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/20100223/87cb917f/attachment-0001.html
More information about the nsi-wg
mailing list