subnet can have an associated tunnel interface for evpn

[jainvipin]

@glimchb @venkatmahalingam - pls review one field change in subnet.proto file

[glimchb]

Vipin, I thought you adding subnet reference to the tunnel object. Not the other way around… if tunnel is vxlan, and subnet is bridge we may have one to many…

[jainvipin]

Vipin, I thought you adding subnet reference to the tunnel object. Not the other way around… if tunnel is vxlan, and subnet is bridge we may have one to many…

Yes, a bridge would/could have many tunnel interfaces like it can have many local interfaces. Would it be better to make this field repeated instead of having subnet reference in the tunnel? This way we can keep all interfaces within a subnet together (local and tunnel). e.g. field number 15 is for the local interfaces today. Given that we are not worried about backward compatibility, we can put these two fields together for clarity.

 // when operating in DEVICE_OPER_MODE_HOST mode with multiple host PFs/VFs
  // present, subnet needs to be attached to a PF/VF (aka. host interface),
  // HostIf is list of such VF/PFs
  repeated string host_interface_name_ref = 15;

[jainvipin]

@glimchb @sandersms - should we merge this? this way cloud APIs can be a bit more flexible. Having said that we are addressing evpn use case as a first class APIs and so the use case for this enhancement becomes somewhat unclear.