Thanks Luc for your comment. I would wait for Stephanes comment as well and 
address it all together.

Mankamana

From: BESS <bess-boun...@ietf.org> on behalf of "Rabadan, Jorge (Nokia - 
US/Mountain View)" <jorge.raba...@nokia.com>
Date: Monday, March 8, 2021 at 8:04 AM
To: Luc André Burdet <laburdet.i...@gmail.com>, 
"draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org" 
<draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org>
Cc: "bess@ietf.org" <bess@ietf.org>
Subject: Re: [bess] draft-ietf-bess-evpn-igmp-mld-proxy-06 review

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 <bess-boun...@ietf.org> on behalf of Luc André Burdet 
<laburdet.i...@gmail.com>
Date: Wednesday, March 3, 2021 at 2:26 PM
To: draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org 
<draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org>
Cc: bess@ietf.org <bess@ietf.org>
Subject: [bess] draft-ietf-bess-evpn-igmp-mld-proxy-06 review
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  |  laburdet.i...@gmail.com  |  Tel: +1 613 254 4814




On 2021-01-25, 16:55, "BESS on behalf of internet-dra...@ietf.org" 
<bess-boun...@ietf.org on behalf of internet-dra...@ietf.org> 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
    BESS@ietf.org
    https://www.ietf.org/mailman/listinfo/bess

_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Reply via email to