SAI Ambiguities

########## Ambiguities to resolve

########## Parsing and packet validation

• No specific definition of VLAN tag. We assume TPID 0x8100, but it is not specified anywhere

  • Yes, 0x8100 is the hardcoded value

• Are priority-tagged packets “tagged” or “untagged” for the purposes of DROP_TAGGED/DROP_UNTAGGED

  • MSFT to think about it

• Are there any additional packet verification rules? For example, how should the following packets be treated:

  • Ethernet packets with MACSA[40]==1 (multicast source address).

  • Ethernet packets with MACSA==00:00:00:00:00:00

  • Ethernet packets with MACDA==00:00:00:00:00:00

  • Ethernet packets with MACSA == MACDA

    i. Treat per IEEE specs (i.e. drop packets)

  • Ethernet packets with LLC/SNAP encapsulation (esp. with ProtocolID=0x0800)

    i. Do not allow for now

########## Router Interfaces

1. The order of precedence between port-based and VLAN-based router interfaces is not specified

   • API implementation is responsible for the correct programming even if the data plane allows more flexibility

   • If a port-based router interface is created, that port cannot accept tagged packets. This port cannot be added to a VLAN, the default VLAN can be set on a port...

     • MSFT to think about: priority-tagged packets case
     • MSFT to think about which packets are acceptable and consult with other participants. The router can only process IPv4 and IPv6 packets. If any other packet manages to get in, it must be dropped. If you don’t want that to happen, then it should be trapped before the router.

2. Ingress functionality:

   • Which packets are subject to routing functionality: just IPv4 and IPv6? What about ARP?

     • See above

   • If neither SAI_ROUTER_INTERFACE_ATTR_SRC_MAC_ADDRESS, nor SAI_SWITCH_ATTR_SRC_MAC_ADDRESS are set, does it mean that ALL packets ingressing on a given port/VLAN will go to L3 processing, or none?

   -   SRC\_MAC\_ADDRESS must always be set (at least for
       the switch)
   -   It’s OK to create many router interfaces with different
       SRC\_MAC\_ADDRESS
   

   • While the attribute name is SRC_MAC_ADDRESS, doesn’t it mean that packets with the given Destination MAC address need to match? It probably should have been called MAC_ADDRESS (without SRC)

     • MSFT: Think about separating into Ingress and Egress Routing Interfaces

3. It is not clear what kind of MAC addresses are allowed for SAI_ROUTER_INTERFACE_ATTR_SRC_MAC_ADDRESS and SAI_SWITCH_ATTR_SRC_MAC_ADDRESS. Are multicast addresses allowed, for example? How about broadcast or all-zeroes?

   • For now use Unicast MAC addresses

4. Is SAI_ROUTER_INTERFACE_ATTR_MTU an ingress or egress parameter (or both)?

   • Both

5. Router interfaces are also used in the neighbor objects. However, it is not explicitly specified what happens. Do they always set MACSA=RouterMac and the new VLAN ID?

   • For port-based interfaces VLAN_ID is irrelevant (see below)

6. What about port-based Router Interfaces? What do they provide? Just MACSA or VLAN_ID which is the default on a port?

-   Port-based router interfaces provide both MAC SA and the
    egress port.

3. Should the VLAN, specified as SAI_ROUTER_INTERFACE_ATTR_VLAN_ID exist? What if it is removed after the interface has been created (SAI_STATUS_OBJECT_IN_USE)?

   • SAI must enforce consistency

4. Same thing for SAI_ROUTER_INTERFACE_ATTR_VIRTUAL_ROUTER_ID? What if the virtual router is removed (SAI_STATUS_OBJECT_IN_USE)?

   • SAI Enforces consistency

########## Virtual Routers

1. Which Admin state has precedence, virtual router or router interface admin state?

   • It’s an AND

2. Is SAI_ROUTER_INTERFACE_ATTR_SRC_MAC_ADDRESS ignored if you have a virtual router without SAI_ROUTER_INTERFACE_ATTR_SRC_MAC_ADDRESS attribute?

   • Correct

########## Routes & NextHops

1. Route maps (vr_id, destination (IP prefix)) to the nexthop ID

2. Nexthop Id resolves into (IP address, router interface)

3. (IP address, router interface) is looked up in the neighbor table, gives us MAC DA.

4. MAC DA is looked up in FDB. Where does vlan_id come from? Probably router interface, but what if it is port-based?

   • FDB is looked up only for VLAN-based Router Interfaces

5. No words about URPF checks

   • Not yet defined

########## Neighbors

It sounds like the neighbor table can be used as a host route table unless SAI_NEIGHBOR_ATTR_NO_HOST_ROUTE is set to true. What’s the priority between that entry and an entry in the routing table? Also, lookup in the neighbor table is done using (IP, router_interface_ID), not (IP, vr_id).

• MSFT to think about it. My proposal: If SAI_NEIGHBOR_ATTR_NO_HOST_ROUTE if FALSE, that means that an entry is automatically added to the route table, just as a convenience.

########## LAGs

1. it is not clear where lag_id can be used. The spec is vague. For example, can a router interface be created for a LAG? If yes, what’s the VLAN ID of the egress packet? Depends on a port?

   • MSFT to clarify

2. Is it OK to add the same port to to a LAG multiple times?

   • No

3. Is it OK for a port to be added to multiple LAGs? How ingress LAG is resolved?

   • No

4. Are port-based router interfaces looked up using the ingress port or ingress LAG?

   • Yes

########## SAI Status Codes

1. SAI_STATUS_INVALID_VLAN_ID does it mean that the VLAN hasn’t been created or that VLAN ID is simply out of 0..4095 (or is it 0..4094, 1..4095, 1..4094?) range?

   • MSFT to think about it

########## STP

1. How exactly LEARNING, FORWARDING and BLOCKING states are defined (since there is no BPDU definition around)?

   • MSFT to think about it. 01:80:C2:xx:xx:xx ? Something else?
   • Make sense to add DISABLED state

2. What happens if a VLAN is added to multiple STP VLAN Lists?

   • STP group is a VLAN property

########## ACL

1. What’s the semantics of SAI_ACL_TABLE_ATTR_PRIORITY? Is “Priority 0” highest or lowest?

   a. Priority 0 is lowest