[bess] An use-case that RFC 8584 (EVPN DF Framework)  works not so well and its solution .

<wang.yubao2@zte.com.cn> Tue, 30 April 2019 03:02 UTC

Return-Path: <wang.yubao2@zte.com.cn>
X-Original-To: bess@ietfa.amsl.com
Delivered-To: bess@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0422712025D for <bess@ietfa.amsl.com>; Mon, 29 Apr 2019 20:02:22 -0700 (PDT)
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_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 5HymLITIfULI for <bess@ietfa.amsl.com>; Mon, 29 Apr 2019 20:02:19 -0700 (PDT)
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 0D8DF12024F for <bess@ietf.org>; Mon, 29 Apr 2019 20:02:18 -0700 (PDT)
Received: from mxct.zte.com.cn (unknown [192.168.164.215]) by Forcepoint Email with ESMTPS id 7847D8B95C1AD5AB612F for <bess@ietf.org>; Tue, 30 Apr 2019 11:02:17 +0800 (CST)
Received: from mse-fl2.zte.com.cn (unknown [10.30.14.239]) by Forcepoint Email with ESMTPS id 66A95E64FE4BB2481C65; Tue, 30 Apr 2019 11:02:17 +0800 (CST)
Received: from njxapp05.zte.com.cn ([10.41.132.204]) by mse-fl2.zte.com.cn with SMTP id x3U32CYO011358; Tue, 30 Apr 2019 11:02:12 +0800 (GMT-8) (envelope-from wang.yubao2@zte.com.cn)
Received: from mapi (njxapp02[null]) by mapi (Zmail) with MAPI id mid203; Tue, 30 Apr 2019 11:02:12 +0800 (CST)
Date: Tue, 30 Apr 2019 11:02:12 +0800
X-Zmail-TransId: 2afa5cc7bab4d422c221
X-Mailer: Zmail v1.0
Message-ID: <201904301102120783046@zte.com.cn>
Mime-Version: 1.0
From: wang.yubao2@zte.com.cn
To: bess@ietf.org
Cc: jorge.rabadan@nokia.com
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl2.zte.com.cn x3U32CYO011358
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/GzLj-eltxQe_I6SBgNCZXb43ioo>
Subject: [bess] An use-case that RFC 8584 (EVPN DF Framework)  works not so well and its solution .
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, 30 Apr 2019 03:02:22 -0000

Hi everyone,






I reviewed the draft-09 of RFC 8584 a few days ago, and found that the DF Election FSM can't work well after the ES goes UP for the second time.


I described it in detail in this mail: https://mailarchive.ietf.org/arch/msg/bess/9fK2HHdish3b5Hosa5ZU4NKwX7o


And I think the issue remained in RFC 8584 unchanged. 


So I described the use-case more clearly here so that we can check that whether it is a misunderstanding or it is worth updating.  





0) the ES goes up on PE1 for the first time while the same ES has been DF_DONE on PE2/PE3 for a long time, the DF FSM per RFC8584 works well.
1)the ES goes down later, but the PE1 node itself still works well. Because the failure only occurs on the ES interface. 
2)so the remote routes(assumed that they are from PE2 and PE3) for the same ES need not to be collected again.  
3)the ES goes up again, PE1 advertises the ES route immediately after the ES_UP event. 
4)So PE1 makes PE2 and PE3 to re-elect a new DF for VLAN x immediately after its ES_UP event, and the new DF may be PE1 itself.  
5)But PE1 doesn't take itself as the new DF of VLAN x untill the DF_TIMER. so the VLAN x doesn't have a DF untill the DF_TIMER event.

I think the PE1 has to advertise the ES route on the DF_TIMER event from the moment of the second ES_UP on. 
And I think it is better for PE1 to advertise the ES route on the DF_TIMER event even for the first ES_UP.
Because since PE1 don't intend to take a DF responsibility in the collecting time, it is technically not necessary for it to make other PEs select itself as the DF.
So I suggest that the ES route should be advertised on the DF_TIMER event, not the ES_UP event. 

I think both RFC7432 and RFC8584 may need an update on the above use case.
I think the original use case for RFC7432/RFC8584's DF_WAIT state may be that all the adjacent PEs for an specified ESI are restarted on the same time.
In the original use case the ES routes should be advertised immediately after the ES_UP event because the collecting will not happen untill they advertise ES routes to each other.
But I think in the original use case the PEs technically can't be restarted on the exact same time,
and the interval among their restarting time may be more bigger than the transmission time of the ES route.
Note that the original use case will not happen so frequently than my above use case. 
So I think it is not quite fair to focus on the original use case and ignore the above use case. 

How do you think about the above use case and the solution? 




Best Regards,


Bob





On Wed, 24 Apr 2019 21:12:29 -0700 (PDT)

rfc-editor@rfc-editor.org wrote:




> A new Request for Comments is now available in online RFC libraries.

> 

>         

>         RFC 8584

> 

>         Title:      Framework for Ethernet VPN Designated 

>                     Forwarder Election Extensibility 

>         Author:     J. Rabadan, Ed.,

>                     S. Mohanty, Ed.,

>                     A. Sajassi, 

>                     J. Drake,

>                     K. Nagaraj, 

>                     S. Sathappan

>         Status:     Standards Track

>         Stream:     IETF

>         Date:       April 2019

>         Mailbox:    jorge.rabadan@nokia.com, 

>                     satyamoh@cisco.com, 

>                     sajassi@cisco.com,  

>                     jdrake@juniper.net, 

>                     kiran.nagaraj@nokia.com,  

>                     senthil.sathappan@nokia.com

>         Pages:      32

>         Characters: 69774

>         Updates:    RFC 7432

> 

>         I-D Tag:    draft-ietf-bess-evpn-df-election-framework-09.txt

> 

>         URL:        https://www.rfc-editor.org/info/rfc8584

> 

>         DOI:        10.17487/RFC8584

> 

> An alternative to the default Designated Forwarder (DF) selection

> algorithm in Ethernet VPNs (EVPNs) is defined.  The DF is the

> Provider Edge (PE) router responsible for sending Broadcast, Unknown

> Unicast, and Multicast (BUM) traffic to a multihomed Customer Edge

> (CE) device on a given VLAN on a particular Ethernet Segment (ES).

> In addition, the ability to influence the DF election result for a

> VLAN based on the state of the associated Attachment Circuit (AC) is

> specified.  This document clarifies the DF election Finite State

> Machine in EVPN services.  Therefore, it updates the EVPN

> specification (RFC 7432).

> 

> This document is a product of the BGP Enabled Services Working Group of the IETF.

> 

> This is now a Proposed Standard.

> 

> STANDARDS TRACK: This document specifies an Internet Standards Track

> protocol for the Internet community, and requests discussion and suggestions

> for improvements.  Please refer to the current edition of the Official

> Internet Protocol Standards (https://www.rfc-editor.org/standards) for the 

> standardization state and status of this protocol.  Distribution of this 

> memo is unlimited.

> 

> This announcement is sent to the IETF-Announce and rfc-dist lists.

> To subscribe or unsubscribe, see

>   https://www.ietf.org/mailman/listinfo/ietf-announce

>   https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

> 

> For searching the RFC series, see https://www.rfc-editor.org/search

> For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

> 

> Requests for special distribution should be addressed to either the

> author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless

> specifically noted otherwise on the RFC itself, all RFCs are for

> unlimited distribution.

> 

> 

> The RFC Editor Team

> Association Management Solutions, LLC

> 

> 

> 

>