[Nsi-wg] Topology section

Thu May 31 15:31:27 EDT 2012

On 5/29/12 10:26 AM, Radek Krzywania wrote:
> Hi,
> I think Jeroen was thinking on OSPF mechanisms, not the OSPF itself (at least I did). So use the algorithms and behaviour but adopted to our needs. We can use Web Services for that and introduce security. It's up to us. We don’t need to use Quagga or whatever other routing software for that purpose.
Fair enough...   But it still comes down to "what do we want it to 
do?"   We have on several occasions looked at using OSPF routing 
protocol (and GMPLS variants) only to decide that it would not work well 
in inter-domain environment for a number of architectural reasons never 
mind the shift from XML based data descriptions to TLVs.

I do agree we should consider the aspects of OSPF style flooding.  But 
even so it is a non-trivial implementation.

May I suggest the following topology exchange process:

1) Bootstrap:  Lets assume that each NSA is initialized with a local 
topology.   This initial topology is likely a manually specified "local" 
topology (e.g. the RDF/OWL we use now.)   Assume this topology is 
announced via a public "topology URL".  Further, assert that the 
topology description contains SDPs that reference the topology URLs of 
the adjacent networks.

2) Given this initial info, an agent/NSA would "pull" information from 
each URL referenced in the SDPs, iteratively fetching each new topology 
URL as they are encountered.   The topology information from each remote 
topology URL is merged with the local topology to create a comprehensive 
"world view".

This is simple, but poses the N^2 scaling problem: all NSAs contact all 
other NSAs.   This is addressed as follows:

3) As each NSA merges another topology file into their world view 
topology, they post that merged world view to the topology URL for the 
local domain.   (Thus the local advertized topology includes both local 
topology and other topology the NSA now knows about the world.)

4) An NSA only explores (fetches) "hanging" SDPs.  Hanging SDPs have not 
had their topology URL fetched and merged into the world view.

5) Finally, each NSA periodically refreshes its world view. _/But/_ 
because the topology URLs are providing _/world view/_ topology (not 
just local topology), an NSA only needs to  fetch the topology from 
immediate neighbor(s) to get updated world views.  Thus addressing the 
N^2 problem and updates propagate to all topology agents

I think this process is exceedingly simple - it essentially only 
requires a periodic HTTP GET of topology from one (or a few) URLs.   An 
NSA can still directly walk the entire global topology itself if it 
desires, but it is not necessary - it need only fetch topology from its 
immediate neighbors.   Updates will flood (propagate) out as a result of 
periodic refresh.   Thus, topology will converge with time.

A nice feature of this proposed process is that it allows for NSAs to 
act as a topology servers.   An agent/NSA could walk the topology from 
any starting domain and construct a world view.   And this same server 
could continuously monitor these domains for updates.  Clients or other 
NSAs can fetch the world view from the topology server first.    Such a 
server effectively reduces the diameter of the propagation domain thus 
allowing the topology to converge quicker.   The process allows multiple 
[redundant] servers to exist.

One concern I had with this process is the update propagation mechanism 
- it is based on periodic pull rather than an event driven push.   A 
push is only useful if the time between update events is large - 
propagating updates as they occur rather than waiting for some periodic 
schedule.       If, however, updates are happening frequently, then a 
periodic pull is just as effective as a push, maybe more so if it allows 
updates to be batched.  Given the complexity we have seen due to 
firwalls and NATs, I think the complexity of a push mechanism is more 
sophisticated tahn we need for now - and we have our hands full getting 
CS v2.0 code working as it is. _So, for now, I believe a periodic pull 
will be fine and so simple as to be trivial._

Further, a pull allows an NSA to selectively pull updates only from 
particular key other networks, or from just particular other servers.  
I.e. a hierarchichal server tree could be constructed (ala DNS.)

One aspect that still needs some discussion is the "merge" process.   A 
sophisticated validation processes will be challenging (shelve this for 
now).   I also think an intelligent update of a topology by construct 
elements will be non-trivial (shelve this for now).   I suggest we keep 
it simple: a merge simply uses the latest known version of a domain's 
topology.  We just wholesale replace a domain's topology text with the 
most current version of the text file in its entirety.   Not a surgical 
strike, but should work for near future.    We simply need a topology 
construct that timestamps the topology file.   We could also define 
expiration date element as well - thus telling other NSAs how often they 
should refresh.

