[Nsi-wg] UvA/TUD topology exchange proposal

[Ralph Koning]

Hi Henrik,

Thanks for your comments; it seems that some things are left unclear and
let me elaborate on this. Naturally, we will improve the text in the
next document version. As both Miroslav and me will be present at the
Nordunet conference we can further elaborate and clarify the model.

#0  The document is a proposal for a topology exchange
    - It is not a requirements document (upcoming/promised by Chin/John)
    - It is not a comparison of routing techniques
    - Chapter 2 introduces three main approaches to routing / topology
exchange but doesn't describe specific implementations

#1  Topology exchange != routing
    We distinguish between 'topology exchange' and 'path calculation'.

#2  We propose an infrastructure for any type of topology documents
    - NML is used as an example and we think it is a good example
    - We use NML to exchange inter-domain topology information
    - Topology documents that are exchanged could represent both
link-state and distance vector information.
    - NML might not be the right format to model link-state and distance
vector(s), and NML may need to be extended to support both of them.

#3  Path finding is not centralized
    - Every domain provider can run its own path finder which is seen as
a TC
    - The path finding implementation we present is distance-vector but
we do not mandate it.

#4  Every provider can choose the level of topology information to
present to the consumer
    - NRENs don't seem to be always 'open' in practice
    - Policies can be applied based on consumer
    - Policies can be applied on the path the consumer intends to take
so this allows for peering agreements
    - This is done by adding/removing links/nodes/ports from the
topology presented to the consumer

#5 We support different levels of trust
    - In order to do key distribution you need to trust the TI
    - When using other methods for this its up to the TC and TP to
decide what levels of trust to accept
    - The TP can provide a minimal topology when trust is low
    - The TP can provide a custom topology for given consumer based on
key verification

#6 The only centralized component in our proposal is the TI
    - TI is just a collection of URLs
    - It can be omitted if you know the TP URLs
    - It can notify you of updates and aid in finding TPs
    - You can distribute the TI

#7 We say 'optimal path finding given the provided topologies'
    - let's define it as the solution that maximizes the given objective
function based on the information (e.g. topologies, policies, etc.)
known to path computation element
    - If the exchanged topologies are not complete this solution may not
be globally optimal (in a strict sense).
    - we are aware that the problem is hard, and has a large state space
    - we present a solution to exclude certain paths, or specify the
paths to be included
    - we assume that scheduling may become very important problem in the
future of resource reservation within the networks
    - you can always choose to aggregate to make the problem easier (and
choose your own algorithm for this) but you can not easily ask for more
specific information when you are dictated by just aggregated information
    - sharing more topology information may provide a environment where
research to new innovative routing algorithms can be done

Cheers,
Ralph

