[Nsi-wg] Topology section
Radek Krzywania
radek.krzywania at man.poznan.pl
Thu May 17 05:46:23 EDT 2012
Hi,
In AutoBAHN the lookup service is rather to find STPs and neighbour agents, not the topology. The topology is built by receiving topology updates from neighbours. TimeToLive may be useful to have in NSI.
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: John MacAuley [mailto:john.macauley at surfnet.nl]
> Sent: Wednesday, May 16, 2012 5:07 PM
> To: radek.krzywania at man.poznan.pl
> Cc: 'Jeroen van der Ham'; 'NSI WG'
> Subject: Re: [Nsi-wg] Topology section
>
> Okay, so besides the Propagate/DoNotPropagate policy I was thinking about,
> I definitely think we need a TimeToLive so we can expire learned topology
> data.
>
> Is your lookup server looking up NSA or topology data?
>
> John.
>
> On 2012-05-16, at 10:55 AM, Radek Krzywania wrote:
>
> > Hi,
> > Lookup service is not centralized topology. It just point to NSA where you
> can start topology discovery. Lookup services can be also distributed. I agree
> that not all NSAs will peer, so you need to discover starting from neighbors,
> that's obvious. What I am reluctant to, is to have different agents and
> different logic to serve them - one can see more details of some domains
> than others. I would risk that we will get the same functionality if all NSA has
> the same knowledge (same reachability graph, as topology is nothing more at
> this moment, no internals are provided). You will probably need to send a
> message or two more, instead of knowing something on your neighbour by
> default. "Privileged/Trusted domains" is something I could consider in v8, just
> after having NSI operationally deployed in few global telecommunication
> companies :)
> >
> > 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: John MacAuley [mailto:john.macauley at surfnet.nl]
> >> Sent: Wednesday, May 16, 2012 4:16 PM
> >> To: radek.krzywania at man.poznan.pl
> >> Cc: 'Jeroen van der Ham'; 'NSI WG'
> >> Subject: Re: [Nsi-wg] Topology section
> >>
> >> Here is the assumption:
> >>
> >> a) All NSA will not have peering relationships, and therefore, not every
> NSA
> >> will be able to communicate with all other deployed NSA.
> >> b) A centralized topology solution is undesirable, and therefore, we need
> to
> >> distributed topology discovery.
> >> c) NSA agents will communicated with their provider NSA to discover
> >> network topology similar to the provider-to-provider discovery.
> >>
> >> The problem is not a hard one as it has been solved in many distributed
> >> routing solutions. The key is controlled learning using directly connected
> >> peer NSA.
> >>
> >> I thew the policy in there because we always throw the security issue into
> >> every message we define ;-)
> >>
> >> John
> >>
> >> On 2012-05-16, at 4:59 AM, Radek Krzywania wrote:
> >>
> >>> Hi,
> >>> Re 1 an 2) - shouldn't we just define a kind of lookup service for all NSI
> >> agents in clound (it can be done in distributed manner, like DNS structure
> eg,
> >> or whatever), so the "yellow pages" are always known? Also I am not sure
> if I
> >> understand how "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." Shouldn't we have exactly the same
> >> topology in all NSI agents, for sake of clarity and simplicity?
> >>>
> >>> Re 3) - that's what I don't like. I understand you don’t trust PIONIER and
> >> don't want to share the topology with me (the detailed one), no offence
> :)
> >> However making agent different and distributing different topology data
> to
> >> those whom you trust or no makes whole system tough to design and
> >> horrible to implement. Also if there are some trusted sites which gets
> more
> >> details, someone may compromise one of such sites and get information
> >> now allowed to see (and use it for a network attack e.g.). The trusted
> >> domains will also have more information about neighbours, but what to
> do
> >> with such info since domain are independent? Even if you know
> something
> >> about a neighbour, you can't make decisions instead of him. Despite of
> that
> >> the agent will behave differently for domain it trust and knows more, and
> for
> >> the rest. That changes the logic of an agent, and thus make it more
> complex.
> >> My feeling is that the benefit of giving more info to trusted domains is less
> >> than implementation problems it generates.
> >>>
> >>> 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 John MacAuley
> >>>> Sent: Wednesday, May 16, 2012 4:21 AM
> >>>> To: Jeroen van der Ham
> >>>> Cc: NSI WG
> >>>> Subject: Re: [Nsi-wg] Topology section
> >>>>
> >>>> 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.
> >>>>
> >>>> 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.
> >>>>
> >>>> 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
> >>>
> >
> >
More information about the nsi-wg
mailing list