Thoughts?
J

> Best regards
> Radek
>
> ________________________________________________________________________
> Radoslaw Krzywania                      Network Research and Development
>                                             Poznan Supercomputing and
> radek.krzywania at man.poznan.pl                   Networking Center
> +48 61 850 25 26                             http://www.man.poznan.pl
> ________________________________________________________________________
>
>
>> -----Original Message-----
>> From: nsi-wg-bounces at ogf.org [mailto:nsi-wg-bounces at ogf.org] On Behalf
>> Of Jerry Sobieski
>> Sent: Tuesday, May 29, 2012 3:45 PM
>> To: Jeroen van der Ham
>> Cc: NSI WG
>> Subject: Re: [Nsi-wg] Topology section
>>
>> This bootstrapping process is exactly what I described:
>> How do you learn what the world looks like topologically when the NSA starts
>> up?
>> And how do you do this in a global distributed system of autonomous
>> administrative domains and millions of untrusted [topology] consumers?
>>
>> the problem with OSPF is that it indeed floods link state announements.  But
>> this is a scaling problem in a large multidomain environments and can take a
>> significant time for such protocols to converge..if ever they ever do.   And
>> even with OSPF not all toplogy is expressed...there are summarized LSA and
>> areas...etc.   all these hide topology in an attempt to make it scale better.
>>
>> and ospf is non trivial... It does not use IP.   It has no authorization security
>> either.   And it is not exactly a web service:-).    it has multiple timers just to
>> tell when a neighbor is present and how/when to flood link state
>> announcements.  yet no way to determine if a LSA is to be trusted.   And you
>> still need to discover or configure the local topology...ospf can only do this in
>> very limited cases...even in gmpls this was done by LMP...yet another
>> protocol.  further, the topology technologies/layering are defined in the
>> protocol, rather than a separate topology standard...thus you need to
>> change the protocol in order to enhance the topology descriptions.  And the
>> open source implementations (quaga, zebra, ...) are not small packages easily
>> modified...
>>
>> These are some of the reasons why you never see OSPF in interdomain use.
>> And rarely see it even in multilayer use.   And why many networks have
>> migrated to ISIS for intradomain ip routing.   I think these are also good
>> opportunities for us to consider how we want to manage topology
>> distribution in the futre rather than just blindly adopting what was defined In
>> the past for ip networks.
>>
>> So it seems to me we ought to discuss and understand the fundamental
>> process that we want to see occur before we decide what the proper
>> mechanism is to accomplish that process.
>>
>> Perhaps we should review the NSI requirements for topology distribution...I
>> dont think we ever actually came up with one that was vetted by the
>> group...I made some bullets that were presented at OGF in Lyon, but those
>> were just talking points and i think were oriented more to topology
>> representation rathe rthan distribution and discovery processes.
>>
>> thoughts?
>> jerry
>>
>>
>>
>>
>>
>>
>> Sent from my iPad3g
>>
>> On May 29, 2012, at 7:14 AM, Jeroen van der Ham<vdham at uva.nl>  wrote:
>>
>>> Hi,
>>>
>>> On 16 May 2012, at 19:46, Jerry Sobieski wrote:
>>>> The key is that we are exchanging world views - or updates to world
>> views, not simply local topologies.
>>>> try this protocol sequence:
>>>> [...]
>>>
>>> Instead of thinking up all kinds of scenarios, and exchange mechanisms,
>> could we just please restrain this to referring to other implementations?
>>> Most of what I've seen so far is all supported by OSPF. It has limited
>> peering, abstraction, and simple update mechanisms. I propose we use that
>> same mechanism, if there is anything that is wrong with that, please write
>> what needs to be changed, and why.
>>> The only thing we don't have at our disposal is multicast, but I think we can
>> solve that by using a peer-to-peer overlay network. That requires some
>> bootstrapping, but you need to coordinate with your neighbor(s) already, so
>> that can become part of that exchange too.
>>> Jeroen.
>>>
>> _______________________________________________
>> 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/20120531/8390129a/attachment.html>