With the new PIM and IGMP protocol modules, I am curious if there is any interest in adding an AFT module for ipv4-multicast. After some cursory research into some vendor documentation into how their MFIBs are formatted, it appears that a common method of storing the table is to index on (source, mgroup/mask), with each table entry containing an input interface (which may be null), and a list of output interfaces (which may be empty).
After looking at some of the other AFT modules, I think that an IPv4 multicast AFT would look something like this:
+--rw afts
+--rw ipv4-multicast
+--rw ipv4-mc-entry* [source mcast-prefix]
+--rw source -> ../config/source
+--rw mcast-prefix -> ../config/mcast-prefix
+--rw config
| +--rw source? oc-inet:ipv4-address
| +--rw mcast-prefix? oc-inet:ipv4-mc-prefix
+--ro state
+--ro source? -> ../config/source
+--ro mcast-prefix? -> ../config/mcast-prefix
+--ro packets-forwarded? oc-yang:counter64
+--ro octets-forwarded? oc-yang:counter64
+--ro last-activity? oc-types:timeticks64
+--ro input-interface? -> ../../../../next-hops/next-hop/state/id
+--ro output-group? -> ../../../../next-hop-groups/next-hop-group/state/id
oc-inet:ipv4-mc-prefix would be defined as a prefix contained in 224.0.0.0/4, with the mask as /32 unless this is a bidir-PIM tree. I am not sure if we should include mask entries whose purpose is only to punt to the CPU to create new entries (RP entries, etc), and also if it would be valid to use oc-inet:ipv4-address 0.0.0.0 to indicate the * in (*, G)
I am leveraging the existing next-hops and next-hop-groups modules to handle identifying the input and output interfaces -- if this is an incorrect approach due to the interface-only approach of multicast, let me know what else might be preferred.
The next-hops themselves wouldn't need anything other that interface-ref entries, as nothing the packet is changed/rewritten when it's sent to the output interfaces (source IP remains that of the source, destination IP remains the mcast group, destination MAC remains derived from the mcast group).
I'm happy to work on composing the actual module itself, but wanted to see if there was a general need for the module, and if there are any errors in my assumptions above or edge cases I have not considered.
With the new PIM and IGMP protocol modules, I am curious if there is any interest in adding an AFT module for ipv4-multicast. After some cursory research into some vendor documentation into how their MFIBs are formatted, it appears that a common method of storing the table is to index on (source, mgroup/mask), with each table entry containing an input interface (which may be null), and a list of output interfaces (which may be empty).
After looking at some of the other AFT modules, I think that an IPv4 multicast AFT would look something like this:
oc-inet:ipv4-mc-prefixwould be defined as a prefix contained in 224.0.0.0/4, with the mask as /32 unless this is a bidir-PIM tree. I am not sure if we should include mask entries whose purpose is only to punt to the CPU to create new entries (RP entries, etc), and also if it would be valid to useoc-inet:ipv4-address0.0.0.0 to indicate the * in (*, G)I am leveraging the existing next-hops and next-hop-groups modules to handle identifying the input and output interfaces -- if this is an incorrect approach due to the interface-only approach of multicast, let me know what else might be preferred.
The next-hops themselves wouldn't need anything other that interface-ref entries, as nothing the packet is changed/rewritten when it's sent to the output interfaces (source IP remains that of the source, destination IP remains the mcast group, destination MAC remains derived from the mcast group).
I'm happy to work on composing the actual module itself, but wanted to see if there was a general need for the module, and if there are any errors in my assumptions above or edge cases I have not considered.