Re: [bess] Questions on draft-sajassi-bess-evpn-ip-aliasing-03

wang.yubao2@zte.com.cn Wed, 10 November 2021 02:55 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 49AE73A101A for <bess@ietfa.amsl.com>; Tue, 9 Nov 2021 18:55:24 -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_FONT_FACE_BAD=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-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 ym1t5pwrRNY0 for <bess@ietfa.amsl.com>; Tue, 9 Nov 2021 18:55:19 -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 057643A1019 for <bess@ietf.org>; Tue, 9 Nov 2021 18:55:18 -0800 (PST)
Received: from mxct.zte.com.cn (unknown [192.168.164.215]) by Forcepoint Email with ESMTPS id D8FDEA9A2AB7E8949107 for <bess@ietf.org>; Wed, 10 Nov 2021 10:55:14 +0800 (CST)
Received: from mse-fl2.zte.com.cn (unknown [10.30.14.239]) by Forcepoint Email with ESMTPS id C05D7F786E331FE7F59E; Wed, 10 Nov 2021 10:55:14 +0800 (CST)
Received: from njxapp03.zte.com.cn ([10.41.132.202]) by mse-fl2.zte.com.cn with SMTP id 1AA2t5ND073617; Wed, 10 Nov 2021 10:55:05 +0800 (GMT-8) (envelope-from wang.yubao2@zte.com.cn)
Received: from mapi (njxapp05[null]) by mapi (Zmail) with MAPI id mid203; Wed, 10 Nov 2021 10:55:05 +0800 (CST)
Date: Wed, 10 Nov 2021 10:55:05 +0800
X-Zmail-TransId: 2afd618b3489de5560c9
X-Mailer: Zmail v1.0
Message-ID: <202111101055055319566@zte.com.cn>
In-Reply-To: <BY3PR08MB70603039D33112EA0E123A46F7929@BY3PR08MB7060.namprd08.prod.outlook.com>
References: 202111091605433823608@zte.com.cn, BY3PR08MB70603039D33112EA0E123A46F7929@BY3PR08MB7060.namprd08.prod.outlook.com
Mime-Version: 1.0
From: wang.yubao2@zte.com.cn
To: jorge.rabadan@nokia.com
Cc: bess@ietf.org
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl2.zte.com.cn 1AA2t5ND073617
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/YgTLTUqdYDWIY1p27NTmjkhwhCk>
Subject: Re: [bess] Questions on draft-sajassi-bess-evpn-ip-aliasing-03
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, 10 Nov 2021 02:55:24 -0000

Hi Jorge,






please see in-line with [Yubao2]














原始邮件



发件人:Rabadan,Jorge(Nokia-US/MountainView)
收件人:王玉保10045807;
抄送人:bess@ietf.org;
日 期 :2021年11月09日 20:23
主 题 :Re: Questions on draft-sajassi-bess-evpn-ip-aliasing-03




Hi Yubao,


 


Please see in-line.


Thanks.


Jorge


 



From: wang.yubao2@zte.com.cn <wang.yubao2@zte.com.cn>
 Date: Tuesday, November 9, 2021 at 9:06 AM
 To: Rabadan, Jorge (Nokia - US/Mountain View) <jorge.rabadan@nokia.com>
 Cc: bess@ietf.org <bess@ietf.org>
 Subject: Questions on draft-sajassi-bess-evpn-ip-aliasing-03



 


Hi Jorge,


 


I read the draft, and have the following questions:


 


1) on section 1.2 Inter-subnet Forwarding for Prefix Routes in the Interface-less IP-VRF-to-IP-VRF Model


 


    The RT-1 per EVI route of ESI1 in Figure 2 is not an IP A-D per EVI route, but a normal Ethernet A-D per EVI route,


    in other words, its MPLS label identifies a BD, not an IP-VRF.


    is my understanding correct?

[jorge] not really, it is an IP A-D per EVI route as explained in section 3.


 


    In RFC9136 Interface-less IP-VRF-to-IP-VRF Model, 


    the inter-subnet-forwarding from H3 to H1 will pass through PE1/PE2's IP-VRF instance via the MPLS label of the IP-VRF's instance,


    but in the RFC9316 Bump-in-the-wire instance, 


    the inter-subnet-forwarding from H3 to H1 will not pass through PE1/PE2's IP-VRF instance because of the RT-1 per EVI route's MPLS Label's L2 context.


    But this section refers to both the above two use cases of RFC9136,


    So which behavior will be followed by this use case?

[jorge] see above, the IP A-D per EVI route includes the route-target and label of the IP-VRF as explained in section 3.




[Yubao2] I get your meanings now, I mistake the RT-1 per EVI route of use case b (section 1.2) as a Ethernet A-D per EVI route because of the following text:






   In the Interface-less IP-VRF-to-IP-VRF model described in

   [I-D.ietf-bess-evpn-prefix-advertisement] there is no Overlay Index

   and hence no recursive resolution of the IP Prefix route to either a

   MAC/IP Advertisement or an Ethernet A-D per ES/EVI route, which means

   that the fast convergence and aliasing/backup path functions are

   disabled.  Although the use-case is different, in a sense the

   recursive resolution of an IP Prefix route to an Ethernet A-D per ES/

   EVI route is already described in section 4.3 of

   [I-D.ietf-bess-evpn-prefix-advertisement], Bump-in-the-Wire Use-Case,

   but that section does not describe aliasing.


