[Nsi-wg] [NSI imp] Some perspective on the discovery service and topology

[Diederik Vandevenne]

Hi Henrik,

 > It is not explained why it is better to have a flooding mechanism to
 distribute documents instead of distributing only the link to discovery
 services and subscribing directly from the source. This is despite the latter
 being significantly simpler, while providing the exact same functionality
 and with the same amount of messages send in the system.

Good remark. This is also something I am thinking of. I even think you do not need to distribute (flood) the link of the location of the discovery service. You could use a lookup service similar to DNS to find out the address. This was one of the solutions mentioned during the last OGF meeting in Oxford.

> The only way to got more effient distribution is to aggregate information
   somehow, but that is - AFAICT - not done.

At this moment I do not see clearly how this is done in the model proposed by John. You should have some kind of hierarchical addressing schema to do this. However, an aggregator has still the potential to summarize / aggregate information. Maybe John can explain.

> To transit into the second major issue: Distributing information like this
combined with NML means one can acquire network topology descriptions. However
in our current system (and way of thinking) we only export one topology per
network. The discovery service system further enhances this view of the world
by distributing the single description further. However network don't really
work like that. They have different policies towards different other networks.
...
> In our current model, describing topology doesn't tell me how I can use it.
This makes path finding rather difficult. The reasons for different policies to
different networks is usally political and economical. Right now we have a
model that deals mainly with technological aspects of networking, but we cannot
ignore the other aspects of it.

I agree with you that we may not ignore the aspect of policy. Sadly I do not have any solution yet. The question is if you want to distribute different topologies or if you want to distribute the policies in some other way? 


Kind regards,

Diederik




SURFsara heeft een nieuw algemeen telefoonnummer: 020 800 1300

| Diederik Vandevenne | Infrastructure Services  | SURFsara |
| Science Park 140 | 1098 XG | Amsterdam |
| T 06 4798 8196 | diederik.vandevenne at surfsara.nl | www.surfsara.nl |

________________________________________
From: Henrik Thostrup Jensen [htj at nordu.net]
Sent: Monday, March 03, 2014 1:03 PM
To: NSI Working Group; NSI implementation group
Subject: [NSI imp] Some perspective on the discovery service and topology

Hi

As promised, here is my concerns over the proposed discovery service, a long
with concers over our current topology model / way of thinking about topology.

Discovery service:

- Essentially a mechanism to publish (and subscribe to) documents, with the
   documents emitted through a flooding mechanism.
   - Documents are signed by their creater.

- It is not explained why it is better to have a flooding mechanism to
   distribute documents instead of distributing only the link to discovery
   services and subscribing directly from the source. This is despite the latter
   being significantly simpler, while providing the exact same functionality
   and with the same amount of messages send in the system.

- The flooding mechanism distributes the exact number of messages / documents
   by pushing them around. It is not more efficient, it just adds more with
   lifetime, expiration, etc.

- The only way to got more effient distribution is to aggregate information
   somehow, but that is - AFAICT - not done.

- Also, I have no idea what it is this thing is trying to do/solve.

Signing and distributing the documents like this, still doesn't solve the issue
of transitive trust. Say a setup like this:

A - B - C

A trusts B. B trusts C. A does NOT trust C. A getting information from C,
signed by C, does actually do anything, because cannot verify it. What is weird
is that if A requests a connection service from A to C, through B, it HAS to
trust B, and implicately C, to provide the service. This issue comes up
practially everywhere when building networks. You have to trust your provider
to deliver your data, and trust your peers to not only announce the right
reachability information, but also to deliver data to end users.

I'll just repeat it...

Signing documents doesn't solve the issue of transitive trust.


To transit into the second major issue: Distributing information like this
combined with NML means one can acquire network topology descriptions. However
in our current system (and way of thinking) we only export one topology per
network. The discovery service system further enhances this view of the world
by distributing the single description further. However network don't really
work like that. They have different policies towards different other networks.

I'll use the nordunet network to show how these policies work. You can see an
overview of it here:
http://stats.nordu.net/stat-q/load-map/ndn-map,,traffic,peak

We do several things with our network:
- Provide generic connectivity to our few owners/customers (the NRENs of the
   five nordic countries)
- Peer with a number of networks, mainly at NETNOD, AMSIX, LINX, DECIX, along
   with several Equinix sites and CPS in the US.
- We also provide US transit to PIONIER and SURFnet (which we have private
   links to)
- We also have links to GEANT, these are used for transit towards europeans
   NRENs
- We also have services towards RBnet and RUNNET, but I am actually not sure
   what we provide to them.

As you can imagine this is a bit of mish-mash with a lot of policies for who
can use the network in what manner. Here are some things we DO NOT allow:

- SURFnet & PIONIER to send data to GEANT through us
- Allow transit between GEANT and our peerings

Both of these lists can be made very long. Most of this is handled with BGP
communities (I assume). Essentially NORDUnet is a transit network (I guess all
network are that in some sense), but how you can use our infrastructure depends
on the agreement you have with us.

I can fairly easily create a single topology of our network, but that topology
doesn't tell anyone how they can use it. For instance our links over the
Atlantic are rather heavily loaded, but additional capacity over the Atlantic
costs a significant amount of money (the ANA-100 circuit is attempt of trying
to reduce costs over the Atlantic for NRENs), so we are in general not going to
allow connections over those link except for special arrangements.

Our initial NSI peering are likely to be DeIC, GEANT, SURFnet, and possibly
SUNET (Onsala). What I'd like to announce wrt. reachability is something like
this:

DeIC:    SURFnet, GEANT, SUNET
SUNET:   SURFNET, GEANT, DeIC
SURFnet: DeiC, SUNET
GEANT:   DeIC, SUNET

Furthermore we have a potential user through DeIC that may want to reach SLAC
which means transatlantic link, so we might announce a different reachability
towards DeIC. Our agreement with SURFnet and GEANT might also differ in how
other networks can reach us through them, and what they can announce other
networks.

But this is not really possible currently. I can start to serve different
topologies depending on request IP, but that is a hack. So essentially, the
problem boils down to this:

In our current model, describing topology doesn't tell me how I can use it.

This makes path finding rather difficult. The reasons for different policies to
different networks is usally political and economical. Right now we have a
model that deals mainly with technological aspects of networking, but we cannot
ignore the other aspects of it.

Furthermore, with networks the size/layout of NORDUnet (and GEANT, ESNet, and
more) it becomes rather difficult to perform effecient path finding when having opaque
networks. I've been toying with idea of being able to split network into
sub-parts (nordunet would probably be nordic, eu, and us), somewhat inspired by
some ideas from Jerry, but I haven't gotten around to do something concrete,
and I am not entirely sure how useful it is.

Anyway, this is just the tip of the iceberg. In short: The discovery service
doesn't solve any problem AFAICT. In fact, it just reinforces some dogmas which
I think are wrong.


     Best regards, Henrik

  Henrik Thostrup Jensen <htj at nordu.net>
  Software Developer, NORDUnet