Add a new attribute SAI_BFD_SESSION_ATTR_NEXT_HOP_ID to saibfd.h

[baorliu]

Adding a new attribute SAI_BFD_SESSION_ATTR_NEXT_HOP_ID to saibfd.h to support forwarding single hop bfd packet to specific nexthop.

The proposed usage is:
1, this attribute can be provided both in create_bfd_session and set_bfd_session_attribute.
2, if SAI_BFD_SESSION_ATTR_USE_NEXT_HOP (optional, default if false) is set to true, BFD session will get next hop from SAI_BFD_SESSION_ATTR_NEXT_HOP_ID value and forward the bfd packet to the next hop. If SAI_BFD_SESSION_ATTR_USE_NEXT_HOP is false, attribute SAI_BFD_SESSION_ATTR_NEXT_HOP_ID will be ignored.
3, when both SAI_BFD_SESSION_ATTR_HW_LOOKUP_VALID and SAI_BFD_SESSION_ATTR_USE_NEXT_HOP, the implementation is vender dependent.

[anamehra]

Hi @abdosi , @kcudnik , Please review. Thanks

[kcudnik]

Is this needed? If next hop is null it will not be used, does make sense to make only 1 attribute next hop without second one which acts flag ?

[baorliu]

Hi @kcudnik ,
SAI_NULL_OBJECT_ID is valid for SAI_BFD_SESSION_ATTR_NEXT_HOP_ID here.
The reason is that, when interface becomes DOWN, the corresponding nexthop will be removed. In this case, orchagent update SAI_BFD_SESSION_ATTR_NEXT_HOP_ID SAI attribute with value SAI_NULL_OBJECT_ID to that single hop BFD session, and update NPU/ASIC eventually, make NPU/ASIC drop the egress BFD packet on purpose.
When the interface becomes UP, orchagent update BFD session with a normal nexthop_id, so the BFD TX packet resume.

[kcudnik]

From your description I see no need for bool flag you described exactly how this can be done without that flag

[baorliu]

The bool flag SAI_BFD_SESSION_ATTR_USE_NEXT_HOP is trying to direct SAI to use next_hop approach or to use "SAI_BFD_SESSION_ATTR_HW_LOOKUP_VALID == false" + SAI_BFD_SESSION_ATTR_DST_MAC_ADDRESS approach.

because 0 is a valid mac address (even it might not be valid for SAI_BFD_SESSION_ATTR_DST_MAC_ADDRESS), with SAI_BFD_SESSION_ATTR_USE_NEXT_HOP=true, we can avoid checking SAI_BFD_SESSION_ATTR_HW_LOOKUP_VALID==false && SAI_BFD_SESSION_ATTR_DST_MAC_ADDRESS==0

[kcudnik]

got confused here, what mac has to do wiht hthat ?

for me you have 4 options here:

1. use_next_hop = true, && next_hop = valid_oid
2. use_next_hop = true, && next_hop = NULL
3. use_next_hop = false, && next_hop = valid_oid
4. use_next_hop = false, && next_hop = NULL

in 2 3 and 4 you will not use next hop, since next hop is ether NULL or use_next_hop is false
so the only scenario when possible to use is scenario 1
thus this logic points that having use_next_hop is unnecessary flag, setting it to true when next hop is NULL have no effect, so actual value of next_hop NULL/valid_oid is the same as flag false/true

[baorliu]

Sorry for the confusion here, let's forget SAI_BFD_SESSION_ATTR_HW_LOOKUP_VALID and SAI_BFD_SESSION_ATTR_DST_MAC_ADDRESS related things, and focus on NEXT_HOP only here.

1. use_next_hop = true, && next_hop = valid_oid --> it tells HW to construct BFD packet using the nexthop info directly and skips HW_LOOKUP.
2. use_next_hop = true, && next_hop = NULL --> it tells HW to use nexthop, but because of null value, HW is not able to construct TX BFD packet. The system stops BFD TX in this way. use_next_hop = true, && next_hop = NULL is a valid combination, NOS stops BFD session TX on purpose in the skip HW_LOOKUP case.
   The use case in second case, for portchannel, even portchannel is DOWN, part of its members might be still UP and packet can get through physically. if nexthop is used and BFD packet is sent directly to TX port, single hop BFD packet can reach peer system which is not expected when portchannel is DOWN.

[kcudnik]

im even more confused XD i dont know the workflow of pipeline here XD