vbd/impl/vbridge-workflow.txt

   1 VPP Inventory/Topology
   2 ----------------------
   3
   4 - VPP management done through netconf-node-topology
   5 - Mount point management done by sal-netconf-connector
   6
   7
   8 Virtual Bridge Domain management
   9 --------------------------------
  10
  11 Prerequisite: configured netconf-node-topology
  12
  13 1) Create a Virtual Bridge Domain:
  14
  15         A) The UI creates a network topology instance in Controller Data Store
  16         with:
  17
  18         - topology-types/vbridge-topology container
  19         - tunnel-type set to tunnel-type-vxlan
  20         - tunnel-parameters/vxlan/vni set to appropriate value
  21         - any bridge domain parameters from v3po:bridge-domain-attributes
  22
  23         B) The Controller App receives a DataTreeChangeNotification about the
  24         topology instance being created
  25
  26 2) Assign a VPP into a Virtual Bridge Domain
  27         Prerequisite: Virtual Bridge Domain exists
  28
  29         A) The UI creates a 'node' within the VBD network topology in the
  30         Controller Data Store with:
  31
  32         - bridge-member container
  33         - supporting-node pointing to the VPP node in the
  34           netconf-node-topology
  35
  36         B) The Controller App receives a DataTreeChangeNotification about the
  37         node being added, and:
  38
  39         - it looks at the supporting-node in the netconf topology and if the
  40           node is connected:
  41           - it creates a bridge domain with the name matching this VBD name,
  42             copying bridge domain parameters from VBD Topology configuration
  43             into the VPP
  44           - once that succeeds it creates the corresponding
  45             supporting-bridge-domain leaf in the Controller's operational
  46             datastore. The leaf contains a RESTCONF-encoded instance
  47             identifier of the bridge domain created in the VPP, relative to
  48             that VPP's mount point.
  49
  50 3) Assigning a physical VPP interface into a Virtual Bridge Domain
  51         Prerequisite: The VPP itself has been added to the Virtual Bridge
  52                       Domain
  53
  54         A) The UI creates a 'termination-point' inside the 'node' added in 2),
  55         with:
  56
  57         - interface name.
  58
  59         B) The Controller App receives a notification of this being done and:
  60         - looks if the VPP is connected, if it is, the app will:
  61           - add the interface into the VPP's bridge domain configuration
  62
  63 Inverse operations are achieved by the UI deleting the corresponding nodes in
  64 the Controller's configuration data store.
  65
  66
  67 Virtual Bridge Domain tunnel management
  68 ---------------------------------------
  69
  70 Operation is triggered by adding more than one VPP into the virtual bridge
  71 domain, for sake of clarity this describes only one-way tunnel setup. The
  72 process is repeated until a full mesh is achieved (FUTURE: spanning tree?).
  73 The process is also simplified for demo purposes, real-world deployment would
  74 deal with day-1 configuration and multi-provider setups.
  75
  76 Demo assumption: there is exactly one interface with a VRF and IP address
  77 assined, which is the interface to be used for tunnels
  78
  79 The Controller App looks at the Source VPP:
  80 - it finds the only interface with VRF and IP addresses. It will use this VRF
  81   as the vxlan tunnel VRF. It will use the IP address as the vxlan tunnel
  82   source.
  83
  84 The Controller App looks at the Destination VPP:
  85 - it finds the only interface with VRF and IP addresses. It will use the IP
  86   address as the vxlan tunnel destination.
  87
  88 The Controller App sets up the tunnel on the source VPP, using the VNI
  89 configured for this Virtual Bridge Domain and IP addresses as detailed above.
  90
  91 The controller app creates a new termination point within the VBD's the
  92 controller's  operational data store, under the
  93 node representing the source VPP, with a generated ID (mechanism is TBD, must
  94 not conflict with VPP names) and 'tunnel-interface' leaf, which points to the
  95 vxlan interface created on the source VPP (e.g. VPP config state).
  96
  97 This process is repeated in the reverse direction.
  98
  99 Once that is done, the controller app will create a link from the newly-created
 100 source TP to the newly-created destination TP in the controller's operational
 101 data store, with leaf 'tunnel' pointing to the source VPP's interface operation
 102 state (e.g. VPP vxlan oper state). A reverse link will be created, with the
 103 'tunnel' leaf pointing to the destination VPP's interface state.
 104