Re: [bess] Questions on VLAN-based/VLAN-bundle Service Interface of rfc7432bis

wang.yubao2@zte.com.cn Fri, 26 May 2023 06:16 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 02A7CC151532; Thu, 25 May 2023 23:16:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.898
X-Spam-Level:
X-Spam-Status: No, score=-6.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G_kNHf6bNMVO; Thu, 25 May 2023 23:16:38 -0700 (PDT)
Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.216.63.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 322DFC14CE52; Thu, 25 May 2023 23:16:37 -0700 (PDT)
Received: from mse-fl1.zte.com.cn (unknown [10.5.228.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mxhk.zte.com.cn (FangMail) with ESMTPS id 4QSF755H29z8RTWb; Fri, 26 May 2023 14:16:33 +0800 (CST)
Received: from njb2app05.zte.com.cn ([10.55.22.121]) by mse-fl1.zte.com.cn with SMTP id 34Q6GSdg081639; Fri, 26 May 2023 14:16:28 +0800 (+08) (envelope-from wang.yubao2@zte.com.cn)
Received: from mapi (njb2app05[null]) by mapi (Zmail) with MAPI id mid203; Fri, 26 May 2023 14:16:30 +0800 (CST)
Date: Fri, 26 May 2023 14:16:30 +0800
X-Zmail-TransId: 2afd64704ebeffffffffcdd-49cdf
X-Mailer: Zmail v1.0
Message-ID: <202305261416304022327@zte.com.cn>
In-Reply-To: <SJ0PR11MB577024BA7AFDBB4664176EA3B0469@SJ0PR11MB5770.namprd11.prod.outlook.com>
References: 202305251026103766835@zte.com.cn, SJ0PR11MB577024BA7AFDBB4664176EA3B0469@SJ0PR11MB5770.namprd11.prod.outlook.com
Mime-Version: 1.0
From: wang.yubao2@zte.com.cn
To: sajassi@cisco.com
Cc: draft-ietf-bess-rfc7432bis@ietf.org, bess@ietf.org
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl1.zte.com.cn 34Q6GSdg081639
X-Fangmail-Gw-Spam-Type: 0
X-Fangmail-Anti-Spam-Filtered: true
X-Fangmail-MID-QID: 64704EC1.000/4QSF755H29z8RTWb
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/3NnwNhz2uB1mbVUikpKXGi4gjfo>
Subject: Re: [bess] Questions on VLAN-based/VLAN-bundle Service Interface of rfc7432bis
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.39
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: Fri, 26 May 2023 06:16:40 -0000

Hi Ali,






Thank you for your response.


1)If two VIDs on the same physical interface of an ES are getting mapped to BD1, but the <ES, BD1> is advertised via Eth AD per EVI route with Eth-tag of non-zero, can BD1 still be called as VLAN-bundle service interface? I think it is not VLAN-aware bundle service interface, because these VIDs share the same bridge table. but section 6.2 of rfc7432bis says that the eth-tag of all EVPN routes of VLAN-bundle service interface MUST be set to 0, so I think this is not VLAN-bundle service interface either. Is this use case supported by rfc7432bis?


2)If two VIDs on a physical interface of ES1 is getting mapped to BD1 and two VIDs on a physical interface of ES2 is getting mapped to BD1 and BD2 respectively ,  but both <ES1, BD1> and <ES2, BD1> are advertised via Eth AD per EVI route with Eth-tag of zero. In such case, that EVI (which contains BD1 and BD2) is VLAN-bundle service interface for ES1, but the same EVI is VLAN-aware bundle service interface for ES2. Is my understanding correct? I ask this question because I want to know that whether these "service interface" concepts are talking about an EVI's character or they just talk about <ESI, EVI>'s character.




3)RFC7209 section 7 says that  "[RFC4762] defines two types of VPLS services based on 'unqualified and qualified learning', which in turn maps to port mode and VLAN mode, respectively.". But I also noticed that RFC4761 Section 4.2.6 says that "If the key for learning within a VPLS is just the MAC address, then this VPLS is operating under unqualified learning.  If the key for learning is (customer VLAN tag + MAC address), then this VPLS is operating under qualified learning." 

It seems that the qualified learning of RFC4761 is not VLAN-based service interface, because the key of that VPLS for MAC learning is <C-VLAN, MAC>, which mean that the MAC learning for different C-VLAN is done inside the same VPLS. But in VLAN-based service interface it is not the case. Otherwise, in VLAN-aware bundle service interface the MAC learning for different C-VLAN is done within the same EVI (EVPN VPLS). To me it seems that the qualified learning of RFC4762 is VLAN-based service interface, but the qualified learning of RFC4761 is VLAN-aware bundle service interface. Such understanding appears a little weird to me.  But I don't know what's wrong with it. I noticed that the MAC learning key of RFC4762 is considered to be a "logical key", but the MAC learning key of RFC4761 is ”the key for learing withing a VPLS“. is the latter the actual key of that VPLS other than a logical key?  Are the "qualified learning" of RFC4762 and RFC4761 the same with each other?  






Thanks,


Yubao














原始邮件



发件人:AliSajassi(sajassi)
收件人:王玉保10045807;draft-ietf-bess-rfc7432bis@ietf.org;
抄送人:bess@ietf.org;
日 期 :2023年05月25日 13:02
主 题 :Re: Questions on VLAN-based/VLAN-bundle Service Interface of rfc7432bis  




 


If you are talking about different VLAN IDs (VIDs) on the same physical interface of an ES is getting mapped to a BD, and the <ES, BD> is advertised via Eth AD per EVI route with Eth-tag of zero, then this is VLAN-bundle service interface. In VLAN bundle, it is assumed that the MAC addresses across different VIDs are unique and thus they all can be placed in a single BD!  


 


Cheers,


Ali


 



From: wang.yubao2@zte.com.cn <wang.yubao2@zte.com.cn>
 Date: Wednesday, May 24, 2023 at 7:26 PM
 To: draft-ietf-bess-rfc7432bis@ietf.org <draft-ietf-bess-rfc7432bis@ietf.org>
 Cc: bess@ietf.org <bess@ietf.org>
 Subject: Questions on VLAN-based/VLAN-bundle Service Interface of rfc7432bis  


 

Hi All,

 

I have encountered a use case that I don't know if it's VLAN-based service interface or VLAN-bundle service interface.

When two individual subinterfaces on the same ES are attached to the same BD which is the only one BD (whose Ethernet Tag ID is zero) of its EVI, which Service Interface should the EVI be called? VLAN-based service interface or VLAN-bundle service interface or none of those three service itnerfaces?

I noticed that there is just a single A-D per EVI route for that <ES, BD>, thus these two ACs have to share the same A-D per EVI route in such case. So if one of them fails but the other is OK, should that A-D per EVI route be withdrawn or not?

When these two interfaces are merged into a single subinterface, I know there is no doubt that this is VLAN-bundle service interface. But here each VLAN has its individual interface.

Whether this use case is supported by rfc7432bis? If it is supported, should it be called VLAN-based service interface or VLAN-bundle service interface?

 

Thanks,

Yubao