After doing some research I found a few vendors that have a solution that extends the vxlan fabric to the server hypervisor.
Cisco VTS supports 3rd party x86 available now for vxlan fabric extension Arista and Nuage collaboration on vxlan fabric extension solution available now VMware also has a solution Kind regards Gyan On Tue, Mar 10, 2020 at 3:04 AM Tony Przygienda <[email protected]> wrote: > we're weighing in 161 pages in the last IESG reviews now which is however > not very meaningful ;-) since it's probably 25 pages just IANA request and > it's not just the spec, it's the whole outline of design/narrative/walk > through (folks preferred it that way). With FSMs/algorithms and water-tight > interoperable protocol like it can't be done in 10 easy pages breeze > through (well, one can do that but then customers spend 5 years figuring > out how to interop anything and finding cornercases, not the way RIFT WG is > run ;-) > > I'll ping you 1:1 otherwise ;-) > > thanks > > --- tony > > On Mon, Mar 9, 2020 at 9:15 PM Gyan Mishra <[email protected]> wrote: > >> Hi Tony >> >> I am actually a member of RIFT, as the WG charter description >> was intriguing so I joined - to learn more about the RIFT technology. >> >> I downloaded the draft but never made it through as its a lengthy 100+ >> page draft. Now I really have to read it. >> >> Yes that would be great. Please unicast me on [email protected]. >> >> Kind regards >> >> Gyan >> >> On Mon, Mar 9, 2020 at 11:31 AM Tony Przygienda <[email protected]> >> wrote: >> >>> Gyan, the technology that you look for exists and is about to go >>> standards RFC (i.e. _scalable_ L3 multihoming to the host including >>> bandwidth load-balancing and many other things that need consideration in >>> such case, e.g. host asic table scalability). Please look @ >>> https://datatracker.ietf.org/doc/draft-ietf-rift-rift/ If you need >>> more info/code, more than happy to talk out of band >>> >>> thanks >>> >>> -- tony >>> >>> On Thu, Mar 5, 2020 at 2:04 PM Gyan Mishra <[email protected]> >>> wrote: >>> >>>> Hi Sandy >>>> >>>> Thank you for the feedback on your use cases. >>>> >>>> For now will remain L2 MLAG to the host. >>>> >>>> BESS WG, >>>> >>>> If anyone hears of any new developments on vxlan fabric extension to >>>> hypervisor and any vendors supporting even 3rd party open source >>>> implementations of fabric extensions please reach out to me. >>>> >>>> As an aside when reading RFC 8365 NVO3 section 7 it kind of gets >>>> excited by the subject heading “single homed NVE residing in Hypervisor” or >>>> section 8 MH NVE in TOR server - thinking that maybe fabric extension to >>>> hypervisor does actually exist but of course the let down that no vendor >>>> supports it. >>>> >>>> It does seem there would be a lot of customers wanting this fabric >>>> extension to hypervisor capabilities for MH load balancing- and very >>>> surprising that it does not exist. >>>> >>>> https://tools.ietf.org/html/rfc8365#section-7 >>>> >>>> >>>> >>>> Kind regards >>>> >>>> Gyan Mishra >>>> Verizon >>>> Cell 301 502-1347 >>>> >>>> On Wed, Mar 4, 2020 at 4:57 PM Sandy Breeze <[email protected] >>>> <[email protected]>> wrote: >>>> >>>>> Hi Gyan, >>>>> >>>>> >>>>> >>>>> Here, we use a mix of NXOS & Arista EOS for leaf and spine, ASR9k DCI >>>>> doing L2 + L3 VTEP and stitching to MPLS EVPN / traditional VPNv4/6. We >>>>> also confess to pockets of proprietary NXOS vPC, and, pockets of Arista >>>>> ESI-MH. Incidentally, the older Broadcom NXOS boxes do have ESI-MH >>>>> capabilities and that worked alright. Customers, like us, have been long >>>>> promised the vendor silicon will catch up, though we’ve yet to see it >>>>> happen. >>>>> >>>>> >>>>> >>>>> We’re entirely a home grown automation / orchestration stack, with >>>>> many years behind it. Have a look at some talks we’ve given publicly for >>>>> the background in our ‘GOLF’ project. >>>>> https://www.youtube.com/watch?v=jXOrdHfBqb0&t= >>>>> >>>>> >>>>> >>>>> > Has this ever been done before and with which hypervisors ? >>>>> >>>>> We had the same requirements as you 2-3 years ago. Have we solved >>>>> it? TL;DR: not really! We did make an interesting proof of concept >>>>> though… >>>>> >>>>> Being largely a VMWare NSX house, we found VMWare closed to offering >>>>> any type of EVPN orchestrated VTEP extension into the physical fabric.. >>>>> Quite simply, its model of extending to physical VTEP is OVSDB. That’s >>>>> not >>>>> exactly compatible with an EVPN ToR, for various reasons. So, we had the >>>>> idea that we’d build something which spoke both OVSDB (to NSX) and EVPN >>>>> (to >>>>> the physical ToR). The high level idea being, we’d use this to create >>>>> routes in EVPN if they were seen from OVSDB, and visa-versa, only we’d >>>>> maintain the original next-hop. Kinda like an iBGP RR, only between 2 >>>>> different control-planes. Internally, we called it VxGlue. >>>>> >>>>> >>>>> >>>>> At a high level, it worked well in achieving nice loadbalancing of >>>>> traffic into the hypervisor. It would no doubt scale fairly well too.. >>>>> Is >>>>> it the right thing to do in a production network? We decided not. For >>>>> one, its very hard to keep up with pace of development of underlying >>>>> VMWare >>>>> API’s. As I say, this was a few years ago and things have moved on. >>>>> Maybe >>>>> we’ll revisit. >>>>> >>>>> >>>>> >>>>> Sandy >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 04/03/2020, 21:03, "BESS on behalf of Gyan Mishra" < >>>>> [email protected] on behalf of [email protected]> wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Thank you all for the feedback!! >>>>> >>>>> >>>>> >>>>> Our requirements we ar looking for a way to increase stability without >>>>> sacrificing bandwidth availability and convergence with Data Center host >>>>> connectivity to an existing vxlan fabric. Our server traffic volume is >>>>> higher bandwidth East to West then North to South. >>>>> >>>>> >>>>> >>>>> We have a Cisco Nexus based vxlan evpn fabric with multi site feature >>>>> connecting all of our PODs intra DC and use BGP EVPN over an MPLS core for >>>>> DCI inter connect inter Data Center connectivity. >>>>> >>>>> >>>>> >>>>> We have orchestration via Cisco NSO and DCNM for network >>>>> programmability. Typical Cisco shop.. >>>>> >>>>> >>>>> >>>>> Our Data Center host attachment model as been with MLAG using Cisco’s >>>>> vPC. That has been problematic having that L2 extension so we would like >>>>> to find a better way to maybe leverage our existing vxlan fabric and >>>>> extend >>>>> to server hypervisor if at all possible. >>>>> >>>>> >>>>> >>>>> So with a hypervisor connected to two leaf switches in a vxlan fabric >>>>> it sounds like it maybe possible with Cisco’s IETF standards based >>>>> implementation of vxlan overlay following NVO3 RFC 8365 and BGP EVPN RFC >>>>> 7432 that we could extend the fabric to server hypervisor. >>>>> >>>>> >>>>> >>>>> The question related to L3 ECMP versus L2 MLAG become moot as with >>>>> existing BGP EVPN load balancing procedures with EVPN type 4 default >>>>> gateway DF election we can achieve all active multi homed load balancing >>>>> from the hypervisor. As was mentioned RFC 8365 since vxlan evpn does not >>>>> use ESI the local bias feature would have to be used for split horizon.. >>>>> >>>>> >>>>> >>>>> Of course with the extension to the hypervisor we would use are >>>>> existing orchestration of the fabric to manage the server hypervisor >>>>> layer. >>>>> >>>>> >>>>> >>>>> Has this ever been done before and with which hypervisors ? >>>>> >>>>> >>>>> >>>>> Kind regards >>>>> >>>>> >>>>> >>>>> Gyan >>>>> >>>>> >>>>> >>>>> On Mon, Mar 2, 2020 at 7:58 PM Jeff Tantsura <[email protected]> >>>>> wrote: >>>>> >>>>> Gyan, >>>>> >>>>> >>>>> >>>>> On open source side of things - FRR supports EVPN on the host. >>>>> >>>>> Any vendor virtualized NOS would provide you the same (at least >>>>> Junos/cRPD or XRv). >>>>> >>>>> EVPN ESI load-sharing eliminates need for MLAG (basic thought, the >>>>> devil is in the details :)) >>>>> >>>>> ECMP vs LAG load-balancing - the algorithms supported are quite >>>>> similar, in some code bases actually the same, so this statement is not >>>>> really correct. >>>>> >>>>> >>>>> >>>>> Would be glad to better understand your requirements and help you! >>>>> >>>>> Regards, >>>>> >>>>> Jeff >>>>> >>>>> >>>>> >>>>> On Mar 2, 2020, at 16:00, Gyan Mishra <[email protected]> wrote: >>>>> >>>>> >>>>> >>>>> Thanks Robert for the quick response >>>>> >>>>> >>>>> >>>>> Just thinking out loud - I can see there maybe some advantages of >>>>> elimination of L2 to the host but the one major disadvantage is that BGP >>>>> multipath provides flow based uneven load balancing so not as desirable >>>>> from that standpoint compare to L3 MLAG bundle XOR Src/Dest/Port hash.. >>>>> >>>>> >>>>> >>>>> Other big down side is most enterprises have the hypervisor managed by >>>>> server admins but if you run BGP now that ends up shifting to network.. >>>>> More complicated. >>>>> >>>>> >>>>> >>>>> Kind regards >>>>> >>>>> >>>>> >>>>> Gyan >>>>> >>>>> >>>>> >>>>> On Mon, Mar 2, 2020 at 6:39 PM Robert Raszuk <[email protected]> >>>>> wrote: >>>>> >>>>> Hi Gyan, >>>>> >>>>> >>>>> >>>>> Similar architecture has been invented and shipped by Contrail team. >>>>> Now that project after they got acquired by Juniper has been renamed to >>>>> Tungsten Fabric https://tungsten.io/ >>>>> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftungsten.io%2F&data=02%7C01%7Csandy.breeze%40eu.clara.net%7C5f875c0816c2433baeee08d7c07f7358%7Cf87a76403b944bbdb5fab4c15947cf56%7C0%7C0%7C637189525946984085&sdata=YOxnBjXir%2B%2Br4h2Emgz0%2BMkYxBrR75TpcLWqEuXiftY%3D&reserved=0> >>>>> while >>>>> Juniper continued to keep the original project's name and commercial >>>>> flavor >>>>> of it. No guarantees of any product quality at this point. >>>>> >>>>> >>>>> >>>>> Btw ,,, no need for VXLAN nor BGP to the host. The proposed above >>>>> alternative were well thought out and turned to work ways far more >>>>> efficient and practical if you zoom into details. >>>>> >>>>> >>>>> >>>>> Best, >>>>> >>>>> Robert. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Tue, Mar 3, 2020 at 12:26 AM Gyan Mishra <[email protected]> >>>>> wrote: >>>>> >>>>> >>>>> >>>>> Dear BESS WG >>>>> >>>>> >>>>> >>>>> Is anyone aware of any IETF BGP development in the Data Center arena >>>>> to extend BGP VXLAN EVPN to a blade server Hypervisor making the >>>>> Hypervisor >>>>> part of the vxlan fabric. This could eliminate use of MLAG on the leaf >>>>> switches and eliminate L2 completely from the vxlan fabric thereby >>>>> maximizing stability. >>>>> >>>>> >>>>> >>>>> Kind regards, >>>>> >>>>> >>>>> >>>>> Gyan >>>>> >>>>> -- >>>>> >>>>> Gyan Mishra >>>>> >>>>> Network Engineering & Technology >>>>> >>>>> Verizon >>>>> >>>>> Silver Spring, MD 20904 >>>>> >>>>> Phone: 301 502-1347 >>>>> >>>>> Email: [email protected] <[email protected]> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> BESS mailing list >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/bess >>>>> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fbess&data=02%7C01%7Csandy.breeze%40eu..clara.net%7C5f875c0816c2433baeee08d7c07f7358%7Cf87a76403b944bbdb5fab4c15947cf56%7C0%7C0%7C637189525946994081&sdata=ioGt83d8%2FQ%2FUFiA9L0T%2BgrGmoDBiqADpUzw7kaRfxhI%3D&reserved=0> >>>>> >>>>> -- >>>>> >>>>> Gyan Mishra >>>>> >>>>> Network Engineering & Technology >>>>> >>>>> Verizon >>>>> >>>>> Silver Spring, MD 20904 >>>>> >>>>> Phone: 301 502-1347 >>>>> >>>>> Email: [email protected] >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> BESS mailing list >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/bess >>>>> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fbess&data=02%7C01%7Csandy.breeze%40eu..clara.net%7C5f875c0816c2433baeee08d7c07f7358%7Cf87a76403b944bbdb5fab4c15947cf56%7C0%7C0%7C637189525947004076&sdata=CEduzdoebDfvYoDdqSQJEafpKGKycyM5YpCYOYviX%2FE%3D&reserved=0> >>>>> >>>>> -- >>>>> >>>>> Gyan Mishra >>>>> >>>>> Network Engineering & Technology >>>>> >>>>> Verizon >>>>> >>>>> Silver Spring, MD 20904 >>>>> >>>>> Phone: 301 502-1347 >>>>> >>>>> Email: [email protected] >>>>> >>>>> >>>>> >>>>> >>>>> >>>> -- >>>> >>>> Gyan Mishra >>>> >>>> Network Engineering & Technology >>>> >>>> Verizon >>>> >>>> Silver Spring, MD 20904 >>>> >>>> Phone: 301 502-1347 >>>> >>>> Email: [email protected] >>>> >>>> >>>> >>>> _______________________________________________ >>>> BESS mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/bess >>>> >>> >> >> -- >> >> Gyan Mishra >> >> Network Engineering & Technology >> >> Verizon >> >> Silver Spring, MD 20904 >> >> Phone: 301 502-1347 >> >> Email: [email protected] >> >> >> >> -- Gyan Mishra Network Engineering & Technology Verizon Silver Spring, MD 20904 Phone: 301 502-1347 Email: [email protected]
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
