P4 Support

[kthare10]

Enabling P4 Switch on FABRIC

Standard slice request

User's Slice Request

The user requests a slice with the following specifications:

• VM1: Located at Site1, connected via a Shared NIC.
• VM2: Located at Site2, connected via a Shared NIC.
• P4 Switch: Located at either Site1, Site2, or Site3.

Connections:

• VM1 to P4 Switch Port 1 via an L2PTP link.
• VM2 to P4 Switch Port 1 via an L2PTP link.
• Submit the Slice.

Expected Result:

Upon deploying P4 code on the P4 switch, VM1 should successfully transmit traffic to VM2.

Slice Request

A sample slice request using fablib can be found below:

simple_p4_slice_request

Switch Provisioning for Users

The AM Handler performs the following steps to provision a P4 switch:

• Boots a Debian-based golden image, specifically a RARE freeRtr derivative:

  echo rare | sudo -S efibootmgr --bootnext 0004
  echo rare | sudo -S reboot

• Installs the user's SSH key into the root account:

  echo {{ sshkey }} >> ~/.ssh/authorized_keys

• Assigns a floating IP address (more details below).

Switch Deprovisioning

The AM Handler undertakes the following actions to deprovision a P4 switch:

• Removes the user's SSH key.
• Releases the floating IP address (details below).

Outstanding Items

Connectivity of P4 Switch

• Accessible solely via the head node.
• Proposed method (Mert): Utilize a Floating IP Address for the P4 switch, allowing allocation and deallocation, potentially using Ironic.

Switch Environment

• Ensures inclusion of licensed SDE within the image.
• Facilitates all compilation and build processes directly on the switch.
• RENCI holds an Intel Level 2 license permitting these actions.
• SC labs utilize P416, aligning with our preferred configuration.
• SC labs demonstrate procedures such as connecting VSCode (including terminal windows) to the switch via SSH.
• Provides a login shell/SSH on the switch (root access), maintaining licensed software integrity on the switch (compiler). Notebooks are configured accordingly.

Queries

• Methods to prevent users from downloading the SDE tar file hosted on the switch?
  • Could this be achieved using Security Group rules?

[ibaldin]

Couple of questions/thoughts

1. Transmitting traffic between VM1 and VM2 is conditional on appropriate P4 program loaded into the switch - are you planning to provide a default that makes it act like e.g. a learning switch? I'm guessing freeRtr does that out of the box. Seems like a good idea - a user gets a working-by-default environment.
2. Deprovisioning user keys - is it needed if the switch is reimaged every time? In my original thinking we were going to wipe the switch clean after every user/use. That seems like a good security feature. Otherwise users will leave all kinds of artifacts behind I think.

[kthare10]

1. As you mentioned intent is to give user a default working environment. freeRtr gives that too. In addition, we are working on for default example P4 code which can be deployed, that just passes traffic.
2. You are right - removing SSH keys is not required as the next provisioning, we flash with the image again.

[kthare10]

Recommendations:

• Special Project permission for using P4 requiring Project Lead to sign a pledge for not sharing the SDE. Something similar to https://wiki.geant.org/display/RARE/P4+targets
• Connectivity to switch via the VM
• Require Switch to be associated with a VM if needed - TBD