요약

  • RFC 3139는 '골드 서비스' 정책을 예로 들어, 하나의 네트워크 수준 의도가 토폴로지, 기능, 운영 정보에 따라 서로 다른 장비에서 서로 다른 명령을 요구할 수 있음을 보여주었다.
  • 여러 번역자가 네트워크 전반에서 함께 동작할 수 있었지만, 특정 시점에 특정 장비에서 동작할 수 있는 번역자는 하나뿐이었다. 따라서 정책 승인, 로컬 번역, 동기화된 프로비저닝, 장비 확인, 실제 전달된 동작에는 각각 별도의 접수 증거가 필요했다.

'골드'는 설정이 되기 전에 약속이었다

네트워크 운영자가 한 문장을 쓴다: 이 고객 그룹에 골드 서비스를 제공하라. 이 문장은 라우터가 알아야 하는 거의 모든 것을 생략하기 때문에 간결하다. 어떤 인터페이스가 고객 트래픽을 수행하는가? 어떤 분류기가 그 트래픽을 식별하는가? 각 플랫폼에 어떤 큐가 존재하는가? 이 위치에서 '골드'를 구현하는 대역폭과 스케줄링 매개변수는 무엇인가? 지금 경로에 있는 장비는 어느 것이고, 장애 이후 인계받는 장비는 어느 것인가?

RFC 3139는 바로 이런 종류의 요청에서 출발했다. 동일한 의도된 동작이 서로 다른 벤더의 장비에서는 서로 다른 매개변수로, 라우터마다는 수많은 명령으로 번역될 수 있었다. 그 정책이 유용한 이유는 바로 이런 세부 사항들 위에 있었기 때문이고, 동시에 그것이 세부 사항 자체는 아니라는 뜻이기도 했다.

거버넌스 시스템은 '골드'를 승인할 수 있다. 정책 저장소는 그것을 저장할 수 있다. 설정 엔진은 오류 없이 컴파일할 수 있다. 그러나 그 어떤 사건도 모든 영향받는 장비가 올바른 로컬 상태를 수용했음을, 변경이 안전한 순서로 적용되었음을, 패킷이 기대한 처리를 받았음을 증명하지는 못한다.

2001년 6월 Informational 문서로 발표된 RFC 3139는 관리 프로토콜을 선택하지 않았다. IETF 작업 그룹들이 개별 기술에 맞춘 로컬 최적화된 설정 솔루션을 만들고 있다는 우려에 따라, 이 문서는 요구 사항을 수집했다. 1999년 회의는 COPS/PIB 방식과 SNMP/MIB 방식을 비교했으나 여러 질문에서 합의에 이르지 못했다. 요구 사항 팀은 그 경쟁에서 물러나, 통합 솔루션이라면 무엇이든 달성해야 하는 바가 무엇인지 물었다.

이 역사가 중요하다. 이 문서의 MUST 표현은 미래의 설정 관리 시스템이 갖추어야 할 필수 속성을 기술한 것이며, 이 메모를 인터넷 표준으로 만들거나, COPS-PR이나 SNMP가 이미 모든 요구를 충족함을 입증하거나, 배포된 결과를 보고한 것은 아니다.

세 가지 표현이 의도와 장비 사이에 놓여 있었다

RFC 3139는 장비 로컬 설정(device-local configuration)을 하나의 네트워크 장비에 고유한 데이터, 즉 가장 세밀한 설정 단위로 정의했다. 네트워크 전역 설정(network-wide configuration)은 특정 장비에 고유하지 않으면서 여러 로컬 설정을 도출할 수 있는 데이터로 정의했다. 그 위에는 정책으로 표현된 모델과 기대 동작인 고수준 설정 관리 데이터가 놓였다.

설정 데이터 번역자(configuration-data translator)는 이 계층들을 가로질렀다. 고수준 또는 네트워크 전역 데이터를 받아 일반적인 장비 기능에 따라 로컬 설정을 생성했다. 번역자는 사람일 수도, 중앙화된 소프트웨어, 중간 시스템, 또는 장비와 함께 위치한 기능일 수도 있었다. RFC는 그 역할을 규정했을 뿐, 물리적 위치는 규정하지 않았다.

번역에는 정책 텍스트 그 이상이 필요했다. RFC 3139의 다이어그램은 토폴로지 정보와 상태·성능·모니터링 정보를 이 과정에 공급했다. 번역자가 어떤 링크가 존재하는지 모른다면 이중화 경로에 대한 규칙은 올바르게 컴파일될 수 없다. 구현의 기능을 읽어내지 않고 가정한다면 큐 할당은 신뢰할 수 없다. 빠른 장애 조치 후보가 같은 장애 도메인을 공유한다면 로컬로는 타당하더라도 운영상으로는 틀릴 수 있다.

