Conflicting names of SwitchInterface objects of different switches

[byteocean]

Currently, the OS interface names (e.g., ethernet10) obtained from the Sonic agent is directly used as the SwitchInterface object's name, which would lead to conflicting ones for different switches.

[maxmoehl]

I'd prefer if we could have names that do not depend on the vendor of the device. One thing which always trips me is one- vs. zero-indexing. When communicating with the technicians they always talk about ports and breakouts. The ports are obviously one-indexed as they just count the ports on the back whereas SONiC starts with zero and just skips ports that are not broken out making it almost impossible to do the conversion reliably without explicitly looking it up each time. If there are breakouts, it's also important to know which breakout on which physical port is meant. Therefore my preferred scheme would be eth$port-$breakout. The conversion would then be (assuming four lanes per port):

• Ethernet0 -> eth1-1 (no breakout)
• Ethernet4 -> eth2-1 (broken out into two)
• Ethernet6 -> eth2-3
• Ethernet8 -> eth3-1 (broken out into four)
• Ethernet9 -> eth3-2
• Ethernet10 -> eth3-3
• Ethernet11 -> eth3-4

This naming could be used across all vendors with each operator implementing the conversion. The technical name used to manipulate the state would live somewhere inside the resource so that the reconciler doesn't have to constantly convert between the two.

_{Now imagine doing this conversion in your head, good look :)}

[Giluerre]

My only concern is whether this scheme would remain entirely on the operator’s side, without touching the real aliases, or whether the aliases would also need to be changed on the switches. Then I remembered that LLDP also shows even aliases. During port breakout, we would need to keep in mind that their aliases must be changed explicitly.

LocalPort    RemoteDevice     RemotePortID     Capability    RemotePortDescr
-----------  ---------------  ---------------  ------------  -----------------
Ethernet8    switch1      Eth31(Port31)    BR            Ethernet120
Ethernet12   switch2      Eth31(Port31)    BR            Ethernet120
Ethernet120  switch3      Eth31/1(Port31)  BR            Ethernet120

In general, I like this idea.

Another topic would be port vs interface, by upper mentioned scheme are described only frontpanel ports, if we are not differentiate between port/interface we should extend this scheme with another types of interfaces e.g. loopback,mgmt,vlan...

[maxmoehl]

Right, LLDP is a good point. We could just define that LLDP will contain vendor-specific data though that would obviously reduce the convenience factor quite a bit. On the other hand, trying to properly translate the LLDP data is also not a straightforward task if you consider the possibility that switches from different vendors might be deployed alongside each other.