[Bier] Extending IGMP/MLD with BIER sender parameters?

[Stig Venaas <[e-mail]>]

Hi

As I mentioned in the last meeting, it may be good to store BIER sender
info in IGMP/MLD messages, like BIER prefix, BFR-ID and sub-domain.
I would like to hear your thoughts on this.

Currently in the IGMP/MLD overlay we require that the source address of
reports is the BFR prefix, allowing the BFR-ID of the sender to be
derived assuming we know the sub-domain. However we have no good
way of knowing the sub-domain. Alternatively one could get this information
from the BIER header, but this information is often not visible to upper layer
protocols.

For pim we decided to add a join attribute with sub-domain-id, BFR-ID
and BFR-prefix. This is similar to the PMSI tunnel attribute defined
for MVPN containing

          +---------------------------------+
          |  Sub-domain-id (1 octet)        |
          +---------------------------------+
          |  BFR-id (2 octets)              |
          +---------------------------------+
          |  BFR-prefix (4 or 16 octets)    |
          +---------------------------------+

Do you think we should extend IGMP/MLD messages over BIER to
include this information?

Currently IGMP and MLD RFCs have some text about additional data.
E.g. RFC 3376 in 4.1.10 and 4.2.11. For reports it says:

4.1.10. Additional Data

   If the Packet Length field in the IP header of a received Query
   indicates that there are additional octets of data present, beyond
   the fields described here, IGMPv3 implementations MUST include those
   octets in the computation to verify the received IGMP Checksum, but
   MUST otherwise ignore those additional octets.  When sending a Query,
   an IGMPv3 implementation MUST NOT include additional octets beyond
   the fields described here.

Hence I think we could define an extended message for use with BIER.
Existing implementations (non-BIER routers) would ignore any additional
octets. While routers implementing IGMP/MLD over BIER can parse the
additional data. I would suggest that the extra data is like the PMSI
tunnel attribute above. However, I also think there is a chance that IGMP
messages might have additional data for other reasons in the future, so I
think we should define a type, so we might add something like:

          +---------------------------------+
          |  Extension type (1 octet)       |
          +---------------------------------+
          |  Sub-domain-id (1 octet)        |
          +---------------------------------+
          |  BFR-id (2 octets)              |
          +---------------------------------+
          |  BFR-prefix (4 or 16 octets)    |
          +---------------------------------+

where say extension type 1 means BIER with the format above. Any
other use of IGMP/MLD additional data should get its own type,
so that a BIER IGMP/MLD router can ignore it (by checking for
the BIER extension type).

What do you think? Should we do this?

Thanks,
Stig