[Bier] Comments on <draft-ietf-bier-mld-02>

[Xiejingrong <[e-mail]>]

Hi,
I have the some comments on the draft.

3.  Overview
   This document proposes to use the mechanisms described in MLDv2 in
   order to enable multicast membership information sharing from BFERs
   toward BFIRs within a given BIER domain.  BMLD queries (resp.
   reports) are sent over BIER toward all BMLD Nodes (resp.  BMLD
   Queriers) using modified MLDv2 messages which IP destination is set
   to a configured 'all BMLD Nodes' (resp. 'all BMLD Queriers') IP
   multicast address.
[XJR] I don't think the 'resp.' is good for a draft. I try to understand like this:
BMLD queries are sent over BIER toward all BMLD Nodes, using DA 'all BMLD Nodes'.
BMLD reports are sent over BIER toward all BMLD Queriers, using DA 'all BMLD Queriers'.

5.1.  Configuration Parameters
   Both Queriers and Listeners MUST operate as BFIRs and BFERs within
   the BIER domain in order to send and receive BMLD messages.  They
   MUST therefore be configured accordingly, as specified in [RFC8279].
   All Listeners MUST be configured with an 'all BMLD Queriers'
   multicast address and the BFR-ids of all the BMLD Queriers.  This is
   used by Listeners to send BMLD reports over BIER toward all Queriers.
   All Queriers MUST be configured to accept BMLD reports sent to this
   address.
   All Queriers MUST be configured with an 'all BMLD Nodes' multicast
   address and the BFR-ids of all the Queriers and Listeners.  This
   information is used by Queriers to send BMLD queries over BIER toward
   all BMLD Nodes.  All BMLD Nodes MUST be configured to accept BMLD
   queries sent to this address.

   It may be cumbersone to configure the exact set of BFR-ids for
   Queriers and Listeners.  One MAY configure the set of BFR-ids to
   contain any potentially used BFR-id, perhaps having all bit positions
   set.  There is no harm in configuring unused BFR-ids.  Configuring
   the BFR-ids of additional routers would in most cases cause no harm,
   as a router would drop the BMLD message unless it is configured as a
   Querier or a Listener.
[XJR] I am afraid that may still be a lot of configuration, considering the use case this draft listed ---- each vni need to configure a 'all BMLD Queriers' and 'all BMLD Nodes' multicast address.
[XJR] besides that, the 'would in most cases cause no harm' is very confused to me. Can the authors point out which may be the cases cause harm, how would that harm be?

5.3.  Packet Forwarding

   BMLD Queriers configure the BIER Layer using the information obtained
   using BMLD, which associates BMLD Listeners (identified by their BFR-
   Prefixes) with their respective MLDv2 membership state.
[XJR] BMLD Queries construct the multicast overlay forwarding information. The text are saying the Queriers construct the BIER Layer ?

A.3.  A BIER MLD solution for Virtual Network information
   The BIER MLD solution allows having multiple MLD instances by having
   unique pairs of BMLD Nodes and BMLD Querier addresses for each
   instance.  Assume for now that we have a unique instance per VNI and
   that all BMLD routers are using the same mapping between VNIs and
   BMLD address pairs.  Also for each VNI there is a multicast group
   used for encapsulation of BUM traffic over BIER.  This group may
   potentially be shared by some or all of the VNIs.
[XJR] per the VNI, an 'all BMLD Nodes' and 'all BMLD Queriers' need to be configured, as pointed above.
Besides, how could you differentiate the VNI a packet belongs to ? Do you have a upstream-assigned VpnLabel or a domain-unique Vni value ? What's the proto value in the BIER header ?

Besides the above comments, I have the following questions:
(1) What is the advantages does the authors think this draft as a solution to DC BUM using BIER, comparing to <draft-ietf-bier-evpn> draft ?
(2) There is even consideration to use MVPN signal between EVPN PEs for per-VRF. How do you feel about that as an alternative?

Thanks,
Jingrong