Bridging the Gap Accelerating Open Source Agility on Cisco Silicon One Platforms — Transcript

Full transcript

1. 0:03Oh, sorry. Uh, good afternoon. Uh, today
2. 0:06we'll be covering an important area for
3. 0:08OCP. How to quickly enable a healthy
4. 0:11ecosystem of partners and suppliers
5. 0:13through accelerating open source agility
6. 0:15with Cisco silicon 1based platforms. I
7. 0:18am Wayan Hong from Cisco and
8. 0:19co-presenting is Masi Muhammad also from
9. 0:22Cisco. Here
10. 0:26Cisco Silicon provides a consistent
11. 0:28hardware foundation for scalable
12. 0:30disagregated networking.
13. 0:33A common BSP use of the SI abstraction
14. 0:36layer and reasonable validation workflow
15. 0:39accelerates onboarding of open- source
16. 0:42NOS solutions such as Sonic and Fboss.
17. 0:46We will cover open source NOS
18. 0:48architecture and and ecosystem reuse,
19. 0:51integration hurdles, workflow and
20. 0:53benefits,
21. 0:55three-phase validation strategy and test
22. 0:57workflow,
23. 0:58test coverage, reuse, gaps and
24. 1:01integration challenges.
25. 1:04We'll conclude with community
26. 1:06collaboration and call to action.
27. 1:10The open NOS architecture consists of
28. 1:13the NOS integrating over SAI SDK and
29. 1:15silicon one. It is driven by strong test
30. 1:19suites for both EP boss and Sonic.
31. 1:22Sonic uses the Sonic management test
32. 1:24suite. EP boss uses the test suite
33. 1:26specific for the data plane. Notably the
34. 1:30agent hardware inside tests and the link
35. 1:32test. Both NOS run over Cisco silicon
36. 1:36one family which includes a rich set of
37. 1:38devices spanning multiple rows.
38. 1:45The Sonic management test suite covers
39. 1:47features across tier topologies.
40. 1:51EP boss agent hardware and site test
41. 1:52cover features as well and eposs link
42. 1:55test extensively cover link and module
43. 1:57testing.
44. 1:59run frameworks are very different from
45. 2:01piest and packet test framework in Sonic
46. 2:04compared to GEST and CPU packet
47. 2:06injection in F boss.
48. 2:10Though approaches are different, the
49. 2:12goals are the same to validate switch
50. 2:14ASIC functionality in advance of running
51. 2:16in the live network.
52. 2:20When running these tests, the plan is
53. 2:22generally to run identically,
54. 2:24but there can be differences that need
55. 2:27to be covered.
56. 2:29We see different CPU models, physical
57. 2:33memory, BIOS settings, kernel versions,
58. 2:37and Linux repos in use. Also, optical
59. 2:41modules and cables can come from
60. 2:43multiple suppliers.
61. 2:45Hardware configuration, topology,
62. 2:49and the the peer link partners do matter
63. 2:51as well. The software versions need to
64. 2:54be the same platform sai SDK but mixes
65. 2:58can happen.
66. 3:01All parties also need to run the same
67. 3:03test suite revision and configurations.
68. 3:06Operational semantics can include
69. 3:08provisioning scripts and environmental
70. 3:10factors.
71. 3:12Out of memory, out of range sensor
72. 3:14conditions, these are all factors that
73. 3:17can happen in a real life network.
74. 3:20Proper error handling requires strong
75. 3:22debug capabilities.
76. 3:24Leveraging strategic design and testing
77. 3:27minimizes these events.
78. 3:32The open NOS testing workflow is run by
79. 3:34three primary groups. Each group can
80. 3:37come from multiple companies and this is
81. 3:39where the most benefit can be achieved.
82. 3:42Leveraging a common Cisco workflow with
83. 3:44Silicon One based platforms where we
84. 3:47build the NOS link with Silicon One SAI
85. 3:50libraries, run validation, feature and
86. 3:53solution tests
87. 3:55and deliver validated SAI SDK code to
88. 3:58customers.
89. 4:00Cisco also provides strong debug
90. 4:02capabilities through Silicon One gRPC
91. 4:05based CLI and Python gel.
92. 4:11We get multi-party coverage with
93. 4:14hardware validation for the ODM, SAI SDK
94. 4:18validation for Cisco Silicon team and
95. 4:21optics cables and peer interrupt for the
96. 4:23end users.
97. 4:25This one workflow saves time, reduces
98. 4:29duplicate work, catches bugs earlier,
99. 4:33and benefits all parties.
100. 4:38Now I'll hand it over to Masi to cover
101. 4:40test strategy.
102. 4:41>> Yeah, I will. Hey, thank you. I will go
103. 4:43through a few slides that cover the
104. 4:45Cisco test strategy and how we actually
105. 4:49execute some of the test for open NAS
106. 4:51like Sonic and Foss. Cisco test strategy
107. 4:55is organized into three different uh
108. 4:58three distinct phases
109. 5:00each serving a specific purpose in the
110. 5:04life cycle of qualification.
111. 5:08Each phase fades fa feeds into the next
112. 5:11phase. As an example, the component
113. 5:15level tests gates PR commits whereas
114. 5:20the onbox test gates the nightly builds
115. 5:25whereas the solution test gates code
116. 5:28drops. This layered approach ensures
117. 5:32that we catch defects as early as
118. 5:36possible at the earliest stage.
119. 5:39The goal of this test strategy is to
120. 5:41validate FBOS on Cisco platforms using
121. 5:45the same m same criteria as I outlined
122. 5:50above in the test strategy so that we
123. 5:53could accelerate readiness.
124. 5:58[snorts]
125. 5:59As part of the test strategy, we
126. 6:02performed some analysis by dividing the
127. 6:06test suites into layers
128. 6:09uh to understand how we can actually
129. 6:13reuse a level per layer using sonic test
130. 6:18framework and the the tools that we have
131. 6:22inhouse as a benchmark or as a baseline.
132. 6:25We concluded that most of the layers has
133. 6:29high potential reuse. Some layers have
134. 6:33medium potential reuse and some has we
135. 6:36have to do a lot of work to run fost and
136. 6:40pass those test cases.
137. 6:43And then we performed another analysis
138. 6:46where we wanted to go a little bit more
139. 6:47granular of how we can actually qualify
140. 6:50in NOS with existing and proven
141. 6:53topologies like leaf spine backtoback
142. 6:57and fixed and we came to while ensuring
143. 7:01that FB boss or another open NOS meets
144. 7:05the same quality and performance
145. 7:07standards.
146. 7:10The SA and the SDK test typically
147. 7:12validate the hardware abstraction layer
148. 7:15that is independent of NOS. So the reuse
149. 7:18level is pretty much full. So
150. 7:21environment remains the same even even
151. 7:24if you use another NOS to run the SI SDK
152. 7:26test. The BSP test are essentially u a
153. 7:31board level hardware test uh that are
154. 7:34consistent with the hardware where some
155. 7:36adaptation might be needed to run on
156. 7:38different platforms.
157. 7:40The data plane forwarding tests
158. 7:43uh are essentially programmed by the SAI
159. 7:46SDK and is actually consistent with the
160. 7:48ASIC for you to run for different
161. 7:50topologies. Some adaptation actually is
162. 7:53needed.
163. 7:55And when you go down go down to the
164. 7:58latency, latency essentially is an ASIC
165. 8:01property. The methodology to to measure
166. 8:04latency applies independently of the
167. 8:07NOS. Optics test essentially validates
168. 8:10your transceivers
169. 8:12and some BSP related optical management
170. 8:15functions irrespective of the NAS.
171. 8:19QoS behavior like PFC, ECN, scheduleuler
172. 8:23depends upon is largely determined by
173. 8:25the ASC configuration and you have to do
174. 8:28a lot of adaptation to make those tests
175. 8:31run and work closely with with vendors
176. 8:33and customers. Manufacturing tests
177. 8:37essentially uh validates the hardware
178. 8:39integrity and are independent of the
179. 8:41NAS. So we were excited to see that most
180. 8:44of the capabilities that we have today
181. 8:46as with our suites of tests that we have
182. 8:49we can reuse them to run any other open
183. 8:52NOS like FB boss or or or any other open
184. 8:56uh NOS that is available today.
185. 8:59What are some of the challenges that we
186. 9:00have that we are facing in terms of
187. 9:03testing open NAS? One of the major
188. 9:05challenges we have or the security
189. 9:07challenges where the vulnerability
190. 9:09detection and mitigation with openness
191. 9:11is not visible much. We also do not know
192. 9:15the cadence at which the security
193. 9:17patches are getting applied. So we need
194. 9:19to have a closer look if you really
195. 9:21wanted to run open NOS where security
196. 9:23has to be a priority.
197. 9:26Interoperability issues that comes while
198. 9:28testing with optics or ny or other
199. 9:31switches. Typically the optics and mix
200. 9:34looks very very simple but actually
201. 9:35they're are very extremely challenging
202. 9:37from an interoperability point of view.
203. 9:40The other challenge that we see is the
204. 9:42debugability and the troubleshooting
205. 9:44challenges when you have a multi- vendor
206. 9:47multi-layer open rack systems and these
207. 9:50challenges are real. We have made a lot
208. 9:53of improvements in integration of tools
209. 9:56and other things but we have some way to
210. 9:58go so that everything can be shared very
211. 10:00in open manner.
212. 10:04Uh I just wanted to highlight some of
213. 10:07the amazing projects that we have done
214. 10:09uh with Meta where we worked at various
215. 10:12levels whether we have worked closely
216. 10:16with ODM vendors in building a ve 4 and
217. 10:18100C by our Cisco silicon one only um uh
218. 10:24only and silicon one silicon one and MPU
219. 10:27SDK
220. 10:29uh and we have also done an OCP inspired
221. 10:32design uh with meta which is a custom
222. 10:34system which 8501 that is getting
223. 10:36consumed at meta at multiple roles uh
224. 10:39[snorts] across data center and backbone
225. 10:42and also we have our own Cisco designed
226. 10:45systems that are going to be day one
227. 10:48fbost enabled or sonic enabled. So we
228. 10:51have Cisco is actually in a very unique
229. 10:53position to meet the demands of the
230. 10:56varied engagement and operational models
231. 10:59that the customer is is is asking.
232. 11:02The takeaway is we need to adapt
233. 11:06standardization validation. We encourage
234. 11:08all of you to contribute test cases to
235. 11:11upstream expand the test coverage and
236. 11:14collaborate to improve on the
237. 11:16qualification criteria. End of the day,
238. 11:18the goal is to build an open ecosystem
239. 11:22and accelerate development,
240. 11:24qualification and deployment of
241. 11:28networking platforms with open NAS.
242. 11:31Thank you so much for your time.
243. 11:39Thank you guys. Uh any questions? Uh
244. 11:41please line up behind the mics.
245. 11:51I don't see any questions. Thank you.
246. 11:52Thanks so much. Thank you.