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

<zhang.zheng@zte.com.cn> Tue, 28 January 2020 03:22 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 0276B3A0C08; Mon, 27 Jan 2020 19:22:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3EufKRwjMcDq; Mon, 27 Jan 2020 19:21:56 -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 582B23A0C06; Mon, 27 Jan 2020 19:21:51 -0800 (PST)
Received: from mse-fl2.zte.com.cn (unknown [10.30.14.239]) by Forcepoint Email with ESMTPS id 4CF69B66D12A673C2372; Tue, 28 Jan 2020 11:21:49 +0800 (CST)
Received: from njxapp03.zte.com.cn ([10.41.132.202]) by mse-fl2.zte.com.cn with SMTP id 00S3LWQv051126; Tue, 28 Jan 2020 11:21:32 +0800 (GMT-8) (envelope-from zhang.zheng@zte.com.cn)
Received: from mapi (njxapp04[null]) by mapi (Zmail) with MAPI id mid203; Tue, 28 Jan 2020 11:21:32 +0800 (CST)
Date: Tue, 28 Jan 2020 11:21:32 +0800
X-Zmail-TransId: 2afc5e2fa8bccfed364f
X-Mailer: Zmail v1.0
Message-ID: <202001281121323421362@zte.com.cn>
In-Reply-To: <MN2PR05MB5981E5B90EFEDCA92B3DB6F9D40B0@MN2PR05MB5981.namprd05.prod.outlook.com>
References: 202001271636514809757@zte.com.cn, MN2PR05MB5981E5B90EFEDCA92B3DB6F9D40B0@MN2PR05MB5981.namprd05.prod.outlook.com
Mime-Version: 1.0
From: zhang.zheng@zte.com.cn
To: zzhang@juniper.net
Cc: bier@ietf.org, jorge.rabadan@nokia.com, sajassi@cisco.com, prz@juniper.net, bier-chairs@ietf.org
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl2.zte.com.cn 00S3LWQv051126
Archived-At: <https://mailarchive.ietf.org/arch/msg/bier/xZnnnnlckNyuclsxKkCzqsYPlkg>
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: Tue, 28 Jan 2020 03:22:01 -0000

Hi Jeffrey,







Let me make the procedure more clear, please see if I understand right.


The EVPN is used as BIER overlay, the advertisement content is used for BIER payload encapsulation, and the advertisement is among edge routers.


The multicast address is used for BFER to distinguish the payload tunnel type. 


The BFIR should advertise the associated multicast address to indicate the tunnel encapsulation.


From RFC7348, one multicast address can map to one VNI. But we can use one same multicast address for all BDs by configuration or some other ways.


In case the multicast address advertised by different BFIRs are different, the BFERs should distinguish them and execute the packet correctly.


When BFIR do the encapsulation function, the associated IP tunnel with DA set to the multicast address is encapsulated as payload behind BIER header.


When the BIER header of the packet is moved in the router which does the PHP function,


    if there is only one hop between the PHP router and BFER, the inner packet will be sent directly to the BFER. In this situation, the IP tunnel packet with multicast address will be exposed in the BIER core network.


    if there is multihop between the PHP router and BFER, necessary encapsulation will be used in front of the tunnel encapsulation. Because the multicast address can not be routed in the BIER core network.






Do I understand right?






Thanks,


Sandy












原始邮件



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




Hi Sandy,


 


It is an underlay multicast address (It’s like all Rosen MDT tunnels are using the same group address – it works because we’re not using group but using vxlan VNI to demultiplex traffic into different VPNs/BDs).


 


Different PEs advertising different address is still fine – it’s the ingress PE’s own decision - just that egress PEs need to be prepared to accept traffic with multiple addresses.


 


Still, allocating a well-known address is better.


 


Jeffrey


 


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


 

Hi Jeffrey,

 

Thank you very much for your explaining!

I got it. The multicast destination is in the inner packet, like the overlay multicast address, right?

If there are multiple BFERs need to advertise the multicast address as Auxiliary information, 

they may advertise different addresses, then it's hard to encapsulate the inner packet.

A dedicated IP multicast address or some other unified methods are more reasonable. :-)

 

Thanks,

Sandy

 


原始邮件



发件人:Jeffrey(Zhaohui)Zhang <zzhang@juniper.net>



收件人:张征00007940;



抄送人:'bier@ietf.org' <bier@ietf.org>;'jorge.rabadan@nokia.com'
 <jorge.rabadan@nokia.com>;'sajassi@cisco.com' <sajassi@cisco.com>;AntoniPrzygienda <prz@juniper.net>;'bier-chairs@ietf.org' <bier-chairs@ietf.org>;



日期:2020年01月26日
 21:25



主题:RE: [Bier] Comments on draft-ietf-bier-evpn-02




Forgot to say that, if the PH tunnel the packet to an indirectly connected BFER, then there is a tunnel header before the IP/UDP/vxlan header.


 



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




 


Hi Sandy,


 


The PH pop the BIER header and forward the inner packet to the BFER, either natively or over an underlay tunnel depending on whether the BFER is directly connected or not.


 


In case of vxlan, the inner encapsulation (after the popped BIER header) would be vxlan including its IP/UDP header. The IP destination address would be a multicast address advertised
 in the Auxiliary Information. The reason for including IP/UDP header is that in case of PHP, the BFER may not be able to know that incoming header is vxlan w/o IP/UDP (when PHP is not used, the BIER header’s proto field can indicate the inner header type).


 


Having said that, we’re thinking of allocating a dedicated IP multicast address for this purpose, instead of advertising it in the Auxiliary Information.


 


Jeffrey


 


From: BIER <bier-bounces@ietf.org>On
 Behalf Of zhang.zheng@zte.com.cn
Sent: Sunday, January 26, 2020 3:34 AM
To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
Cc: bier@ietf.org; jorge.rabadan@nokia.com;sajassi@cisco.com; Antoni Przygienda <prz@juniper.net>;bier-chairs@ietf.org
Subject: Re: [Bier] Comments on draft-ietf-bier-evpn-02


 

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