Re: [bess] Comments on "draft-sajassi-bess-evpn-igmp-mld-proxy-00"

Haoweiguo <haoweiguo@huawei.com> Thu, 05 November 2015 05:54 UTC

Return-Path: <haoweiguo@huawei.com>
X-Original-To: bess@ietfa.amsl.com
Delivered-To: bess@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 055CE1B3A18 for <bess@ietfa.amsl.com>; Wed, 4 Nov 2015 21:54:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fAaNNj6e1T3h for <bess@ietfa.amsl.com>; Wed, 4 Nov 2015 21:54:28 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBF051B3A1B for <bess@ietf.org>; Wed, 4 Nov 2015 21:54:27 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CDR53012; Thu, 05 Nov 2015 05:54:24 +0000 (GMT)
Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 5 Nov 2015 05:54:17 +0000
Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.75]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0235.001; Thu, 5 Nov 2015 13:54:09 +0800
From: Haoweiguo <haoweiguo@huawei.com>
To: "Ali Sajassi (sajassi)" <sajassi@cisco.com>
Thread-Topic: Comments on "draft-sajassi-bess-evpn-igmp-mld-proxy-00"
Thread-Index: AdEMpjj259K5iE8ETHms059lGH4czQLOR7qA//9Y6hU=
Date: Thu, 05 Nov 2015 05:54:09 +0000
Message-ID: <DD5FC8DE455C3348B94340C0AB5517334F8D61EA@nkgeml501-mbs.china.huawei.com>
References: <DD5FC8DE455C3348B94340C0AB5517334F8D2D28@nkgeml501-mbs.china.huawei.com>, <D260ED5D.15F560%sajassi@cisco.com>
In-Reply-To: <D260ED5D.15F560%sajassi@cisco.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.194.185.251]
Content-Type: multipart/alternative; boundary="_000_DD5FC8DE455C3348B94340C0AB5517334F8D61EAnkgeml501mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.563AEF12.004A, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.75, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 02f3d49b0f7eccda03ba7b1836e576e0
Archived-At: <http://mailarchive.ietf.org/arch/msg/bess/RkOUC7CjvUwX5b3T0tVKog4Ibm0>
Cc: "bess@ietf.org" <bess@ietf.org>
Subject: Re: [bess] Comments on "draft-sajassi-bess-evpn-igmp-mld-proxy-00"
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.15
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: Thu, 05 Nov 2015 05:54:31 -0000

Hi Ali,

Thanks for your reply. I think the 'distributd anycast multicast router' may not satisfy my requirements. In my discriptions, one multicast router is attached behind a EVPN PE or the multicast router also acts as an EVPN PE at the same time,  the multicat router is centralized deployed. In this scenario, one bit Flag as multicast router indicator is needed. The PE acting as multicast router or with multicast router behind should announce the route type 6 message with the indicator flag marked. When other PEs with multicast source behind receives the message,  when they inject local multicast traffic to EVPN network, they will always send the traffic to the multicast router PE, the multicast traffic will never be pruned. If no this Flag, if the multicast router PE has no local IGMP/MLG receivers, the multicast traffic from other PEs will never come to the multicast router PE.


I think your whole solution is good, it's easy to add this multicast router Flag bit in route type-6 TLV.

Thanks,
weiguo
________________________________
From: Ali Sajassi (sajassi) [sajassi@cisco.com]
Sent: Thursday, November 05, 2015 10:33
To: Haoweiguo
Cc: bess@ietf.org
Subject: Re: Comments on "draft-sajassi-bess-evpn-igmp-mld-proxy-00"


Hi Weiguo,


From: Haoweiguo <haoweiguo@huawei.com<mailto:haoweiguo@huawei.com>>
Date: Thursday, October 22, 2015 at 2:17 AM
To: Cisco Employee <sajassi@cisco.com<mailto:sajassi@cisco.com>>
Cc: "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
Subject: Comments on "draft-sajassi-bess-evpn-igmp-mld-proxy-00"


Hi Ali,

I have read through the draft, i think the procedures is fine for IGMP/MLD proxy. However, this draft doesn't consider multicast router scenario, better to be added.

Scenario 1:

         An EVPN PE acts as multicast router and runs PIM protocol with the outside multicast routers.

Scenario 2:

         An EVPN PE connects to a multicast router on port1, no IGMP receiver on the port.  The PE sends IGMP/MLD to the multicast router.



We have covered both scenarios. The first one is referred to as “distributed anycast router"


In both scenarios, the EVPN PE should announce its role through the extended route type6 to indicate it connects to a multicast router or acts as multicast router itself.

Other EVPN PEs having local multicast source should forward the multicast traffic to the PE announcing multicast router role, the PE announcing multicast router role should not be pruned for all multicast traffic.

For the PE connecting to a multicast router, it should translate  EVPN route type-6 message to IGMP/MLD message, it's already described in your draft. For the PE acting as multicast router, it should translate EVPN route type-6 message to PIM protocol, this part has not been covered in your draft, better to be added.

Correct, the mcast traffic treatment for inter-subnet is not described yet but we’ll mention it in the next rev.

Cheers,
Ali



Thanks,

weiguo