An add or delete of VM translates to updating ENI and routes in bulk context.In normal operation, route updates can occur every 30 sec.In normal operation, mapping updates can occur as much as 100 mappings/sec.Implementation must support such bulk updates During startup, it is possible to have scaled configurations applied successively.Implementation must support single and bulk update of LPM and CA-PA Mapping tables.The following are the design considerations. As such, the implementation is performance and scale focussed as compared to traditional switching and routing based solutions. TBD 1.4 Scaling requirementsįollowing are the minimal scaling requirements ItemĭASH Sonic implementation is targeted for appliance scenarios and must handles millions of updates. Warm-restart support is not considered in Phase 1. User shall be able to clear state of ENI, VNET or all.User shall be able to show the DASH configured objects.Initial support is only for show and clear commands Eni, Vnic, VPort are used interchangeablyġ Requirements Overview 1.1 Functional requirementsĪt a high level the following should be supported:īringup SONiC image for DEVICE_METADATA subtype - Applianceīringup Swss/Syncd containers for switch_type - dpuĪble to program DASH objects configured via gRPC client to appliance card via SAI DASH API Definitions/Abbreviation Table 1: Abbreviations General DASH HLD can be found at dash_hld. This document provides more detailed design of DASH APIs, DASH orchestration agent, Config and APP DB Schemas and other SONiC buildimage changes required to bring up SONiC image on an appliance card. SONiC-DASH HLD High Level Design Document Rev 0.7 Table of Contents
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |