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

[Stig Venaas <[e-mail]>]

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

Stig


On Fri, Aug 30, 2019, 15:05 Mankamana Mishra (mankamis) <[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]> 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]> 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
> >
> > _______________________________________________
> > BIER mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/bier
>
>