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

["IJsbrand Wijnands (iwijnand)" <[e-mail]>]

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

Sent from my iPhone

> On 28 Aug 2019, at 00:03, Stig Venaas <[e-mail]> wrote:
> 
> 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
> 
> _______________________________________________
> BIER mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bier