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

[Chin Guok]

Hi Henrik,

Thanks for the response.

On Wed, Jun 4, 2014 at 1:04 AM, Henrik Thostrup Jensen <htj at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/nsi-wg/attachments/20140609/8bb0f6de/attachment.html>