[Yubao2] These two concepts Ethernet A-D per ES/EVI route and IP A-D per ES/EVI route in this draft may be confusing.

                To me an ethernet A-D per EVI route means that its route-target identifies a MAC-VRF as per [RFC7432].

                an IP A-D per EVI route means that its route-target identifies a IP-VRF as per this draft.

                When they will be used by a RT-5 route with an ESI overlay index,

                they will be different in route advertisement, recursive resolution and forwarding behavior too.

                But in the above text of draft-sajassi-bess-evpn-ip-aliasing-03, it seems that the route advertisement, recursive resolution and forwarding 

                behavior in the draft is just the same as RFC9136 secion 4.3 Bump-in-the-wire use case.

                I think it will be confusing. The most obvious difference between these two use case is that,

                The  inter-subnet forwarding from H3 to H1 will use a MPLS label which identifies a MAC-VRF according to Bump-in-the-wire use case,

                But in this draft it is not the same behavior. This difference will lead to other differences on route advertisement and recursive resolution too.


 


2) On section 5.3 Constructing the EVPN IP Routes


 


     Is the RT-5 construction of the second use case (section 1.2) the same as the third use case (section 1.3) ?


     I mainly concerns the Route Targets and the Ethernet Tag ID of the RT-5 routes.


     especailly when the BD (to which the ESI of section 1.2 is attched) is of VLAN-aware service interface.

[jorge] the IP Prefix routes and MAC/IP advertisement routes are constructed as per section 5.3, hence the IP Prefix routes ethernet tag id is 0. This document does not change the use of the Ethernet Tag ID.




[Yubao2] As I explained above, if they are the same, 

         is the RT-5 construction of the use case c (section 1.3) the same as RFC9136 Bump-in-the-wire use case?


 


3) On section 5.3.1 Route Resolution


 


    Is the Route Resolution of the second use case (section 1.2) the same as the third use case (section 1.3) ?


    Will the route resolution of the second use case(section 1.2) need a BD and an IRB interface on PE3?


    I note that in RFC9136 section 4.3 Bump-in-the-wire use case, 


   the RT-1 per EVI route is advertised in a normal BD. It says that:


 


   (1)  Assuming TS2 is the active TS in ESI23, NVE2 advertises the


        following BGP routes:


 


        *  Route type 1 (Ethernet A-D route for BD-10) containing: ESI =


           ESI23 and the corresponding tunnel information (VNI field),


           as well as the BGP Encapsulation Extended Community as per


           [RFC8365].


 


        *  Route type 5 (IP Prefix route) containing: IPL = 24, IP =


           SN1, ESI = ESI23, and GW IP address = 0.  The EVPN Router's


           MAC Extended Community defined in [RFC9135] is added and


           carries the MAC address (M2) associated with the TS behind


           which SN1 sits.  M2 may be learned by policy; however, the


           MAC in the Extended Community is preferred if sent with the


           route.


 


    This RT-1 per EVI route will not just be used by the RT-5 routes for IP forwarding, 


    it will also be used by the MAC forwarding of BD-10.


    When it is used in IP forwarding and MAC forwarding, it will be the same route.


    If this is correct, it will need a BD on PE3 to be resolved to.

[jorge] the resolution is the same for the three cases, based on section 5.3.1. It happens in the context of the IP-VRF, but now considering the IP A-D routes (which carry the IP-VRF route-target). For use-cases 2 and 3, this is applicable to the interface-less and even interface-ful unnumbered IP-VRF-to-IP-VRF model (we can clarify this in future versions).




[Yubao2] In RFC9136 Interface-ful unnumbered IP-VRF-to-IP-VRF model, 

         The MPLS payload is encapsulated as ethernet packet:






   (3)  When DGW1 receives a packet from the WAN with destination IPx,

        where IPx belongs to SN1/24:




        *  A destination IP lookup is performed on the DGW1 IP-VRF

           table.  The lookup yields SN1/24, which is associated with

           the Overlay Index M1.  The forwarding information is derived

           from the RT-2 received for M1.




        *  The IP packet destined to IPx is encapsulated with: inner

           source MAC = M3, inner destination MAC = M1, outer source IP

           (source VTEP) = DGW1 IP, and outer destination IP

           (destination VTEP) = NVE1 IP.




[Yubao2] An IP A-D per EVI route whose MPLS label identifies an IP-VRF can't be use in such encapsulation.

           I try to understand their differences as the following, can you tell me whether it is consistent with draft-sajassi-bess-evpn-ip-aliasing-03?

           The Ethernet A-D per EVI route: Route-Target = MAC-VRF, as per [RFC7432], [RFC9136] and [EVPN inter-subnet forwarding]

           The IP A-D per EVI route: Route-Target = IP-VRF, as per draft-sajassi-bess-evpn-ip-aliasing-03

           And here are two variations which are not described in draft-sajassi-bess-evpn-ip-aliasing-03:

           The Ethernet A-D per EVI route with an IP-VRF label:  it is advertised in the context of a MAC-VRF but carries an IP-VRF label

      The IP A-D per EVI route with a MAC-VRF label: it is advertised in the context of an IP-VRF but carries a MAC-VRF label     


If you want to use a SBD with a unnumbered IRB interface,


The Ethernet A-D per EVI route with an IP-VRF label may help,


But the recursive route resolution for ESI overlay index will be done in the context of the SBD, 


which is not the same as your current design, but like the distributed bump-in-the-wire use case,


but this will have little relations with the RFC9136 Interface-ful unnumbered IP-VRF-to-IP-VRF model,


becaus of their different MPLS payload formats.


Although this is not consistent with the route resolution design of draft-sajassi-bess-evpn-ip-aliasing-03,


this solution may be easier to be deployed than an ethernet-format MPLS-payload solution or the IP A-D per EVI route with a MAC-VRF label solution .






I think it will be better if the difference between new IP A-D per EVI route and old Ethernet A-D per EVI route can be cearlified in this draft. 










Thanks,


Yubao