zebra: suggest to use SEG6_LOCAL_VRFTABLE than SEG6_LOCAL_TABLE for END.DT6

[zhutang]

Since END.DT6 is mostly used for EVPN in WAN, the seperation of multi-tenant in routing tables is important, so strict mode of vrfs should be used to ensure the one-to-one mapping of vrfs and routing tables. so it is suggested to use SEG6_LOCAL_VRFTABLE, not SEG6_LOCAL_TABLE for END.DT6.
In current release, END.DT4 and END.DT46 have already used SEG6_LOCAL_VRFTABLE, keeping pace with the other two is also needed.

[cscarpitta]

Please provide more information.

What is the reason behind this change? What are you trying to achieve here? If you are trying to fix an issue, what is the issue?

[zhutang]

Please provide more information.

What is the reason behind this change? What are you trying to achieve here? If you are trying to fix an issue, what is the issue?

yes, I am trying to fix an issue.

based on [iproute2-next v1 1/1] seg6: add support for vrftable attribute in End.DT4/DT6 behaviors, and seg6: add support for the SRv6 End.DT4 behavior, I think End.DT4/DT6 leverages a VRF device in order to force the routing
lookup into the associated routing table using the "vrftable" attribute, so End.DT6 should use SEG6_LOCAL_VRFTABLE in netlink msg to kernel, not SEG6_LOCAL_TABLE.

however, topotest bgp_srv6l3vpn_to_bgp_vrf failed after rt_netlink.c is changed, I am checking the reason of this fail.

[donaldsharp]

Please take the time and explain your thinking in the actual commit itself.

[Jafaral]

Please take the time and explain your thinking in the actual commit itself.

and a commit/PR title that is less cryptic would help too.

[zhutang]

Please take the time and explain your thinking in the actual commit itself.

OK, I am trying to modify my commit. By the way, do you think SEG6_LOCAL_VRFTABLE is in the right choice, because I found some tests using the traditional SEG6_LOCAL_TABLE and works well, although this is not best.