[Nsi-wg] Input for GLIF meeting

Henrik Thostrup Jensen htj at nordu.net
Mon Mar 17 11:10:15 EDT 2014


Hi

So I have already voiced my concerns about the discovery service, and I 
think it is a step in the wrong direction. But just to re-hash:

- The requirements and design seems to come from a single organization and not from the NSI group
- Has a completely different security model than the NSI Connection Service.
- Essentially a custom system to distribute files. That in itself seems a bit weird.
- Significant complexity to achieve something relatively simple
- Ignores lessons learned during AutoGOLE demos.
   - I.e., changes are frequent, but rarely important for path finding.
    - Adding a new termination port will flood through the network despite having no influence on path finding.
    - An aggregator should not need to know every little detail of the network to find a path.

SURFnet and NORDUnet have created a fairly simple extension to announce 
reachability, and GEANT/AutoBAHN is adopting this as well (and have 
contribute to it as well). We did not suggest it for standardization, 
because it did not originate from within the NSI group. It is, IMHO, 
significantly simpler to implement, as it doesn't need to build up a 
complete topology model of all networks and only distribute a minimal 
amount of information. It essentially eliminates the need for pushing 
documents around and replaces the complex path finder from NML with a 
simple vector look up. It is based on principles from BGP, which I think 
is pretty sane, as it is a proven internetworking protocol. We have some 
known issues with it, but no real showstoppers as such.

/Henrik


On Sun, 16 Mar 2014, Freek Dijkstra wrote:

> Hi all,
>
> Unfortunately, I will not be able to attend the NSI and GLIF meeting
> coming week. Here is our (SURFsara) stand with regards to the current
> service discovery and topology distribution proposals.
>
> Summarizing John's proposal:
> - recursively flood discovery services info to neighbours
> - recursively flood topology files to neighbours
>
> We think that this is a major improvement over the current bootstrap
> document on Github used by AutoGOLE.
>
> We don't think it's perfect.
>
> Our main critique is:
> - there is no aggregation of topology
> - it requires full topology knowledge
>
> Our minor critique is:
> - scalability: long distribution path. Our preference
>  would be that topology docs would be publicly available at each
>  domain. (though we are aware that some organizations are reluctant
>  to publish this information).
> - security: poor PKI. (none to speak of?)
> - flexibility: no distinction between identifiers and addresses
>
> We like to see a better infrastructure in the future, but will not
> pursue that for now (at least not before fall 2014). The reason is that
> we think it is better to gain more experience with
> (1) PKI and security aspects of non-central topology distribution;
> (2) experience how NSI interacts with other technologies, like OpenFlow
> (3) understanding the trade-offs of hierarchical addresses, and the
> distinction between identifiers and addresses.
>
> Concluding, we support John's proposal for discovery services and
> topology distribution as a solution that is good with the current scale
> and requirements of the NSI community, and hope to work with you on a
> better solution for the future.
>
> I wish you a fruitful meeting!
>
> Freek
>
> -- 
> Freek Dijkstra
> | Group Leader & Network Expert | Infrastructure Services | SURFsara |
> | Science Park 140 | 1098 XG Amsterdam | +31 6 4484 7459 |
> | Freek.Dijkstra at surfsara.nl | www.surfsara.nl |
>
> Available on Mon | Tue | Wed | Thu |
> _______________________________________________
> nsi-wg mailing list
> nsi-wg at ogf.org
> https://www.ogf.org/mailman/listinfo/nsi-wg
>


     Best regards, Henrik

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



More information about the nsi-wg mailing list