그래서 이 문서는 오류 없는 변환에 필요한 정보를 사용할 수 없을 때 이를 감지하고 그에 따라 행동할 것을 솔루션에 요구했다. 다만 그 행동 자체를 정하지는 않았다. 중단, 지연, 마지막으로 정상이었던 입력 사용, 변경 제한, 검토 요청은 서로 다른 정책이다. 침묵이 확실성으로 위장하는 것은 허용되지 않았다.

번역자는 여럿, 그러나 장비에서의 기록자는 한 번에 하나

대규모 네트워크는 모든 정책을 한 사람이 번역하는 데 의존할 수 없다. RFC 3139는 여러 번역자가 장비 집합에 대해 함께 동작하는 것을 허용했다. 하나는 사업 정책을 네트워크 전역 서비스 모델로 변환하고, 다른 하나는 기술 프로파일을 선택하고, 장비별 단계가 최종 명령을 생성할 수 있다.

그러나 이 문서는 날카로운 규칙을 부과했다: 어떤 시점에서든 특정 장비에서 동작할 수 있는 설정 데이터 번역자는 하나뿐이다. 네트워크에는 파이프라인이 있을 수 있지만, 장비는 같은 순간에 경쟁하는 작성자를 안전하게 둘 수 없었다.

이 문장은 완전히 명세된 잠금 프로토콜이 아니다. 리더십을 어떻게 선출하는지, 임대가 어떻게 만료되는지, 충돌한 번역자를 어떻게 차단하는지, 운영자가 어떻게 제어권을 회복하는지는 말하지 않는다. 이는 구현이 보존해야 하는 불변성을 선언한 것이다. 두 작성자가 서로 다른 토폴로지 스냅숏이나 정책 리비전으로부터 독립적으로 로컬 상태를 도출한다면, 각 후보는 개별적으로 그럴듯하면서도 결합된 결과는 무의미할 수 있다.

한 컨트롤러가 큐 한도를 낮추는 동안 다른 컨트롤러가 저장된 '골드' 프로파일을 복원한다고 상상해 보라. 쓰기 작업이 서로 끼어들면, 한 장비는 한 리비전의 분류기, 다른 리비전의 스케줄러, 어느 쪽에서도 온 것이 아닌 만료 시각으로 끝날 수 있다. 각 명령에 대한 성공 응답은 명령 처리를 기록할 뿐, 일관된 최종 정책을 기록하지는 않는다.

그래서 RFC 3139는 동시 공유 쓰기 접근으로 인한 잘못된 설정의 제거도 요구했다. 작성자 신원, 정책 리비전, 입력 스냅숏, 의도된 장비 집합, 배타 구간은 접수 증거에 들어가야 한다. '마지막 쓰기 우선'은 저장 순서를 정할 수 있지만, 그 설정이 원래 갖고 있어야 할 이유를 파괴할 수 있다.

하나의 정책이 장비 사이의 틈에서 실패할 수 있었다

네트워크 동작은 종종 여러 장비가 함께 변경되는 데 의존한다. RFC 3139는 필요할 때 완전하거나 부분적인 설정을 장비에 동시에, 또는 동기화된 방식으로 추가·수정·삭제·덤프·복원할 것을 요구했다. '필요할 때'라는 표현이 중요하다. 모든 업데이트가 전군 규모의 장벽을 필요로 하는 것은 아니며, 부분 변경이 자동으로 틀린 것도 아니다.

중요한 것은 의존 관계다. 새 분류기는 그 경로가 존재하기 전에는 무해할 수 있다. 그것을 보호하는 정책보다 먼저 설치된 경로는 트래픽을 새어 나가게 할 수 있다. 수신 측 큐 할당이 그것을 인식하지 못하는 코어로 서비스 등급을 보낼 수 있다. 개별적으로는 옳은 두 장비 상태가 옳지 않은 네트워크 전환을 만들 수 있다.

RFC는 오류 감지(데이터별 오류 포함)와 실패 복구(필요할 때 부적절한 부분 설정의 방지 포함)를 요구했다. 그러나 원자적 분산 커밋을 보장하지는 않았다. 준비·커밋·롤백을 위한 와이어 포맷도 없었고, '부분'의 보편적 정의도 없었으며, 모든 장비가 되돌릴 수 있다는 주장도 없었다.

