[bess] [BESS] Conflicting rules among the Yang models on the association between IRB/AC interface and IP-VRF/MAC-VRF instance.

<wang.yubao2@zte.com.cn> Tue, 23 April 2019 03:52 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 2533B1200C3 for <bess@ietfa.amsl.com>; Mon, 22 Apr 2019 20:52:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 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] 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 XaL2vhVyxQY7 for <bess@ietfa.amsl.com>; Mon, 22 Apr 2019 20:52:35 -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 799351202F1 for <bess@ietf.org>; Mon, 22 Apr 2019 20:52:34 -0700 (PDT)
Received: from mse-fl2.zte.com.cn (unknown [10.30.14.239]) by Forcepoint Email with ESMTPS id E4193BAFEA41F793C92F for <bess@ietf.org>; Tue, 23 Apr 2019 11:52:32 +0800 (CST)
Received: from njxapp04.zte.com.cn ([10.41.132.203]) by mse-fl2.zte.com.cn with SMTP id x3N3qPnn094640 for <bess@ietf.org>; Tue, 23 Apr 2019 11:52:25 +0800 (GMT-8) (envelope-from wang.yubao2@zte.com.cn)
Received: from mapi (njxapp02[null]) by mapi (Zmail) with MAPI id mid203; Tue, 23 Apr 2019 11:52:25 +0800 (CST)
Date: Tue, 23 Apr 2019 11:52:25 +0800
X-Zmail-TransId: 2afa5cbe8bf944a42d77
X-Mailer: Zmail v1.0
Message-ID: <201904231152255772005@zte.com.cn>
Mime-Version: 1.0
From: wang.yubao2@zte.com.cn
To: bess@ietf.org
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl2.zte.com.cn x3N3qPnn094640
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/uZIHoy_AD3na9EvbySey7DoWkIY>
Subject: [bess] [BESS] Conflicting rules among the Yang models on the association between IRB/AC interface and IP-VRF/MAC-VRF instance.
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, 23 Apr 2019 03:52:38 -0000

Hi all,






I find some conflicting rules about interface-to-VRF binding between draft-ietf-rtgwg-ni-model-12 and draft-ietf-bess-l2vpn-yang-09.txt.


It is as below:






RULE1: [NI-model] Section 3.2 says that:

The bind-network-instance-name leaf provides the association between an

   interface and its associated NI (e.g., VRF or VSI). 


RULE2: [draft-ietf-bess-evpn-yang-06] Section 3.3 says that:


     augment 

     /ni:network-instances/ni:network-instance/ni:ni-type/l2vpn:l2vpn:

       +--rw evpn-instance?   evpn-instance-ref


and [draft-ietf-bess-l2vpn-yang-09.txt] Section 3.6.3 says that:

   Each entry in the endpoint list, may hold AC, PW or redundancy-grp

   references.  The core aspect of endpoint container is its flexible

   personality based on what user decides to include in it.  It is

   future-proofed with possible extensions that can be included in the

   endpoint container such as Integrated Route Bridging (IRB), PW

   Headend, Virtual Switch Instance, etc.






According to the RULE1, The bind-network-instance-name leaf provides the association between an interface and its associated MAC-VRF or IP-VRF.


According to the RULE2, IRB/AC interface is associated to it's EVPN MAC-VRF via the "end-point" entry.






So I have the follow two questions:


Question 1: How should I bind an AC to it's EVPN MAC-VRF according to these drafts? 


Question 2: How should I bind an IRB interface to it's EVPN MAC-VRF and EVPN IP-VRF according to these drafts?






For Question 1, my understanding is as below:


I should follow the RULE2 to bind an AC to it's associated EVPN MAC-VRF.


The RULE1 doesn't work for L2VPN ACs,


because if the RULE1 is applied to the association between AC and its associated MAC-VRF, 


It should be applied to the association between IRB interface and its associated MAC-VRF too.


But obviously the RULE1 should be applied to the association between IRB interface and its associated IP-VRF.






Consequently, for Question 2, my understanding is as below:


I should follow the RULE1 to bind an IRB to it's associated EVPN IP-VRF.


I should follow the RULE2 to bind an IRB to it's associated EVPN MAC-VRF.






Is my understanding correct?






Best Regards


Bob