Hi Chin
Thanks for reading.Well you have to start the parsing somewhere :-). But yeah, usually one
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
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.I agree with this, and I think this is already the case (except for not
- 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
allowing ':' in the local part).
But I don't see the question/point here.The schema John suggested had a lot of rules for naming everything. But
- John came up with something in Oxford, maybe we could revisit that
the reason for why everything had to be named explicitely was missing. We
are only adding rules for what we need.
Sure. But the topology scheme presented here doesn't really care about it.
- 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
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.I am not sure what you mean with topology here.
- Is the reachability information part of the topology
But it is NOT part of the NML topology (in fact, the scheme doesn't require NML at all).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.
, or can it leverage the "peers with"
information in the NSA Description Document?
Not really. This requires either vectors, or some form of link-state routing.
- 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)
Technically one could list a network multiple times in the reachability information, but I cannot really see how that would improve anything.Aggregators without data-plane are largely useless. However...
- If the control and data plane have to be congurent, how does this affect Aggregators (that do not
have a dataplane)
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.
- For example if the ESnet uPA only had relationships with the ESnet AG and I2 AG:
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.
But essentially: You only pull discovery and reachability information from your (aggregation) peers. That is the _ONLY_ information that gets pulled in this model.
- 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,
It will work, assuming:
- how will the above affect the path finding in your scheme
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.