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

["Rabadan, Jorge (Nokia - US/Mountain View)" <[e-mail]>]

Hi Yubao,

Please see in-line.
Thanks.
Jorge

From: [e-mail] <[e-mail]>
Date: Tuesday, November 9, 2021 at 9:06 AM
To: Rabadan, Jorge (Nokia - US/Mountain View) <[e-mail]>
Cc: [e-mail] <[e-mail]>
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.



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.



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).





Thanks,

Yubao