따라서 운영자는 어떤 부분 집합이 안전한지, 어떤 순서가 요구되는지, 각 단계를 닫는 증거가 무엇인지 알아야 한다. '배치 완료'라는 컨트롤러 메시지는 오케스트레이션 주장이다. 장비 확인 응답은 로컬 수용을 보여준다. 네트워크 스냅숏은 결과 상태를 보여준다. 패킷과 서비스 측정은 동작을 보여준다. 각 접수 증거는 서로 다른 질문에 답한다.

대안 설정은 사건 이전에 존재해야 했다

RFC 3139에는 또 하나의 요구가 있었다: 장애 시점에 많은 장비로 잠재적으로 거대한 변경을 내려받지 않고도 빠른 전환이 가능하도록 여러 장비 로컬 설정을 미리 프로비저닝하는 것. 비상 결정이 빠를 수 있었던 이유는 준비가 그보다 앞서 이루어졌기 때문이다.

후보를 미리 적재하는 것은 활성화가 아니다. 활성화하는 것은 사건 발생 시 그것이 여전히 적합했음을 증명하는 것이 아니다. 정책 리비전, 장비 인벤토리, 토폴로지 가정, 장애 조치 트리거 모두에 신원이 필요하다. 어제 옳았던 백업 설정은 링크, 고객, 기능의 변화 후에는 위험해질 수 있다.

이중화된 설정 플랫폼과 이중화된 네트워크 구성 요소도 명시적 요구였다. 이중화는 또 하나의 조율 문제를 더한다: 어느 플랫폼이 쓸 수 있는지, 그것이 어떤 스냅숏을 물려받았는지, 이전 리더가 차단되지 않은 번역자로 돌아오는 것을 어떻게 막는지. RFC는 그 필요를 명명했지만, 복제가 자동으로 안전을 만든다고 가장하지는 않았다.

피드백은 루프의 장비 부분만 닫았다

관리 시스템은 피드백을 받아야 했다: 설정 확인, 네트워크 상태, 모니터링 정보, 특정 이벤트. 피드백이 없으면 번역은 일방향 발행 시스템이다. 피드백이 있으면 의도를 장비가 보고하는 것과 비교할 수 있다.

그러나 확인에는 정확한 동사가 필요하다. 장비가 요청을 파싱했는가? 검증했는가? 후보 영역에 저장했는가? 커밋했는가? 유효하게 만들었는가? 재시작을 넘어 보존했는가? 포워딩 프로세스에 적용했는가? 서로 다른 메커니즘과 장비는 '성공'을 서로 다른 지점에 붙일 수 있다.

RFC 3139는 장비 로컬 설정, 상태, 모니터링을 네트워크 전역 설정의 맥락에서 해석하는 능력을 요구했다. 그것은 단순 수집이 아니라 재조정이다. 로컬 큐는 렌더링된 그대로 존재하면서도 경로나 고객 분류가 바뀌어 현재 네트워크 정책과 모순될 수 있다. 반대로, 로컬 편차가 공통 의도의 유효한 장비별 표현일 수도 있다.

장비로부터의 피드백은 종단 간 서비스에는 미치지 못한다. 라우터는 자신의 스케줄러를 확인하는 동안 트래픽은 다른 경로를 탈 수 있다. 모든 장비가 의도된 정책을 보고하면서도 분류기가 고객의 패킷을 놓칠 수 있다. '골드가 설치됨'과 '골드가 체감됨'은 서로 다른 관찰이다.

설정에는 시계가 있었다

RFC 3139는 유효 시각과 만료 시각을 요구했다. 일부 설정 항목은 만료되어야 했고, 다른 항목은 만료되지 않음으로 표시될 수 있었다. 이것은 시간을 권한의 일부로 만들었다.

미래 시점으로 지정된 규칙은 유효하면서 비활성일 수 있다. 만료된 규칙은 저장된 채 사용 권한 없이 남아 있을 수 있다. 시계는 어긋날 수 있다. 컨트롤러가 임시 예외가 끝났다고 믿는 동안 시간이 뒤처진 장비가 그것을 계속 적용할 수 있다. 오래된 스냅숏을 복원하면 원래 수명이 이미 지난 값을 되살릴 수 있다.

따라서 접수 증거는 값 그 이상이 필요하다. 작성 시각, 의도된 유효 시각, 만료 의미론, 장비 시계 기준, 설치된 상태, 관찰된 강제 구간이 필요하다. '설정에 존재함'은 '현재 트래픽을 지배함'을 말하지 않는다.

네트워크 전역 또는 장비 이벤트에 반응하는 동적 프로비저닝은 같은 질문을 압박 속에서 만든다. 어떤 이벤트 버전이 변경을 트리거했는가? 정책이 여전히 유효했는가? 다른 번역자가 같은 이벤트에 작동했는가? 복구 설정이 만료되었는가? 신원과 시간 없는 이벤트 주도 속도는 피드백 루프를 반복적인 진동으로 바꿀 수 있다.

