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

[Stig Venaas <[e-mail]>]

Hi

Anyone got any thoughts on this? Is it a good idea, or just try to
publish what we have?

Thanks,
Stig

On Tue, Aug 20, 2019 at 10:06 AM Stig Venaas <[e-mail]> wrote:
>
> 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