On 02-09-14 16:11, Henrik Thostrup Jensen wrote:
> Hi
> 
> Okay, deep breath.
> 
> On Tue, 19 Aug 2014, Ralph Koning wrote:
> 
>> Attached to this mail is the document describing this topology exchange,
>> and a small discussion on how we can apply it to the NSI work. Feel free
>> to comment and ask questions.
> 
> Section 1:
> 
> * 1 optimal path finding on the provided topologies
> 
> Could you please define optimal.
> 
> (the finer point here is that network is shared infrastructure, which
> makes this a very complicated thing to do).
> 
> 
> Section 2:
> 
> After finishing the document, I realized I had read it wrong. I thought
> section 2 and 3 where discussions about topology (or as it is commonly
> called "routing") models, but I realized later that this is just an
> alternative way of distributing NML. However you don't actually mention
> NML until section 9 (yay, a detective story), which makes the document
> incredibly difficult to read.
> 
> Anyway, what I had hoped to find in section 2 was something like
> link-state vs. distance vectoring, information push vs. pull, discussion
> of transit, peerings, and customer connectivity and link/transit AUPs.
> Further the control and data plane symmetry (or lack of it) would be
> good to have.
> 
> It would also have been nice to see some discussion of what is
> considered the only two successfull inter-networking protocols: BGP and
> SS7. Especially why they are successfull.
> 
> 
> Section 2.1:
> 
> The more time I have spend with NSI topology, the more convinced I am
> that it is just routing, and that most of time stuff we are doing is
> actually 30-40 years old.
> 
> Anyway, could you please list the number of successfull centralized
> routing protocols? Have you considered why there are none? It is not
> just because networks don't want to rely on a single service, but also
> because you cannot cram the policies of a network into a single service
> (there are technical, economical, political and legal reasons for this)
> 
> 
>>> The topology database can also have a dedicated path finder,
> 
> No. It really cannot. We will never succeed in cramming in the policies
> and state of networks into a single point of decision. You cannot tell
> NORDUnet how to deliver data into on of their customer networks. This is
> an agreement between NORDUnet and the customer. Similarly, NORDUnet
> cannot tell their customers how to get the data to the university /
> research institution. You only get to hand over the data to NORDUnet at
> place.
> 
> The sooner we kill of the notion of centralized path finders, the sooner
> we can start making something that can actually be used.
> 
> 
> Section 2.2:
> 
>>> Hence, frequent topology exchanges could be expected between domain
>>> controllers for path finding purposes.
> 
> Why?
> 
> 
> Section 2.3:
> 
>>> However, full disclosure of internal do- main information may pose a
>>> threat to the domain due to possibilities of attack, sabo- tage, or
>>> competitive intelligence between do- mains.
> 
> This is rather speculative. Sure commercial networks are like, but most
> NRENs list their topology openly.
> 
>>> The advantage of providing a minimized internal do- main view is that
>>> less information needs to be processed during path finding, and for
>>> safety concerns. However, insufficient topology information may lead
>>> to suboptimal path or even failure to compute paths.
> 
> Do you know how much information is exchanged via BGP?
> 
> Optimal is still not defined.
> 
> 
> Section 2.4
> 
> If you mean the GNS approach, say the GNS approach.
> 
>>> This discloses even less topology information.
> 
> Because more is better? (scandinavian culture does not assert this btw.)
> 
>>> The routing is done locally, per domain, based on the information of
>>> itself and its direct neighbours leading to a locally optimal route
> 
> Like BGP? :-) (ok, BGP has AS paths, but it is also common to override
> MEDs, so we end up with the same thing).
> 
>>> It is not possible to provide a different view to the requester domain
> 
> WHAT!? Split horizon and reverse poisoning are 40 year old techniques,
> was used in RIP, and covered in all textbooks on routing.
> 
>>> malicious domains can easily provide false reachability information
>>> and break global path finding.
> 
> BGP has the same problem. It also has a solution.
> 
> 
> Section 3:
> 
>>> Since we believe sharing topology information provides more
>>> flexibility over sharing reachability information, we propose a
>>> hybrid approach to exchange topologies:
> 
> When you dismiss something due flaws also found in BGP it is something
> difficult to take it serious. Also the two models do no exclude eath
> other (BGP does MEDs for IPs, but still do AS-Paths for adjecency).
> 
> I fail to see how the TI is more useful than a list of URLs. Sorry. The
> notion of foreign domains is slighly interesting though.
> 
> The trust model is not listed in the section, but it looks like all-to-all.
> 
> Again, I don't want to depend on your central service.
> 
> The neighbour list isn't entirely clear on the data vs control plane
> peering issue.
> 
> 
> Section 7.6.
> 
> Again. You cannot do path computation centrally. Won't fly. Sorry.
> 
> 
> Section 8:
> 
> How to deal with:
> 
> Complex transit policies
> 
> AUP for links. E.g., some project have private links (they have a lot of
> traffic). These might be listed, but you can only use them if you have
> certain credentials. Some links have AUPs that are under NDAs.
> 
> 
> Section 9:
> 
> NML isn't mentioned before this section, but the entire document is
> based on the NML model.
> 
> Section 9.1:
> 
>>> Key distribution is problematic, since many developments within NSI
>>> did not focus too much on the security aspects giving no facil- ity
>>> to distribute information with end-to-end security.
> 
> And forcing all-to-all trust is much better?
> 
> -- 
> 
> Sorry for being an ass about this. But I am tired of seeing technology
> first solutions (and NML and its derivatives is certainly so).
> 
> Policies are much more important for finding paths than technology. BGP
> and SS7 is successfull because they allow policies to be expressed. For
> BGP, announcing different reachability to different networks, and with
> different priorities for where to deliver traffic, and the ability to
> override the latter locally. SS7 is more complicated (because telco),
> but interestingly enough it is circuit based.
> 
> The basic model needs to allow networks to figure out they want to
> connect. Having user or centrally driven path finding is a pipe dream.
> 
> 
>     Best regards, Henrik
> 
>  Henrik Thostrup Jensen <htj at nordu.net>
>  Software Developer, NORDUnet


-- 
Ralph Koning
SNE research group, University of Amsterdam
Tel: +31 20 525 7928 | http://staff.science.uva.nl/~ralph