Hi Sami, If you want to respond, please elaborate so anyone who is following this thread can benefit from the exchange; otherwise, it won’t be productive. Please see my responses marked w/ [AS].
From: "Boutros, Sami" <sbout...@ciena.com> Date: Friday, November 20, 2020 at 10:51 AM To: Cisco Employee <saja...@cisco.com>, Sami Boutros <boutros.s...@gmail.com>, "Ali Sajassi (sajassi)" <sajassi=40cisco....@dmarc.ietf.org> Cc: "bess@ietf.org" <bess@ietf.org> Subject: Re: [**EXTERNAL**] Re: [bess] Issues w/ draft-boutros-bess-elan-services-over-sr Hi Ali, Please see inline. Sighhh! The first section of your draft (section 1) and the first two paragraphs of that section talks about (1) and (2) that I mentioned in my email. Basically, Introduction section states these two reasons as the underlying reasons for your draft. [Sami] In fact, it is not, this is simply an opening statement explaining the control plane complexity that we are trying to simplify and is by no mean objectives to either reduce # of PWs and # of MAC entries, our proposal is a control plane simplification that eliminates need for PWs or EVPN control plane distribute any # of mac entries. You know there is a difference between reducing control plane overhead and eliminating it! [AS] This draft is a technical draft and not a marketing white paper, so when you talk about a 20 year-old VPLS technology and give example wrt its scale issue, then I’d like to know why you are not mentioning PBB-VPLS which eliminate the PW scale issue of VPLS. And if you think doing control-plane signaling in LDP or BGP for PBB-VPLS is complex, then why not mention you can use static PW setup (via a controller). Why these existing solutions are not enough to address your concern if you want to use the old-method of data-plane learning. With respect to EVPN, every routes in EVPN has a purpose but if you want to use a subset of features and use data-plane learning, then EVPN allows for that. As you may know PBB-EVPN uses only a subset of EVPN routes & functions while doing data-plane learning. So, if you think EVPN control-plane is complex and do data-plane learning, then why not use PBB-EVPN? Can you detail for me what aspects of PBB-EVPN is too complex for you? As I explained in details in my response, we have been there and done that long time ago; however, I don’t see any mention of the previous work and RFCs in your draft, so maybe you don’t know about them (History is the best teacher one can have). [Sami] I love history and have a library of history books at home! Please list drafts and other previous work that talked about eliminating PW signaling and we will be more than happy to reference it! [AS] I mentioned all those RFCs in my first email. And wrt VxLAN RFC, it is 7348. Also, you didn’t address any of them issues that I raise and instead. I will list them again here and please respond clearly to each of them: 1. If you want to do data-plane learning over SR, why not use PBB-EVPN over SR. As I mentioned PBB-EVPN is agnostic of underlay tunnel and it can work with SR, MPLS, TE, etc. [Sami] Our proposal is not about using complex control plane to setup PWs or EVPN to start with, so why should we use it? [AS] Again, if you want to have technical discussions, please elaborate on exactly what aspects of PBB-EVPN control plane is complex given PBB-EVPN uses ONLY a subset of EVPN routes and procedures/functions. 1. How does your solution take care of VxLAN encoding which is prevalent in DC and EN? For VxLAN w/ data-plane learning, can you tell me why RFC 7348 (done 10 years ago) is not applicable? Needless to say that both data-plane and control-plane solutions for VxLAN was introduced at the same time about 10 years ago and industry decided in favor of control-plane!! [Sami] We are not saying by any mean don’t use EVPN. And we do respect the industry and service providers choice, so can we leave it to service providers and industry to decide their choice of technology or control plane! [AS] But that wasn’t my question. What I am saying is we have seen this play ten years ago and how is your proposal handle VxLAN encap and how it is different from RFC7348. 1. How do you want to address IRB in your proposal? Will IRB be never be used in your proposal? [Sami] We will address IRB in the next rev of the draft, as we see our proposal will provide great benefits to Data Center customers specially when using SRv6. [AS] Nice marketing ☺ but can you give us a technical explanation now in one paragraph? 1. How do you want to address unequal LB for All-Active MH? [Sami] In fact, how to achieve unequal LB with our solution was clearly explained on the slides I presented [AS] Sami, referring me to a slide-page that doesn’t explain it and saying “it was clearly explained” is not productive. The one to last slide only says: “Packets destined to the MH CE connected to node 5 and node 6 can be load-balanced (ECMP/UCMP) across the core given that the MAC addressed were learned via anycast SID hosted node 5 and 6.” You only make the claim that it can be done and you don’t explain how it can be done. Have you read unequal-lb draft? How does the link bw info is conveyed to other PEs and how those PE perform unequal LB? 1. How do you want to address host mobility where a MAC is associated with multiple IP address? [Sami] This as well we will address in the next Rev. Stay tuned. [AS] It is fine just saying you haven’t thought about it yet ☺ If you have just give a paragraph on how? Now, with respect to your two claims: 1. Simplification: A solution can be simplified if it doesn’t need to address much of anything ☺ I.e., if it doesn’t need to address IRB, to address unequal LB, to address multiple IP address for a MAC, to address optimum mcast for L2&L3 simultaneously (IRB), etc. [Sami] Please see above responses on IRB, and unequal LB. As for mcast, we don’t have plan yet for that. [AS] I did and I will be waiting for your detailed response. 1. Anycast SID: the notion of anycast SID and anycast IP address for All-Active multi-homing is not new and again has been done for ages. Cisco proprietary solution for All-Active multi-homing (called VPC) before EVPN was based on anycast IP address. However, there are drawback for it – one of which is underlay topology decides LB instead of the actual link BW of MCLAG!! [Sami] As I mentioned to Jorge, we are not inventing anycast SID we are simply using it, this is BTW an IETF draft not a patent application! [AS] And as I was explaining in my response to Jorge, underlay mechaism has issues when used for overlay purposes ! Cheers, Ali Thanks, Sami Cheers, Ali From: Sami Boutros <boutros.s...@gmail.com> Date: Thursday, November 19, 2020 at 6:32 PM To: "Ali Sajassi (sajassi)" <sajassi=40cisco....@dmarc.ietf.org> Cc: "bess@ietf.org" <bess@ietf.org>, Cisco Employee <saja...@cisco.com>, Sami Boutros <sbout...@ciena.com> Subject: Re: [bess] Issues w/ draft-boutros-bess-elan-services-over-sr Hi Ali, The draft doesn’t state neither 1 or 2 below. I’m not sure if we are looking at the same draft. Here is the text in the draft introduction The goal of the proposed approach is to greatly simplify control plane functions and minimize the amount of control plane messages PE nodes have to process. In this version of the document, we assume Segment Routing (SR) underlay network. A future version of this document will generalize the underlay network to both classical MPLS and SR technologies. The proposed approach does not require PW, and hence the control plane complexity and message overhead associated with signaling and maintaining PWs are eliminated. Our goal is to simplify: 1- The control plane by signaling very few messages possibly 1 message per node to signal all ELAN services configured on that node, presenting each ELAN service as 1 bit in the control plane message. 2- The data plane by setting up much less control plane elements like PWs, tunnels etc., and more importantly leveraging SR redundancy mechanisms of any cast SID to remove the need of any overlay convergence or redundancy mechanisms. Not sure if any the stuff u listed below can address any of the above! Thanks, Sami On Nov 19, 2020, at 12:21 PM, Ali Sajassi (sajassi) <sajassi=40cisco....@dmarc.ietf.org<mailto:sajassi=40cisco....@dmarc.ietf.org>> wrote: Sami, Since we didn’t have time to discuss the issues during the BESS meeting, let me explain and elaborate them here: The draft states the following two main objectives for its purpose but both have been addressed already !! 1. Reducing # of PWs in VPLS: * VPLS (both BGP and LDP) is a 20-year old technology which is getting deprecated and many providers (SP, DC, and EN) are moving toward EVPN. However, a few years after VPLS (about 15 years ago) we introduced PBB-VPLS (RFCs 7041 and 7080) to address the PW scale issues along with few other things. 1. Reducing # of EVPN MAC route advertisements: * This may have been an issue 10 years ago and that’s why we introduced simultaneously both EVPN and PBB-EVPN (RFC 7623) but not anymore. PBB-EVPN uses data-plane learning and it uses concepts of service-id, source B-MAC (for MAC learning) and destination B-MAC (for BUM ID), and same concepts are used in your draft. Furthermore RFC 7623 supports All-Active multi-homing as well as Single-Active with all the improvements that came later including per-ISID c-mac flushing that Jorge presented during the call. Needless to say that PBB-EVPN is transport agnostic and can work with SR, MPLS, TE, etc. So, my question is that: what is the point of this draft? Are you trying to have a bit more compressed header over what we currently have in PBB-EVPN because in terms of functionality, I don’t see much difference. However, I see even more issues than PBB-EVPN such as IRB handling and Unequal load-balancing for an ES. The idea of breaking a PW in to three components of service-id, source-id, and dest-id has been around for almost twenty years. I introduced mvpls draft in 2002, followed by PBB-VPLS. VxLAN RFC (which also talks about data-plane learning) is along the same idea introduced in 2010. And finally PBB-EVPN in 2012. So, why do we need to re-invent the wheel again? -Ali _______________________________________________ BESS mailing list BESS@ietf.org<mailto:BESS@ietf.org> https://www.ietf.org/mailman/listinfo/bess [ietf.org]<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/bess__;!!OSsGDw!aLcz_pnvt4gPqKIzYHfRA8h4wTCy4_qyyzWSK4zWSIeLeGyHaBG7d3zkxDqblQ$>
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
