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

["Bidgoli, Hooman (Nokia - CA/Ottawa)" <[e-mail]>]

Just playing the devil’s advocate

How is this different then the PIM case? If we said these info is needed because of HW specific reasons I would imagine it is needed on both protocols.

Regards

Hooman

From: BIER <[e-mail]> On Behalf Of [e-mail]
Sent: Thursday, September 5, 2019 7:48 AM
To: [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: Re: [Bier] Extending IGMP/MLD with BIER sender parameters?


Hi Stig,



IMO it does make sense.



Sandy


原始邮件
发件人：StigVenaas <[e-mail]<mailto:[e-mail]>>
收件人：Mankamana Mishra (mankamis) <[e-mail]<mailto:[e-mail]>>;
抄送人：IJsbrand Wijnands <[e-mail]<mailto:[e-mail]>>;BIER WG <[e-mail]<mailto:[e-mail]>>;
日 期 ：2019年08月31日 06:27
主 题 ：Re: [Bier] Extending IGMP/MLD with BIER sender parameters?
_______________________________________________
BIER mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/bier
Agree. That is why I added an Extension Type field.

Stig


On Fri, Aug 30, 2019, 15:05 Mankamana Mishra (mankamis) <[e-mail]<mailto:[e-mail]>> 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

> On Aug 28, 2019, at 1:46 AM, IJsbrand Wijnands (iwijnand) <[e-mail]<mailto:[e-mail]>> wrote:
>
> Hi Stig, I think that is a good idea.
>
> Sent from my iPhone
>
>> On 28 Aug 2019, at 00:03, Stig Venaas <[e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/bier
>
> _______________________________________________
> BIER mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/bier