[bess] draft-ietf-bess-evpn-igmp-mld-proxy-03 shepherd's review

<stephane.litkowski@orange.com> Tue, 20 August 2019 13:19 UTC

Return-Path: <stephane.litkowski@orange.com>
X-Original-To: bess@ietfa.amsl.com
Delivered-To: bess@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 8C903120114; Tue, 20 Aug 2019 06:19:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 3SHM8fTRbSyZ; Tue, 20 Aug 2019 06:19:49 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BAE3120124; Tue, 20 Aug 2019 06:19:46 -0700 (PDT)
Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id 46CWc026HBzCrXF; Tue, 20 Aug 2019 15:19:44 +0200 (CEST)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.89]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 46CWc01ffYz8sYT; Tue, 20 Aug 2019 15:19:44 +0200 (CEST)
Received: from OPEXCAUBMA3.corporate.adroot.infra.ftgroup ([fe80::90fe:7dc1:fb15:a02b]) by OPEXCAUBM44.corporate.adroot.infra.ftgroup ([fe80::e8a4:8bb:d7c2:f4e2%21]) with mapi id 14.03.0468.000; Tue, 20 Aug 2019 15:19:44 +0200
From: <stephane.litkowski@orange.com>
To: "draft-ietf-bess-evpn-igmp-mld-proxy@ietf.org" <draft-ietf-bess-evpn-igmp-mld-proxy@ietf.org>, "bess@ietf.org" <bess@ietf.org>
Thread-Topic: draft-ietf-bess-evpn-igmp-mld-proxy-03 shepherd's review
Thread-Index: AdVWf+zzJqWdWA2ITZ+gOHU7ZAlfaA==
Date: Tue, 20 Aug 2019 13:19:43 +0000
Message-ID: <13342_1566307184_5D5BF370_13342_91_1_9E32478DFA9976438E7A22F69B08FF924D9EE11F@OPEXCAUBMA3.corporate.adroot.infra.ftgroup>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
x-originating-ip: []
Content-Type: multipart/related; boundary="_004_9E32478DFA9976438E7A22F69B08FF924D9EE11FOPEXCAUBMA3corp_"; type="multipart/alternative"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/XEfCyE8e1HPL2em8cGPxdkMBwW8>
Subject: [bess] draft-ietf-bess-evpn-igmp-mld-proxy-03 shepherd's review
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bess>, <mailto:bess-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess/>
List-Post: <mailto:bess@ietf.org>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bess>, <mailto:bess-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Aug 2019 13:19:51 -0000


There are some Nits to fix:

Here is my review of the document:

Abstract & Intro:
s/RFC 7432/ RFC7432.
The reference should be removed from the abstract (as per IDNits).

It may be good to change the paragraph name to IGMP/MLD proxy and use IGMP/MLD in the paragraph. This comment could apply to various other places of the document.


        -"it only sends a single BGP
   message corresponding to the very first IGMP Join".
[SLI] Do we really care about the IGMP message (first or second...) used as a source to build the EVPN route ? The important point is that we do it only one time.

-          For MLD what is the expected behavior in term of flag setting in the SMET, do we set v2 for MLDv2 or do we consider that it is equivalent to IGMPv3 and then we set v3 ?

-          s/BGP is a statefull/BGP is a stateful  ?

-          In 1),  for clarity purpose, it would be good to separate the (*,G) and (S,G) case in two separate paragraphs. At the first read, when reading "In case of IGMPv3, exclude flag...", I thought it was always applicable for IGMPv3 which does not make sense, while it is applicable only "If the IGMP Join is for (*,G)".

-          IMO, 1) 2) 3) and 4) should use normative language

-          Wouldn't it be better to present the encoding of SMET before ? Because the text talks about fields set in the route while it hasn't been presented yet.

-          5) talks about errors that SHOULD be logged, but from a BGP perspective, is it considered as a BGP error ? What is the expected behavior per RFC7606 ?

-          7) is not clear about IGMPv3, the first part of the text tells that the IGMP Join must not be sent if there is no PIM router. While the end of the text tells that it is not a problem for IGMPv3. So is there a difference between IGMPv2 and IGMPv3 reports ?

-          You have a paragraph numbering issue "IGMP Leave Group Advertisement in BGP" should be 2.1.2

-          As for §2.1.1, normative language should be used

-          2) I agree that there is an error when a SMET is received with all version flags unset. How does the receiver handle this ? does it consider the NLRI has withdrawn per RFC7606 from a BGP perspective ? Does it the the current state of the route and ignore the update ? Does it close the session ?

-          2) "If the PE receives an EVPN SMET route withdraw, then it must
   remove the remote PE from the OIF list associated with that multicast
   group." This text is a duplicate on 3).

s/each PE need to have/each PE MUST have/ ?

s/support IGMP sync procedures/support IGMP synchronization procedures/

s/The IGMP Join Sync route carries the ES-Import RT/ The IGMP Join Sync route MUST carry the ES-Import RT/

Again, the paragraph lacks of normative language

s/procedure section(4.1)/the procedure defined in section 4.1/
s/Remote PE (PE/Remote PEs (PEs/

Need to use normative language

The paragraph uses IGMP Join Sync Route or Leave Sync route while §7 uses Multicast Join Synch Route. Please ensure consistency. This applies to other sections of the document.

Please expand "IR" in the title and add it into the acronyms section.

"all of the PEs in the BD support that tunnel type and IGMP", do you mean IGMP proxy ?

§7.1 brings some clarification about MLD usage which wasn't clear in section 2.
However §2 is still confusing in version numbers between IGMP and MLD. As an example, a SMET with a source must not exist with IGMPv2/1 while it must not with MLDv1 only.


"Support for this route type is
   optional.". With regards to RFC7432, yes. However if an implementation supports this draft, the support of the NLRI is mandatory.

Typo is the title: s/Multicas/Multicast/

s/it Must set the IGMP Proxy/it MUST set the IGMP/MLD Proxy/
Could we have some device that support IGMP proxy but not MLD proxy ?


Does it change something to IGMP/MLD security ? Maybe this should be mentioned as well

I think that IGMP and MLD RFCs should be set as normative. You should add MLDv1, IGMPv2, IGMPv1 as references as well and use the references in the text.

RFC7387 and 7623 are referenced but not used


RFC7606 and 4684 should be set as normative


[Orange logo]<http://www.orange.com/>

Stephane Litkowski
Network Architect
Orange Expert Future Networks
phone: +33 2 23 06 49 83 <https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%202%2023%2028%2049%2083%20>  NEW !
mobile: +33 6 71 63 27 50 <https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%206%2037%2086%2097%2052%20>  NEW !


Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.