[Nsi-wg] Topology section

[Radek Krzywania]

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.

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