YANG és CIC integráció – Merre van az ésszerű határ?
A vita lényege röviden: mit lehet és mit érdemes a YANG-ból beengedni a CIC-be, és hol van az a pont, ahol a két modell már nem kompatibilis egymással.
A YANG eredetileg nem eszközkonfig formátum volt, hanem egy hálózati adatmodell. Ma viszont sok eszköz saját YANG-modellt használ, és konkrét konfigurációt YANG instance formában fogad. Emiatt két külön világ alakult ki:
- logikai YANG (absztrakt hálózati szolgáltatásmodellek),
- vendor YANG (az eszköz tényleges konfigurációs API-ja).
A CIC pont ezek között a rétegek között helyezkedik el. A CIC-ben van:
- Actor (eszközök, komponensek),
- State (állapotok),
- Intent (szándék),
- Obligation (szükséges módosítások),
- ProofTrace (bizonyítható állapotváltozás).
A kérdés az, hogyan nézzen ki a helyes adatfolyam:
logikai YANG → (általános device-YANG) → CIC → vendor-YANG
A CIC itt nem konfigurációs formátum, hanem összerendező réteg: eldönti, mely logikai elem mely eszközre kerül, hogyan bomlik le, és milyen szabályok érvényesek rá. A végrehajtás viszont már a vendor-specifikus YANG alapján történik.
A vita tényleges kérdései:
- általános device-Yang hogy jelenjen meg az IaC-ben (yaml vagy Yang formátumban)
- yaml esetén:
- hálózati eszközök schema leíróinak alapjának jó-e a Yang mondelben meghatározott általános device modellek?
- yang esetén:
- a CIC-ben a validáció hogy oldódik meg yang model validációval...
- IaC-ben a elvárt és a valós állapotot tudom-e tárolni yang obj-kban
A téma lényege: hol találkozik a YANG mint adatmodell és a CIC mint fogalmi architektúra, és meddig érdemes ezt az integrációt elvinni úgy, hogy mindkét világ előnyeit kihasználjuk, de egyik modell se torzuljon el.
- 15 megtekintés