apratimmukherjee
commented
3 years ago Trying to understand the target here . My assumptions: 1) Request in sonic area . Target is to run above use-case with IxNetwork controller via OTG script instead of IxNetwork client. [i.e. concrete implementation request for OTG -> IxNetwork , not OTG->Athena-G ] 2) We have support in model upto BGP over loopback in chained device. This part can already be implemented in OTG->IxN path and tested to be working. 3) Need model change to support VPNs in general as children of BGP peers in model, and need specific support EVPN with specific support for EVPN VxLAN with EVPN routes configured to be advertised as EVPN NLRIs to DUT. This needs some amount of EVPN expertise to ensure that EVPN model handles / can handle non VXLAN variants in future. Also needs to ensure that other VPNs e.g. L3VPN or MVPN can be added in future easily without breaking backward compatibility. 4) Need to make sure that OTG traffic data model supports VxLAN encapsulation ( probably just VxLAN : need to check if any MPLS label e.g. for transport over core , is needed or not ) . 5) Need to check if traffic has dynamic DUT learned information (continuation of above point regarding possible need of learned MPLS labels in traffic frame) . If yes, need to understand if okay to work with raw traffic or need support to auto-add the learned fields if any in traffic. Again , needs detailed understanding of EVPN VxLAN traffic frames.
Awaiting a draft test plan for this so that more details can be added here.
Meanwhile, overview in terms of IxNetwork NGPF scenario has been attached below.