추적 가능성은 정확성의 일부였다

RFC 3139는 접근 제어, 인증, 무결성 검사, 재생 공격 방지, 그리고 필요할 때 기밀성을 갖춘 보안 프로비저닝을 요구했다. 호스트 수준 제어가 최소였고, 사용자 또는 역할 기반 제어가 권한을 구분해야 했다. 또한 호스트와 사용자 단위로 변경을 추적하는 기능을 요구했다.

이것들은 장식적 보안 기능이 아니다. 설정 값은 누가 쓸 수 있었는지, 어느 번역자 인스턴스가 작동했는지, 어떤 입력 리비전을 사용했는지, 메시지가 최신인지와 분리해서 평가할 수 없다. 승인되지 않은 프로세스가 만든 구문상 올바른 '골드' 큐는 여전히 잘못된 상태 전환이다.

재생 방지는 한때 정당했던 설정에서 특히 중요하다. 오래된 서명된 정책을 다시 적용하면 폐기된 토폴로지 가정이나 만료된 예외를 복원할 수 있다. 인증은 누가 보냈는지에 답한다. 무결성은 변경 여부에 답한다. 최신성과 승인은 그 발신자가 지금 이 변경을 할 수 있는지에 답한다.

추적은 복구도 지원한다. 장비들이 어긋날 때, 운영자에는 diff만이 아니라 인과 사슬이 필요하다. 어느 고수준 정책이 바뀌었는가? 어느 네트워크 전역 투영이 컴파일되었는가? 어느 번역자가 각 장비를 담당했는가? 어느 로컬 후보가 생성되었는가? 어느 명령이 수용되었는가? 다음 작성자가 시작하기 전에 어느 피드백이 도착했는가?

확장 가능성은 보이지 않는 재해석을 뜻하지 않았다

RFC 3139는 데이터 모델, 메시지 유형, 데이터 유형이 진화함에 따른 유연성을 요구했다. 상호 운용성 실패나 배포된 대규모 장비의 교체 없이 변화하기를 원했다. 또한 관리 경험을 버리는 대신 MIB와 SMI로부터의 지식을 활용할 것을 요구했다.

진화는 그 자체의 번역 경계를 만든다. 새 모델 요소는 오래된 번역자에게 알려지지 않을 수 있다. 장비는 필드를 이해하면서도 더 좁은 기능으로 구현할 수 있다. 컨트롤러는 렌더링할 수 없는 것을 생략할 수 있다. 결과 로컬 설정은 문법적으로 유효하면서 불완전한 의도일 수 있다.

따라서 안전한 확장은 기능 발견, 알려지지 않은 것에 대한 명시적 처리, 가시적인 성능 저하가 필요하다. RFC는 모든 오래된 장비가 모든 새 정책을 실현할 수 있다고 약속하지 않았다. 침묵 속에서 동등함을 가장하지 않고 진화할 수 있는 시스템을 요구했다.

이후의 프로토콜들이 일부 경계를 구체화했다

RFC 3535로 보고된 2002년 IAB 네트워크 관리 워크숍은 실제 업무에 더 적합한 설정 메커니즘과 설정 데이터와 운영 데이터의 더 명확한 구분에 대한 운영자들의 요구를 기록했다. 이후 NETCONF는 설정 데이터스토어에 대한 작업, 잠금, 검증, 커밋, 오류 보고를 정의했다. 네트워크 관리 데이터스토어 아키텍처(NMDA)는 의도된 설정과 적용된 설정, 운영 상태를 구분했다.

이러한 발전들은 RFC 3139의 경계들이 계속 되풀이되었음을 보여준다. 그러나 2001년의 요구 사항이 이미 NETCONF의 잠금, 후보 데이터스토어, NMDA 재조정을 갖추고 있었다는 증명은 아니다. 이후의 정밀성을 역사적 구현 증거로 소급해서 투사해서는 안 된다.

지속되는 교훈은 원래의 추상에서 나온다. 정책은 전 세계적으로 이해 가능하면서도 로컬에서 실행 불가능할 수 있다. 번역자는 낡은 사실로부터 유효한 명령을 만들 수 있다. 장비는 그 명령을 수용하면서도 약속된 서비스를 전달하지 않을 수 있다. RFC 3139는 '골드'가 그 단계들을 건너뛰는 것을 허용하지 않았다.

네트워크 정책은 무엇이 참이어야 하는지를 말했다. 규율 있는 번역, 배타적 쓰기, 조율된 적용, 피드백, 관찰만이 무엇이 참이 되었는지 보여줄 수 있었다.