Hi，Jorge:
From: [email protected] <mailto:[email protected]> <[email protected] <mailto:[email protected]> > On Behalf Of Rabadan, Jorge (Nokia - US/Mountain View) Sent: Tuesday, March 16, 2021 2:54 PM To: Aijun Wang <[email protected] <mailto:[email protected]> >; 'Wei Wang' <[email protected] <mailto:[email protected]> >; 'linda.dunbar' <[email protected] <mailto:[email protected]> > Cc: 'bess' <[email protected] <mailto:[email protected]> > Subject: Re: [bess] About draft-wang-bess-l3-accessible-evpn Hi Aijun, Thanks for replying. Why do you want to “preserve the multi-homing functions” if the solution you are building has nothing to do with multi-homing? [WAJ] There are situations that ASBR in MAN(Metro-Area-Network) may multi-homing to different PEs in Backbone. I think this is similar with the CE multi-homing to PE in layer-2 environment. Also why do you want to introduce a double lookup (based on VNI and then LSI) on the PE if the VNI gives you 16M different values and VNI lookup is something that all chipsets support? [WAJ] It is not applicable to deploy 16M VRFs within the backbone, even the VNI field has the abundant space. For implementation on device, I think the double lookup is not necessary, just only find the right forwarding table based on both the VNI and LSI value. Thanks. Jorge From: Aijun Wang < <mailto:[email protected]> [email protected]> Date: Tuesday, March 16, 2021 at 4:42 AM To: Rabadan, Jorge (Nokia - US/Mountain View) < <mailto:jorge.rabadan@nokia. com> [email protected]>, 'Wei Wang' < <mailto:[email protected]> [email protected]>, 'linda.dunbar' < <mailto:[email protected]> [email protected]> Cc: 'bess' < <mailto:[email protected]> [email protected]> Subject: RE: [bess] About draft-wang-bess-l3-accessible-evpn Hi, Jorge: Thanks for your comments, please see detail replies inline. Wish to hear more suggestions from you. Best Regards Aijun Wang China Telecom From: [email protected] <mailto:[email protected]> <[email protected] <mailto:[email protected]> > On Behalf Of Rabadan, Jorge (Nokia - US/Mountain View) Sent: Friday, March 12, 2021 5:55 PM To: Wei Wang <[email protected] <mailto:[email protected]> >; linda. dunbar <[email protected] <mailto:[email protected]> > Cc: bess <[email protected] <mailto:[email protected]> > Subject: Re: [bess] About draft-wang-bess-l3-accessible-evpn Hi Wei, Thanks for taking the time to reply. The ESI type was conceived in RFC7432 to specify the format of the remaining 9 bytes and produce unique ESIs, in the case auto-derived ESIs and manual ESIs had to coexist in the same network. Irrespective, on reception of the EVPN routes with non-zero ESI some implementations just compare the 10-byte identifier and process EVPN routes accordingly, including routes type 5. [WAJ] Should we require such implementation to follow the requirements of the RFC? Using the ESI in this context will create an unnecessary number of interop issues. At least the Ethernet Tag ID would have no such issues. [WAJ] Some implementations may also ignore the value of Ethernet Tag ID, especially for the type-5 route. You have also mentioned this below. My other comment would be that, when we created the IP Prefix route, we added the Ethernet Tag ID so that user groups could be created within the same IP-VRF, but ultimately we found no use case for it and left it at zero in all the cases in the IP Prefix advertisement draft. [WAJ] Reusing the Ethernet Tag ID to classify the type-5 route is possible, but I prefer to defining the new ESI type, because the new ESI type can still preserve the “Multihoming Functions” , as described in RFC7432. I personally still think it is better and simpler to create a separate IP-VRF and VNI (or identifier) for each user group as people do today, rather than an ‘LSI’ per group withing the IP-VRF. With separate IP-VRFs: - the data path is simpler (no need for a second lookup that is not supported by current chipsets), and - you can still use all the BGP route dissemination tools that are based on route-targets. I don’t see any benefit in the solution you are suggesting, but of course I may miss a lot of things. [WAJ] Using separate IP-VRFs solution can accomplish the LSI-Based Service(similar with VLAN-Based service) effect, but can’t achieve the LSI-Aware Service(similar with VLAN-aware service). The benefit of LSI-Aware service is similar with the VLAN-Aware service, which it simplifies the deployment of IP-VRF within the backbone network. The enhancement to the PE device is necessary. Thanks. Jorge From: Wei Wang < <mailto:[email protected]> [email protected]> Date: Friday, March 12, 2021 at 9:14 AM To: linda.dunbar < <mailto:[email protected]> [email protected]>, Rabadan, Jorge (Nokia - US/Mountain View) < <mailto:[email protected]> [email protected]> Cc: bess < <mailto:[email protected]> [email protected]> Subject: [bess] About draft-wang-bess-l3-accessible-evpn Hi Linda and Jorge, Thanks for your comments at IETF110 meeting, and I think I need to explain our considerations for the newly defined LSI (Logical Session Identifier) concept. Question 1, from Linda Dunbar, "Is the usage of LSI same as the RD for VPN route distinguish?" Answer: LSI(Logical Session Identifier) is mainly used for distinguishing the different logical sessions between CE and PE device. Such session can be established via Vxlan, IPsec, or other tunnel technologies that can span layer 3 network. The LSI information should be transferred via the control plane and forwarding plane. In control plane, we try to use Ethernet Tag ID/newly defined ESI type to transfer, its purpose is to further distinguish the cusomer routes within one provider VRF. In forwarding plane, this information should be inserted into some place of the exising VxLAN encoding, as proposed in our draft:https://datatracker.ietf.org/doc/html/draft-wang-bess-l3-accessible-ev pn-04#section-6.1 Question 2, from Jorge Rabadan. "The ESI shouldn't be used to distinguish the route-type 5, it is mainly used for multi-homing purpose" Answer: Currently, we are considering using two methods to identify the routes that associated different LSI: Method 1: Ethernet Tag ID, which is similar with its usage in layer 2 vlan environment. Method 2: Newly defined ESI type(type 6) We think both methods are approachable: Method 1 requires also the update of https://tools.ietf.org/html/draft-ietf-bess-evpn-prefix-advertisement-11(Eth ernet Tag ID is set to 0 for route type 5), may arises some confuse with its original defintion. Method 2 requires the extension of ESI type (as described in: https://datatracker.ietf.org/doc/html/draft-wang-bess-l3-accessible-evpn-04# section-6.2). The original purpose of ESI (mulit-homing) can also be preserved. I hope the above explanations help. Comments and questions are always welcome. Best Regards, Wei China Telecom
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
