Re: [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> Wed, 24 April 2019 03:58 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 0D63B12068F for <bess@ietfa.amsl.com>; Tue, 23 Apr 2019 20:58:12 -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 Dr53TpQRk-dH for <bess@ietfa.amsl.com>; Tue, 23 Apr 2019 20:58:08 -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 EFDD312068D for <bess@ietf.org>; Tue, 23 Apr 2019 20:58:07 -0700 (PDT)
Received: from mxct.zte.com.cn (unknown [192.168.164.215]) by Forcepoint Email with ESMTPS id D348ABD8E23B6A10D6EA for <bess@ietf.org>; Wed, 24 Apr 2019 11:58:05 +0800 (CST)
Received: from mse-fl1.zte.com.cn (unknown [10.30.14.238]) by Forcepoint Email with ESMTPS id B5B11292CF53AE4FEFF3; Wed, 24 Apr 2019 11:58:05 +0800 (CST)
Received: from njxapp04.zte.com.cn ([10.41.132.203]) by mse-fl1.zte.com.cn with SMTP id x3O3vwug052652; Wed, 24 Apr 2019 11:57:58 +0800 (GMT-8) (envelope-from wang.yubao2@zte.com.cn)
Received: from mapi (njxapp02[null]) by mapi (Zmail) with MAPI id mid203; Wed, 24 Apr 2019 11:57:58 +0800 (CST)
Date: Wed, 24 Apr 2019 11:57:58 +0800 (CST)
X-Zmail-TransId: 2afa5cbfdec612be95b5
X-Mailer: Zmail v1.0
Message-ID: <201904241157584366349@zte.com.cn>
In-Reply-To: <D0B00227-104F-42C4-A7AB-F9A9DDC92BC4@cisco.com>
References: 201904231051218669595@zte.com.cn, D0B00227-104F-42C4-A7AB-F9A9DDC92BC4@cisco.com
Mime-Version: 1.0
From: <wang.yubao2@zte.com.cn>
To: <bess@ietf.org>, <acee@cisco.com>
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl1.zte.com.cn x3O3vwug052652
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/v7UV-id7_0BclxO0-Qm-I5RGVrU>
Subject: Re: [bess] =?utf-8?q?=5BBESS=5D_Conflicting_rules_among_the_Yang_mod?= =?utf-8?q?els_on_the_association_between_IRB/AC_interface_and_IP-VRF/MAC-?= =?utf-8?q?VRF_instance=2E?=
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: Wed, 24 Apr 2019 03:58:12 -0000

Hi all,






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


Thanks Acee for reminding me to check the changes in the new version of these documents.


And I update the original mail as below after the checking:    






RULE1: [RFC8529] 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-07] 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














The Oringinal Mail



发件人:AceeLindem(acee) <acee@cisco.com>
收件人:wang.yubao2@zte.com.cn;bess@ietf.org <bess@ietf.org>;hshah@ciena.com <hshah@ciena.com>;Patrice Brissette(pbrisset) <pbrisset@cisco.com>;ichen.ietf@outlook.com <ichen.ietf@outlook.com>;ihussain@infinera.com <ihussain@infinera.com>;kishoret@juniper.net <kishoret@juniper.net>;lberger@labn.net <lberger@labn.net>;chopps@chopps.org <chopps@chopps.org>;ivandean@gmail.com <ivandean@gmail.com>;xufeng_liu@jabil.com <xufeng_liu@jabil.com>;ing-wher_chen@jabil.com <ing-wher_chen@jabil.com>;jorge.rabadan@nokia.com <jorge.rabadan@nokia.com>;Ali Sajassi (sajassi) <sajassi@cisco.com>om>;
日 期 :2019年04月23日 23:53
主 题 :Re: [BESS] Conflicting rules among the Yang models on the associationbetween IRB/AC interface and IP-VRF/MAC-VRF instance.




Bob,


 



From: "wang.yubao2@zte.com.cn" <wang.yubao2@zte.com.cn>
 Date: Monday, April 22, 2019 at 10:52 PM
 To: "bess@ietf.org" <bess@ietf.org>rg>, "hshah@ciena.com" <hshah@ciena.com>om>, "Patrice Brissette (pbrisset)" <pbrisset@cisco.com>om>, "ichen.ietf@outlook.com" <ichen.ietf@outlook.com>om>, Iftekhar Hussain <ihussain@infinera.com>om>, "kishoret@juniper.net" <kishoret@juniper.net>et>,  "lberger@labn.net" <lberger@labn.net>et>, Christian Hopps <chopps@chopps.org>rg>, Acee Lindem <acee@cisco.com>om>, Dean Bogdanovic <ivandean@gmail.com>om>, "xufeng_liu@jabil.com" <xufeng_liu@jabil.com>om>, Helen Chen <ing-wher_chen@jabil.com>om>, "Rabadan, Jorge (Nokia - US)"  <jorge.rabadan@nokia.com>om>, "Ali Sajassi (sajassi)" <sajassi@cisco.com>
 Subject: [BESS] Conflicting rules among the Yang models on the association between IRB/AC interface and IP-VRF/MAC-VRF instance.



 


 


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.

 

Not that the NI model has been published as RFC 8529.

Thanks,

Acee

 

 


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