SENSE RM model generation review

[xi-yang]

Current version: demo1.ttl.txt

First batch of viewed problems.

• [ ] 1. The object should be Resource instead of Literal / string for both these attributes of a BidirectionalPort.

<urn:ogf:network:es.net:2013::atla-cr5:10_1_10:+>
        <http://schemas.ogf.org/nml/2013/03/base#belongsTo>
                "urn:ogf:network:es.net:2013:" ;
        <http://schemas.ogf.org/nml/2013/03/base#encoding>
                "http://schemas.ogf.org/nml/2012/10/ethernet" ;

• [ ] 2. Similarly ...#vlan is also a Resource (defined by NML) instead liberal.

  <urn:ogf:network:es.net:2013::atla-cr5:10_1_10:+:vlan>
      <http://schemas.ogf.org/nml/2013/03/base#labeltype>
              "http://schemas.ogf.org/nml/2012/10/ethernet#vlan" ;

• [ ] 3. ServiceDefintion is missing for switchingService

<urn:ogf:network:es.net:2013::l2switching>
        missing mrs:hasServiceDefinition

Then a mrs:hasServiceDefinition resource definition. Refer to the OESSDriver code. 

• [ ] 4. Check if mrs:providesSubnet related statements have been coded if the mocking topology does not have a l2 services already provided.

• [ ] 5. A few attributes missing under top Topology.

  
  <urn:ogf:network:es.net:2013:>
  
      missing nml:name
      missing nml:version
      missing nml:exitsDuring -> Lifetime

Then a LifeTime resource definition.

[R-Jimenez]

Github won't let me upload so I'll continue to provide snippets over Slack.

1. Added. NML definition already had a #vlan resource, so I just had to fill in a base ethernet one.
2. Added.
3. Added. I again copied over some definitions and called it a day, but not 100% on what the definition actually entails.
4. Can you clarify this one? I see a providesSubnet property in my example TTL, seems to point to a bunch of resources of a few types.
5. Added. I'm unsure about the lifetime definition so please let me know what start and end represent or calculate from. Actually unsure about all three but the others are easy to swap in and out as you want.

[xi-yang]

4. I do not see the providesSubnet property in the ttl. Does the mocked data included provisioned reservations?

5. There is no defined norm for this. Currently John's code has it for around 6 hours while Alex's code for 2 days. I think 6 hours is good enough.

   • The current model has the root topology nml:name as es.net, which is better than the URI.
   • You can use the current Time (could be same as start of lifetime) value of nml:version.

[R-Jimenez]

4. Sorry, not in this model but the one I've been using as a base. Linked on Slack.
5. Sounds good, I'll do 6 hours then.
   • I'll look for where I might grab that name from. Currently I'm just hardcoding the urn:ogf:network:es.net:2013 but I'll need to see about properly pulling that from the deployment, I suppose?
   • Time as in millisecond instant or datetime string?

[xi-yang]

4. Yes. It points to all the reservations (a.k.a. provisioned L2 connections).
5. • I am not sure where Alex get es.net. Maybe he hard coded. How does NSI bridge make that? Otherwise it can be from a config file.
     • second will do. The current OSCARS RM has something like 2021-08-23T17:41:34+00:00 but NSI RM has milliseconds. Again this is undefined / unused yet.

[R-Jimenez]

4. Interesting. I'll take a look at the ResvService to see what I can pull, as the OSCARS NML code doesn't have anything obviously matching this. Is this something that the python code did correctly and I can review?
5. OSCARS has a properties file that spring loads in, so that's resolved.

[R-Jimenez]

ResvService didn't give me anything of use, and similarly while the ConnController may be able to provide the connections you're talking about, drilling down to the connection repository gives me an empty DB, so it's either not it or the mock does not reflect it.

Does the python RM correctly build the provideSubnet properties? I may be able to at least confirm the trace of this if so.

[xi-yang]

Both John and Alex's codes have provideSubnet in modeling. You can refer to them. Not surprised that the OSCARS mock does not provide the reservations data.

We may still stick to the original (Alex's) design that we only model the SwitchingSubnets for the VLANs SENSE has provisioned, as we may not want to expose the many ESnet production L2 services.

So now we need to decide where to get the ground truth for "our own" services. We may want to filter them out based on specific pattern in the service name and/or description fields. We also need to test out the performance for these data ops.

[R-Jimenez]

Great, I'll go ahead and pull out their logic and see if I can maybe make a mock for the dev.

I'll refer to Alex's code for the filtering logic then as well.

[xi-yang]

I doubt such logic exists. The current oscars-nrm may rely on local db to cache information from push requests, which I would avoid.

I'll refer to Alex's code for the filtering logic then as well.

[R-Jimenez]

Ah, I understand now. Without some external metadata or prediction this filtering isn't really possible then? Should I proceed without filtering for now? (not really a major issue given I don't have backing data anyways)

[xi-yang]

I think you can simply get all the reservations and then only expose "ours" based on the name / description pattern.

Two potential improvements to check:

• Does OSCARS reservations data have a way to return a list based on filtering? So we do not have to iterate and filter after retrieval.
• Does OSCARS provide extra tagging / metadata? So we can store SENSE related information without bothering with formatting the name / description fields.

[R-Jimenez]

The only parameters across ResvService are Interval interval and String connectionId.

Interval is a simple wrapper they have for a beginning and ending Instant pair, and connectionId seems to be either a UUID or some other ID string for a Schedule (which I assume is their name for a reservation). Again really hard to guess at this without some data but that's my insight from the code.

[R-Jimenez]

In terms of metadata/tagging it would likely require editing the entities. Each is explicitly defined JPA, and I don't see any general metadata maps across the ones I've seen so far.

[xi-yang]

Base line model looks good from the dev1 deployment. Moving on to connection (switchingSubnet) and delta handling.

[R-Jimenez]

Instances created on dev1 using the OSCARS testbed do create connections, and I can review them via API, but the orchestrator cannot verify. There may be an issue with the model pull, so I'm going to reinvestigate the code and see if I can find something obvious.