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

From: Stig Venaas <[email-masked]>
Date: Tue, 20 Aug 2019 10:06:44 -0700

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

---

From: Stig Venaas <[email-masked]>
Date: Tue, 27 Aug 2019 15:02:46 -0700

Hi

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

Thanks,
Stig

---

From: "IJsbrand Wijnands (iwijnand)" <[email-masked]>
Date: Wed, 28 Aug 2019 08:46:14 +0000

Hi Stig, I think that is a good idea..

Sent from my iPhone

> On 28 Aug 2019, at 00:03, Stig Venaas <[email-masked]> wrote:
> 
> Hi
> 
> _______________________________________________
> BIER mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bier

---

From: "Mankamana Mishra (mankamis)" <[email-masked]>
Date: Fri, 30 Aug 2019 22:05:24 +0000

Hi Stig, 
if we plan to extend IGMP RFC, then may be it would be good to provision something which can be used even in future. Using additional data as is might solve the problem for now but what if something new comes in future which want to use same set of data. So may be we can add some extra field as type which can indicate what is the additional data carrying. 

Mankamana 

> On Aug 28, 2019, at 1:46 AM, IJsbrand Wijnands (iwijnand) <[email-masked]> wrote:
>

---

From: Stig Venaas <[email-masked]>
Date: Fri, 30 Aug 2019 15:26:43 -0700

Agree. That is why I added an Extension Type field.

Stig

On Fri, Aug 30, 2019, 15:05 Mankamana Mishra (mankamis) <[email-masked]>
wrote:

> Hi Stig,
> if we plan to extend IGMP RFC, then may be it would be good to provision
> something which can be used even in future. Using additional data as is
> might solve the problem for now but what if something new comes in future
> which want to use same set of data. So may be we can add some extra field
> as type which can indicate what is the additional data carrying.
>
> Mankamana
>