[Nsi-wg] [NSI imp] Reachability-based topology suggestion

[Henrik Thostrup Jensen]

Hi. I forgot to answer this one (until now at least).

On Mon, 9 Jun 2014, Chin Guok wrote:

>> Peers with is about control-plane. We are advertisting data-plane 
>> reachability. Also peersWith cannot really be extended. It is pretty 
>> much just a list in XML.
> 
> From what I understand, what you are proposing is to extended the NSA Description Document to include your
> reachability information.  Or are you thinking that this should go into the NSA Topology Document?

Right now we put this into the NSA description document. But it could 
easily be put in a seperate document.

Just to make it clear: The solution does not depend on NML.


> Aggregators without data-plane are largely useless. However...
> 
> I would have to disagree here.  I could foresee project or application specific Aggregators being setup to
> enforce policy enforcement and path finding.  For example, an LHCONE Aggregator to enforce LHC user policy
> (e.g. ATLAS, CMS, etc), as well as path finding.  With the current peer-to-peer trust model, having such
> Aggregators also make it convenient (e.g. knowing a request is from LHC based on the Aggregator request).

Sure, okay. The proposed schema will work fine with this though (problems 
occur when you have transit networks without aggregators).

>> I am not entirely sure who "you" is in the next questions.
> 
> The "you" refer to other NSAs.
>
>                 - what information will you pull from the ESnet uPA,
>                 - what information will you pull from the ESnet AG,
>                 - what information will you pull from the Internet2 AG,

The control-plane peering is not a full mesh. It is in fact highly 
selective, like regular network peering.

ESnet UPA: Most likely only the ESNet AG will talk to this.
ESNet AG: The NSAs that peers with the ESnet AG will pull reachability 
information from it.
Internet2 AG: Same as ESnet AG.

>> But essentially: You only pull discovery and reachability information 
>> from your (aggregation) peers. That is the _ONLY_ information that gets 
>> pulled in this model. 

Still holds. I hope this make it clear.


>>> - how will the above affect the path finding in your scheme
>> 
>> It will work, assuming:
>> 
>> The UPA-only networks are only at the edges (meaning that all the 
>> transit networks have an aggregator)
>> 
>> What won't really work is being able to use the I2 AG to connect to the 
>> ESnet network. One will have to contact the aggregator responsible for 
>> the network (the ESnet AG, assuming we do the networkId proxying) to 
>> setup a path through the ESnet network.
> 
> One of the fundamental decisions of the NSI-WG is to support generic tree workflows.  This implies that the
> control and data plane peerings can be distinct.  Are there enhancements to your scheme that you could
> propose to maintain the NSI-WG's support for tree workflows?

Possible, yes (proxy each link segment). In a sane way, no.

> If not, then we need to figure out how we can reconcile this with the 
> NSI framework.

Sure. But it works in the current form.


Slight rant mode: ON

This is not a super-generic solutions that can encompass all use-cases and 
setups, and it is not intended to be. NML tries to be that, but it 
hopefully also clear now that making the big complicated model of the 
network is not useful in itself, it it doesn't reflect how it can be used. 
It will produce a very complicated model, with complicated path finders 
and complex control-plane trees. It is a not a system that I want to 
implement, debug and support.

This is a farly simple solution that intentionally doesn't answer some 
questions. It is based on a routing algorithm invented in the sixties. It 
delegates routing decisions to the NSAs along the path, which encapsulates 
most of the policy issues, by letting the domain figure out the path. In 
order to this it relies on underspecified STPs and especially the ability 
to re-write labels/vlans. However we have been able to work around issues 
when it turned out a domain could not support these two (you just prune 
the path in a clever way - the function for doing this is 13 lines of 
code).


     Best regards, Henrik

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