YANG: как моделировать данные конфигурации вложенных списков без ключа

Я пытаюсь построить модель YANG для этого файла конфигурации со списками без ключей. Однако из-за необходимости ключа в списке YANG я не смог построить точную модель YANG. Есть ли идея, как представить список списка без ключа в YANG.

Файл включает в себя списки управления доступом, в которых может быть много списков управления доступом, таких как acl1, acl2, названных пользователями и имеющих правила, как в примере ниже.

acls:
  acl1:
  - rule:
      nw_src: 192.168.1.1/24  
      actions:
        allow: 1
  - rule:
      actions:
        allow: 0
  acl2:
  - rule:
      nw_src: 192.168.1.1/24  
      actions:
        allow: 0
  - rule:
      actions:
        allow: 1

Моя модель YANG

list acls{
     description "list of acls ";
      key "acl-name";
      ordered-by user;
      leaf acl-name {
        type string {
          length "1..64";
        }
      }
 list acle {
      description "This is a list of users in the system.";
      key "acle-name";
      ordered-by user;
      leaf acle-name {
        type string {
          length "1..64";
        }
        description
          "The name of access-list. A device MAY restrict the length
           and value of this name, possibly space and special
           characters are not allowed.";
      }

      container actions {
        description "actions for this acl entry ";    
        leaf allow {
          type uint8;
         }              
      } // end actions container       
   container match{
        description "match fields for this acl entry ";
    leaf nw_src{
         type inet:ipv4-address;
         }
    }
 }//match cont
 }//acle
} //acls

И, следовательно, соответствующий действительный файл данных имеет дополнительные поля, которые необходимы для YANG, но не существуют в моем исходном файле конфигурации выше, например (aclname, acle, aclename).

acls:
  acl1:
    aclname: acl1
    acle:
      rule11:
        aclename: rule11
        nw_src: 192.168.1.1/24
        actions:
          allow: 1
      rule12:
        aclename: rule12
        actions:
          allow: 0
  acl2:
    aclname: acl2
    acle:
      rule21:
        nw_src: 192.168.1.1/24    
        aclename: rule21
        actions:
          allow: 0
      rule22:
        aclename: rule22
        actions:
          allow: 1

person Shaboti    schedule 03.03.2018    source источник


Ответы (1)


RFC7950, 7.8.2. Ключевое утверждение списка

Оператор «ключ», который ДОЛЖЕН присутствовать, если список представляет конфигурацию, и МОЖЕТ присутствовать в противном случае, принимает в качестве аргумента строку, которая определяет разделенный пробелами список из одного или нескольких идентификаторов листа этого списка. Листовой идентификатор НЕ ДОЛЖЕН появляться в ключе более одного раза. Каждый такой идентификатор листа ДОЛЖЕН ссылаться на дочерний лист списка. Листы могут быть определены непосредственно в подоператорах списка или в группах, используемых в списке.

Комбинированные значения всех листьев, указанных в ключе, используются для уникальной идентификации элемента списка. Всем листам ключа ДОЛЖНЫ быть присвоены значения при создании записи списка. Таким образом, любые значения по умолчанию в ключевых листах или их типах игнорируются. Любые «обязательные» операторы в ключевых листах игнорируются.

Перечисляет, что данные конфигурации модели (вложенные или нет) должны иметь ключ. Обойти это невозможно, потому что каждый экземпляр списка конфигурации должен быть однозначно идентифицируемым, чтобы такие конструкции, как instance-identifiers, работали должным образом. Вам было бы трудно сказать устройству изменить (или даже просто получить) конкретную запись в вашей конфигурации, если бы не было ключей. Следовательно, то, что вы предлагаете сделать, недостижимо - это не ЯН-образ вещей.

Только списки данных состояния (config false;) могут существовать без ключей, потому что их не нужно модифицировать стандартным образом — их создание/изменение/удаление регулируется деталями реализации устройства.

Кроме того, вы уже используете ключи в своем примере. «acl1» и «acl2» явно являются экземплярами списка «acl», ключи которых закодированы в их именах.

person predi    schedule 05.03.2018