Subject: [bess] draft-ietf-bess-evpn-igmp-mld-proxy-06 review

From: Luc André Burdet <[email-masked]>
Date: Wed, 3 Mar 2021 13:25:38 +0000

Hi,

I have read this version and have some preliminary feedback;

1.	There is a missing ref to ‘bum-procedures-updates’ not listed in references.

2.	Multicast Flags extcomm figure (page25) has only 31 bits per row?
 
3.	“IGMP Membership Report” needs to be substituted/consistently named throughout (perhaps also capitalised more uniformly)
(sometimes referred to as IGMP membership report, other times IGMP Report, and yet other times as membership report etc.)
 
4.	Proposed change to section 4.1.1 (6).  As written, I find it does not map very well to RFC3376’s message format.
RFC3357 s4.2 defines a MR as multiple Group Records, each with multiple Source IPs.
Current text description doesn’t follow that grouping, describes only mapping “multiple Source IPs to a membership Record”
Can you update to reflect Membership -> groups -> sources hierarchy of RFC3357 ?
 
5.	SPMSI AD terminology not defined (at a minimum define/reference  PMSI)

6.	Is 4.1.1 (3) a MUST NOT?  “In other words, the first hop PE MUST not withdraw”

7.	Section 9.1.2 is not really exposing the problem fully. With the topology provided, the simplest way for PE2 to receive all traffic is to simply disable SMET route and IMET route will pull the multicast traffic.
I think the point this section is trying to make is that SMET must be enabled because of some other router...say PE3... and because of that a *,* needs to be generated.

Regards,
Luc André
 
Luc André Burdet |  Cisco  |  [email-masked]  |  Tel: +1 613 254 4814

On 2021-01-25, 16:55, "BESS on behalf of [email-masked]" <[email-masked] on behalf of [email-masked]> wrote:

    A New Internet-Draft is available from the on-line Internet-Drafts directories.
    This draft is a work item of the BGP Enabled ServiceS WG of the IETF.
    
            Title           : IGMP and MLD Proxy for EVPN
            Authors         : Ali Sajassi
                              Samir Thoria
                              John Drake
                              Wen Lin
    	Filename        : draft-ietf-bess-evpn-igmp-mld-proxy-06.txt
    	Pages           : 33
    	Date            : 2021-01-25
    
    Abstract:
       Ethernet Virtual Private Network (EVPN) solution is becoming
       pervasive in data center (DC) applications for Network Virtualization
       Overlay (NVO) and DC interconnect (DCI) services, and in service
       provider (SP) applications for next generation virtual private LAN
       services.
    
       This draft describes how to support efficiently endpoints running
       IGMP for the above services over an EVPN network by incorporating
       IGMP proxy procedures on EVPN PEs.

    The IETF datatracker status page for this draft is:
    https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-igmp-mld-proxy/
    
    There are also htmlized versions available at:
    https://tools.ietf.org/html/draft-ietf-bess-evpn-igmp-mld-proxy-06
    https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-igmp-mld-proxy-06
    
    A diff from the previous version is available at:
    https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-evpn-igmp-mld-proxy-06

    Please note that it may take a couple of minutes from the time of submission
    until the htmlized version and diff are available at tools.ietf.org.
    
    Internet-Drafts are also available by anonymous FTP at:
    ftp://ftp.ietf.org/internet-drafts/

    _______________________________________________
    BESS mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/bess

---

From: "Rabadan, Jorge (Nokia - US/Mountain View)" <[email-masked]>
Date: Mon, 8 Mar 2021 16:03:07 +0000

Luc,

About this:

“7.      Section 9.1.2 is not really exposing the problem fully. With the topology provided, the simplest way for PE2 to receive all traffic is to simply disable SMET route and IMET route will pull the multicast traffic.
I think the point this section is trying to make is that SMET must be enabled because of some other router...say PE3... and because of that a *,* needs to be generated.”

I think Figure 2 assumes that PE1 and PE2 are igmp/mld proxy capable, hence an IMET route won’t pull any mcast as per section 8. But I agree with you this can be explicitly mentioned.

Thanks.
Jorge

From: BESS <[email-masked]> on behalf of Luc André Burdet <[email-masked]>
Date: Wednesday, March 3, 2021 at 2:26 PM
To: [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: [bess] draft-ietf-bess-evpn-igmp-mld-proxy-06 review
Hi,

Regards,
Luc André

    Abstract: