On Fri, Nov 20, 2020 at 09:39:12AM +0000, Xiaoliang Yang wrote: > On 2020-11-18 3:01 Joergen Andreasen wrote: > > I like your idea about using filter actions for FRER configuration. > > > > I think this is a good starting point but I think that this approach > > will only allow us to configure end systems and not relay systems in > > bridges/switches. > > > > In the following I refer to sections and figures in 802.1CB-2017. > > > > I am missing the following possibilities: > > Configure split without adding an r-tag (Figure C-4 Relay system C). > > Configure recovery without popping the r-tag (Figure C4 Relay system F). > > Disable flooding and learning per VLAN (Section C.7). > > Select between vector and match recovery algorithm (Section 7.4.3.4 and > > 7.4.3.5). > > Configure history length if vector algorithm is used (Section 10.4.1.6). > > Configure reset timeout (Section 10.4.1.7). > > Adding an individual recovery function (Section 7.5). > > Counters to be used for latent error detection (Section 7.4.4). > > > > I would prefer to use the term 'frer' instead of 'red' or 'redundancy' > > in all definitions and functions except for 'redundancy-tag'. > > Thanks for your suggestion, it's very useful to me. I ignored frer on > relay system. I will study sections and features you mentioned on > Spec. If using a new tc-frer action is ok, I will perfect and update > it.
Is replicated IP multicast (with IGMP/MLD snooping) something that is going to work using your current abstraction? I think this is one area that is required to work at a higher level than the level of a physical port.
