SENSE provider integration

[xi-yang]

We agreed to create a slice / network schema representation of SENSE resources in fabfed format and map that into SENSE service profiles.

For the experiment, I created two example profiles, one with network L2 connection. The other has one end on an end host with IP address being assigned.

Note that: (1) all the greened highlighted fields are editable. For terminals, a select of URIs are provided. For VLANs, a range or a single VLAN can be used. (2) The service FABRIC-L2-Host does not allocate new host. It only configure VLAN and IP address on the DTN host. We can decide how to model that as part of our slice network.

Let's use these two test cases to validate the SENSE provider design.

• [x] 1. L2 connection stitching with SENSE (see https://github.com/fabric-testbed/fabfed/issues/11#issuecomment-1310532357)
• [x] 2. AWS cloud connect stitching with SENSE (see https://github.com/fabric-testbed/fabfed/issues/11#issuecomment-1310538527)

[xi-yang]

[abessiari]

Thanks I am able to see the profiles.

[xi-yang]

Here is an example profile that allocates VPC/VM in AWS and provides a direct connect (DX) service for stitching.

Note that assumption here is that the DX connection has been ordered by a network partner like AL2S. A name (like AL2S-DX-FABRIC-Test1) is provided. VLAN has be selected upon ordering of the DX connection that can be found and handled by the SENSE orchestrator. So only Layer-3 information is needed here.

{
  "data": {
    "parent": "urn:ogf:network:aws.amazon.com:aws-cloud",
    "gateways": [
      {
        "name": "Gateway 1",
        "connects": [
          {
            "to_hosted_conn": "AL2S-DX-FABRIC-Test1",
            "amazon_ip": "192.168.1.1/30",
            "amazon_asn": "65000",
            "customer_asn": "55038",
            "customer_ip": "192.168.1.2/30",
            "authkey": ""
          }
        ],
        "type": "AWS Direct Connect"
      }
    ],
    "cidr": "10.0.0.0/16",
    "subnets": [
      {
        "vpn_route_propagation": true,
        "name": "Subnet 1",
        "cidr": "10.0.0.0/24",
        "vms": [
          {
            "interfaces": [
              {
                "public": false,
                "type": "Ethernet"
              }
            ],
            "name": "VM 1"
          }
        ],
        "internet_routable": false
      }
    ]
  },
  "service": "vcn",
  "options": [
    "aws-form"
  ]
}

[xi-yang]

TODO:

• [x] 1a. Create FAB experiment description (.fab resource files)
• [x] 1b. Request FABRIC and SENSE slices through respective providers
• [x] 1c. Stitching produces VLAN from FABRIC and then consumes it into SENSE profile parameter
• [x] 1d. IP can be by experiment input or configured post-workflow. Then verify we can ping across two ends.

[xi-yang]

TODO:

• [x] 2a. Create FAB experiment description (.fab resource files)
• [x] 2b. Request FABRIC and SENSE slices through respective providers
• [x] 2c. Stitching produces AWS hosted connection at AL2S associated FacilityPort (ordering from FABRIC AL2S AM)
• [x] 2d. Stitching consumes the hosted connection by SENSE that creates VIF
• [x] 2e. L2 (VLAN) and L3 (BGP peering information) for stitching can be provided in optional user experiment description initially for PoC but should eventually generated by FABRIC orchestrator.

[xi-yang]

@abessiari In sense-o-api==1.25, I added the following API call that would get the UUID of a profile from its name.
GET /profile/{name}?force=true&fetch=false

This can be tested using the CLI client.

$ sense_util.py -p -n FABRIC-AWS-DX
69a24fb3-f2d9-4dc4-a07b-f32b44add2e3

With this, we can put profile either name or id in the network description field.

[abessiari]

Great. Thanks

[xi-yang]

Use case 1 has ben demonstrated. Use case 2 is finished but pending on final tests (waiting for Internet2 to fix OESS API).

[xi-yang]

Use case 2 verified working. We still need some improvement on the summary output like the VM private IP address. Let's leave that to the final wrap up tests at the shrink-packaging time.