[Nsi-wg] Topology section
Jerry Sobieski
jerry at nordu.net
Wed May 16 08:31:04 EDT 2012
HI John-
See comments/thoughts in line-
On 5/15/12 10:20 PM, John MacAuley wrote:
> In addition to the topology data representation we will also need to define a topology discover mechanism that fits into the existing NSI framework. We will need to address the following discover requirements:
>
> 1. Support for controlled discovery. An NSA will attempt to build a view of network topology through communicating with peer NSA. Controlled discovery allows an NSA to make decisions on how it will discover the full network topology. For example, NSA 1 may ask NSA 2 for all the networks it has discovered, but not the detailed topology. NSA 1 will compare the list of returned networks to the list it has already discovered, then make a decision on the individual network topology to retrieve from NSA 2.
With the current NSI topology, all we really have is the adjacencies.
The SDPs. So walking the topology outward will only return
adjacencies. This *will* provide the 1st level approximation for path
finding. "Detailed topology" begs the question of what details do you
want / not want? How do you know which details you need?
How does this all scale? If an NSA begins by asking direct peers for
their peers, and then asks those NSAs for their peers (less NSAs already
visited), etc. If you do not walk the whole network, you will not
discover all adjacencies. So, at least once at initialization, an NSA
needs to walk the whole topology. And we still need to flood updates
somehow - but the importance of updates is dependent on the type of
information you want updated (e.g. link state (slow) vs link utilization
(fast)). Also, this walking method might be optimized if you also asked
for reachability as well as direct peers as this will tell you if a
transit NSA is "of interest" to a particular request...but I hope you
don't plan to walk the entire topology for every request...that will
definately be a scaling problem. Also, this mechanism means that NSAs
would in general need to be responsive to all requests for topology
regardless of the origin... Not every network will see this as a
function they will want to perform...
If the number of NSAs gets large, walking the entire topo could find
ourselves handling peer requests for quite a few NSAs that we do not
have direct peerings with... Considering that any user NSA could be
walking the topology as they do path finding this walking method to
discover topology could be quite onerous on core NSAs.
An alternative is to ask direct peers only but for their /entire/
worldview. This restricts topology exchange to only direct peers.
However, Since we are getting the entire worldview, we don't actually
need to fetch it from a direct peer. Indeed, we could fetch it from
*any* single NSA willing to talk to us. I.e. in this scenario we could
have one or more NSAs that act solely as topology servers, these could
be a few strategically placed, or could be many self selected, but the
exchange process is *much* reduced - or at least concentrated on these
topo servers. In this scenario an NSA is manually configured with one
or more topology server NSAs. The local NSA simply queries one or more
of those servers on startup to get a worldview. This scenario also
supports a reasonably simple update mechanism... When an NSA requests a
worldview, it could also indicates if it wants a push of updates from
server to client, or if it will pull updates when needed. It the
client can also act as a server to the "server" - i.e. the server can
ask the client to push updates or indicate it will periodically pull
updates to the server. Same protocol both ways. There are still some
nuances to be addressed, but these are protcol issues, not structural
scaling issues.
While walking the tree seems simple, it doesn't scale so well in my
estimation. The server style (IMO) can be fairly simply implemented to
start (i.e. a single topo server NSA) and can expand easily as
necessary. Indeed, every NSA could be a server to only specific other
clients...a sort of self organizing distribution tree. I think this
will scale much better.
In any case, we do need some [simple] protocol for managing the topology
exchange. I.e. we need to define the topo representation format, some
sort of timestamp to age the topo information, a mechanism for
indicating push/pull preference for updates, what ypes of updates we
want, and for a push process a means to accept the push, and for pull a
means to request an update rather than full dump, etc.
While I think we *should* do this, I don't think this is strictly
necessary for V2.0 - Topology distribution is separate from the CS v2.0
features. Perhaps this is where we introduce an NSI TS (Topo Service).
We can continue to use a single common worldview file to feed the
NSI-CS path finding for now, and make the auto discovery and dynamic
updating of that worldview topoDB a separate issue.
> 2. We will need a subscription mechanism for an NSA to register with a peer NSA for topology updates on networks of interest. If NSA 1 discovers NSA 3 through discovery with NSA 2, NSA 1 could register with NSA 2 for any topology updates on NSA 3.
>
> 3. Policy will need to be associated with communicated topology. We need additional investigation into this, but I would like to see the ability to associate a propagation policy with my topology. For example, I may allow UvA and NORDUnet to see my detailed topology, but they are not allowed to propagate, or advertise it to any other peer NSA. This will allow me to control distribution, and yes, I will need to trust the peer NSA not to propagate it.
There are two issues here: 1) transitive announcements, and 2) coherency.
The first is an ancient problem: How do I tell you a secret and make
sure you do not tell someone else? I simply need to trust you. But
there is no real way for me to insure that the information does not get
distributed accidentally or otherwise. If the information I give you is
sensititve, what is the risk if it is announced wider? For our
purposes, unless we have a particular urgent use case, I would push this
out for later worry. For now we adopt a simple "all topo announcements
are public" rubric.
The 2nd issue says: If I learn topology from two different sources, and
they are not the same...which should I use? one? or the other? both?
How do we merge them into a single valid topoDB? I think this is
entirely tractable, but it would be nice, at least for now, we did not
have to deal with incoherent topology announcements. So I suggest we
do a simple thing now - a single topology server with a single topology
worldview.
A related issue is timing of updates- Even if topology updates are
monolithic when they converge, there will be a period of time when
different NSAs will have different worldviews. While this may lead to
some failed reservations, I don't think this exposes any flaw in the
protocol. The protocol will continue to work properly.
My thoughts only...
Jerry
>
> John.
>
> On 2012-05-11, at 3:19 AM, Jeroen van der Ham wrote:
>
>> Hi all,
>>
>> I've made a start on the topology section for the NSI v2.0 document. It's not finished yet, but at least it contains some start. Unfortunately, I'll be on holiday next week, so I won't be able to further write on this. If others feel they can contribute, please do so.
>>
>> The document is available for reading at:
>> https://docs.google.com/document/d/1HIo7uQl7DbTe_y-cnPOrqDkspoRBaTKVVrrldURurTk/edit
>>
>> Guy should be able to give out edit access rights too.
>>
>> Jeroen.
>> _______________________________________________
>> nsi-wg mailing list
>> nsi-wg at ogf.org
>> https://www.ogf.org/mailman/listinfo/nsi-wg
> _______________________________________________
> nsi-wg mailing list
> nsi-wg at ogf.org
> https://www.ogf.org/mailman/listinfo/nsi-wg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/nsi-wg/attachments/20120516/db891594/attachment-0001.html>
More information about the nsi-wg
mailing list