Re: [Bier] Comments on draft-ietf-bier-evpn-02

<zhang.zheng@zte.com.cn> Sun, 26 January 2020 08:34 UTC

Return-Path: <zhang.zheng@zte.com.cn>
X-Original-To: bier@ietfa.amsl.com
Delivered-To: bier@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23F3D12009C; Sun, 26 Jan 2020 00:34:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
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 AWyE_zqYTYBB; Sun, 26 Jan 2020 00:34:16 -0800 (PST)
Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.217.80.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE53E12008F; Sun, 26 Jan 2020 00:34:14 -0800 (PST)
Received: from mxct.zte.com.cn (unknown [192.168.164.217]) by Forcepoint Email with ESMTPS id 423C56B7ADA5C2EAFCCE; Sun, 26 Jan 2020 16:34:12 +0800 (CST)
Received: from mse-fl1.zte.com.cn (unknown [10.30.14.238]) by Forcepoint Email with ESMTPS id F17532711A75F39C0A15; Sun, 26 Jan 2020 16:34:11 +0800 (CST)
Received: from njxapp01.zte.com.cn ([10.41.132.200]) by mse-fl1.zte.com.cn with SMTP id 00Q8XtOo056346; Sun, 26 Jan 2020 16:33:55 +0800 (GMT-8) (envelope-from zhang.zheng@zte.com.cn)
Received: from mapi (njxapp04[null]) by mapi (Zmail) with MAPI id mid203; Sun, 26 Jan 2020 16:33:55 +0800 (CST)
Date: Sun, 26 Jan 2020 16:33:55 +0800
X-Zmail-TransId: 2afc5e2d4ef3956ec48c
X-Mailer: Zmail v1.0
Message-ID: <202001261633556978132@zte.com.cn>
In-Reply-To: <MN2PR05MB598114944D6109A19DE63CA7D4090@MN2PR05MB5981.namprd05.prod.outlook.com>
References: 202001061133287394813@zte.com.cn, MN2PR05MB598114944D6109A19DE63CA7D4090@MN2PR05MB5981.namprd05.prod.outlook.com
Mime-Version: 1.0
From: zhang.zheng@zte.com.cn
To: zzhang@juniper.net
Cc: prz@juniper.net, sajassi@cisco.com, jorge.rabadan@nokia.com, bier-chairs@ietf.org, bier@ietf.org
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl1.zte.com.cn 00Q8XtOo056346
Archived-At: <https://mailarchive.ietf.org/arch/msg/bier/qjacJn-UDtGsC5_epzs6BGykxBE>
Subject: Re: [Bier] Comments on draft-ietf-bier-evpn-02
X-BeenThere: bier@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "\"Bit Indexed Explicit Replication discussion list\"" <bier.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bier>, <mailto:bier-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bier/>
List-Post: <mailto:bier@ietf.org>
List-Help: <mailto:bier-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bier>, <mailto:bier-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 26 Jan 2020 08:34:19 -0000

Hi Jeffrey,






Thank you for your respond!






I may misunderstand about the procedure. 


Is the multicast known to all PEs overlay?


Is the tunnel between PH router and BFER built in core network? 


If there is only one hop between PH router and BFER, and the tunnel is bound to a VPN, then the BFER can decapsulate the packet and forward it correctly.


But if there are multiple hops between PH router and BFER, does the router between PH router and BFER forward the packet correctly according to the multicast address in the tunnel encapsulation? 






Thanks,


Sandy












原始邮件



发件人:Jeffrey(Zhaohui)Zhang <zzhang@juniper.net>
收件人:张征00007940;Antoni Przygienda <prz@juniper.net>;sajassi@cisco.com <sajassi@cisco.com>;jorge.rabadan@nokia.com <jorge.rabadan@nokia.com>;
抄送人:bier-chairs@ietf.org <bier-chairs@ietf.org>;bier@ietf.org <bier@ietf.org>;
日 期 :2020年01月26日 03:07
主 题 :RE: [Bier] Comments on draft-ietf-bier-evpn-02




Hi Sandy,


 


Sorry for the late response.


It’s not the PH router that gets a multicast address used to send traffic to the PE. The ingress PE must already use a multicast address known to all PEs.


 


Jeffrey


 


From: zhang.zheng@zte.com.cn <zhang.zheng@zte.com.cn>
Sent: Sunday, January 5, 2020 10:33 PM
To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>; Antoni Przygienda <prz@juniper.net>; sajassi@cisco.com; jorge.rabadan@nokia.com
Cc: bier-chairs@ietf.org; bier@ietf.org
Subject: [Bier] Comments on draft-ietf-bier-evpn-02


 

Hi authors,

 

Happy New Year!

 

I am reading the "draft-ietf-bier-evpn-02" draft. I have a question on section 2.1 in "draft-ietf-bier-evpn-02", there is the description: The tunnel endpoint MUST be an IP multicast address and the receiving egress PE MUST be set up to receive and process
 packets addressed to the address.

 

The IP multicast address can simplify the forwarding procedure on PHP routers. But I am wondering how the PHP routers will do when it's hard to get a consistent multicast address among the BFERs which can not support BIER forwarding. 

And if unicast tunnel can be used here too?

 

Thanks,

Sandy