요약

  • OpenConfig는 필드를 표준화하지만 terminal-device 모델은 operational-mode를 제조사별 식별자로 정의하고 지원 모드 목록에 있어야 한다고 요구한다.
  • NANOG 98 사례에서 5003은 발표자 플랫폼의 OIF 400ZR AppSel 1을 가리킨다. 범용 번호가 아니다.

5003은 자동화에 잘 맞아 보인다. 짧고 비교하기 쉽고 템플릿에 복사하기도 간단하다. 그러나 Philip Bedard의 NANOG 98 발표는 조건을 붙인다. 예시 플랫폼에서 5003은 OIF 400ZR Application Selection 1에 대응한다. 같은 슬라이드는 OpenConfig의 숫자형 operational-mode가 표준화되지 않았다고 설명하고, 실제 AppSel을 나타낼 미래 값으로 6xxx를 제시한다.

여기가 제어 경계다. OpenConfig는 공통 필드를 제공하지만 그 안의 숫자를 공통 광 네트워크 어휘로 만들지는 않는다. terminal-device 모델은 값을 제조사별 식별자로 부르고, 장비의 지원 모드 목록에 있어야 한다고 정한다. 그 목록이 대상 장비가 값을 안다는 근거다.

인벤토리에서 컨트롤러를 거쳐 라우터로 설정을 옮길 때 정의 없이 5003만 복사하면 문자열은 남아도 의도는 사라질 수 있다. 이식 가능한 기록에는 표준 또는 조직 정의 모드, 장비별 ID, 호스트/매체 인터페이스 조합, 대상의 지원 능력이 함께 있어야 한다. 로컬 표기는 적용 장비에서 해석한다.

설정 모드, 모듈 작동 상태, 광 성능 측정, 서비스 제공은 서로 다른 사실이다. 쓰기가 성공했다는 것만으로 의도한 모드나 종단 간 경로가 증명되지는 않는다.

OIF는 2026년 9월 C-CMIS 1.5를 발표해 코히어런트 모듈 관리 기능을 추가했다. 10월 30일 갱신된 IETF DWDM YANG 초안은 표준·조직 정의·명시 모드를 구분하면서 트랜시버 상호운용성을 보장하지 않는다고 밝힌다. 어휘가 정교해져도 장비별 능력과 매핑은 운영자가 유지해야 한다.

자료에는 제조사 간 이전 테스트나 ID 불일치 장애가 없다. 다만 숫자만으로 계약하면 번호가 의미보다 멀리 이동할 수 있다는 문제는 분명하다.

출처