Hi Henrik, Thanks for the response. On Wed, Jun 4, 2014 at 1:04 AM, Henrik Thostrup Jensen <htj@nordu.net> wrote:

Hi Chin

Thanks for reading.

On Tue, 3 Jun 2014, Chin Guok wrote:

Thanks for writing this up. I had a few comment and questions about your

...

proposal. Let me know if you need clarification on any of them.

- I think adding structure to the STP so that it can be parse would be useful - it would be ideal if we could devise a schema that resulted in the same networkID and localID irrespective of the parsing direction (e.g. L->R or L<-R), however I am doubtful

Well you have to start the parsing somewhere :-). But yeah, usually one parses from the left, the scheme presented parses from the right, but it was the simplest we could do considering that people will often have more than just domain+year in the network part.

- considering that the networkID has to be unique, but the localID does

...

not, we should be rigid about the structure of the networkID, but flexible on the localID

I agree with this, and I think this is already the case (except for not allowing ':' in the local part).

But I don't see the question/point here.

- John came up with something in Oxford, maybe we could revisit that

...

The schema John suggested had a lot of rules for naming everything. But the reason for why everything had to be named explicitely was missing. We are only adding rules for what we need.

I think we are all in sync on what we want to achieve, it's just working out the details. I would say that I do like your comment of being about to use just the networkID portion for the ERO, I think it is a very useful construct.

- Bi-directional is convenient and practical, but I can see the need for

...

unidirectional topology modelling if there is a need to support non-congruent or asymmetric circuits

Sure. But the topology scheme presented here doesn't really care about it. In fact, it works perfectly fine with both. But the point of the model is that it cares more about the networks and their adjcency than their internal details and structure.

I just don't like the way NML makes bidirectional way more complicated than it needs to be. I cannot see any reason why unidirectional and bidirectional constructs cannot both be first-order constructs.

- Is the reachability information part of the topology

...

I am not sure what you mean with topology here.

But it is NOT part of the NML topology (in fact, the scheme doesn't require NML at all).

, or can it leverage the "peers with"

...

information in the NSA Description Document?

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?

- With cost factoring, if a network peers with another network at

...

multiple points, is there a way to model multiple costs in the reachability info (or is it only a single cost between two networks)

Not really. This requires either vectors, or some form of link-state routing.

Technically one could list a network multiple times in the reachability information, but I cannot really see how that would improve anything.

- If the control and data plane have to be congurent, how does this

...

affect Aggregators (that do not have a dataplane)

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).

- For example if the ESnet uPA only had relationships with the ESnet

...

AG and I2 AG:

In that case I would just have the ESnet AG present the ESnet networkId as its own. Should work fine. The I2 AG would probably just announce reachability.

The model does not do well with the disjunct control and data plane, and the cross setup in this case. However this is fundamental to the chaining model.

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,

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

- 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? If not, then we need to figure out how we can reconcile this with the NSI framework. Thanks again! - Chin

Best regards, Henrik

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

-- Chin Guok NOC: (510) 486-7600 Network Engineer (800) 333-7638 ESnet Network Engineering Group (AS293) Lawrence Berkeley National Laboratory