요약

  • RFC 3060은 정책 주체들 — 그룹, 규칙, 조건, 액션 및 그 연관 관계 — 을 위한 재사용 가능한 정보 모델을 표준화했습니다. 저자들은 이러한 속성을 결과로 변환하는 알고리즘을 구현체에 명시적으로 맡겼습니다.
  • 이 모델은 우선순위와 액션 순서가 필수인지 권고인지를 표현할 수 있었지만, 그것이 보편적인 실행 엔진은 아니었습니다. RFC 3460이 이후 모델을 갱신하고 의사결정 전략 어휘를 추가했지만, 어느 문서도 장비들이 동일한 정책을 적용했음을 증명하지는 못합니다.

규칙은 그 의미보다 멀리 여행할 수 있다

정책 파일은 가장자리에서 다르게 동작하면서도 이식 가능해 보일 수 있습니다. 한 장비가 다른 장비와 같은 이름의 조건과 액션을 받더라도, 다음에 무엇이 일어날지 결정하기 위해 서로 다른 로컬 기능, 평가 코드 또는 설정을 사용할 수 있습니다. 바로 이 구분이 2001년 2월에 나온 정책 코어 정보 모델(PCIM) 버전 1인 RFC 3060의 핵심에 있습니다.

PCIM은 정책 정보를 하나의 구조로 기술했습니다. 그 클래스들은 정책 요소를 표현했고, 연관(association) 클래스들은 이 요소들이 서로 어떻게 관련되는지를 기술했습니다. PolicyRule은 조건과 액션을 연결했습니다. PolicyGroups는 규칙이나 다른 그룹을 조직했고, 규칙에는 우선순위를 부여할 수 있었습니다. 조건은 개별 문장에 부정을 허용하면서 OR-of-ANDs 또는 AND-of-ORs 형태로 표현될 수 있었습니다. 이러한 구성 요소들은 정책 설계자에게 규칙이 무엇을 가리키는지, 언제 적용되도록 의도되었는지를 인코딩할 방법을 제공했습니다.

그러나 그 스키마가 네트워크가 실제로 결정을 내리는 지점은 아니었습니다. RFC는 정보 모델과 그것을 해석하는 알고리즘을 구분했습니다. RFC 자신의 예시가 이 문제를 구체적으로 보여줍니다. 일반 규칙은 엔지니어링 트래픽에 Bronze 서비스를 부여하면서, 더 높은 우선순위의 예외가 특정 엔지니어 한 명에게 Gold를 부여할 수 있습니다. 모델은 이 중첩을 식별하고 우선순위를 인코딩할 수 있습니다. 그러나 구체적인 구현체가 여전히 조건을 평가하고, 순서 의미론을 적용하고, 선택된 액션을 장비별 동작으로 변환해야 했습니다.

의도된 빈 공간을 남긴 “선언적” 모델

RFC 3060은 자신의 스타일을 선언적(declarative)이라고 기술하면서도, 그 라벨의 의미를 즉시 좁힙니다. RFC는 모델이 속성과 개체를 정의하지만, 이러한 속성으로부터 결과를 산출하는 알고리즘이나 처리 단계의 순서는 정의하지 않는다고 말합니다. 원하는 액션 순서를 기록할 수 있고, 그것이 필수인지 단순 권고인지도 포함되지만, 평가 절차는 공통 정보 모델의 범위 밖에 있습니다.

이것은 하나의 공통 언어 런타임이 있다는 증거가 아니라 조심스러운 경계입니다. “조건 C가 참일 때 액션 A를 적용하라”는 선언은 C와 A에 대한 구체적인 정의가 필요합니다. 또한 누락되거나 지원되지 않는 속성, 충돌하는 정책, 로컬 예외, 장비 기능이 다를 때 무엇을 해야 하는지에 대한 규칙도 필요합니다. PCIM은 벤더 고유의 조건 및 액션 클래스를 포함한 확장 지점을 제공했습니다. 이 확장들은 모델을 적응 가능하게 만들었지만, 동시에 공유되는 기본 스키마가 로컬에서 서로 다른 의미론과 공존할 수 있음을 의미했습니다.

RFC의 설명은 이례적으로 직접적입니다. 저자들은 사람이 정의하고 진단할 수 있으면서 광범위한 장비가 처리할 수도 있는 표현을 원했습니다. 그들은 정책 관리에 대한 집단적 경험이 제한적임을 인정하고 모델을 완전하게 만들려는 시도를 경계했습니다. 대신 VPN과 QoS 같은 요구를 위한 공통 코어를 선호하며, 요구와 경험이 변함에 따라 모델이 성장할 경로를 마련했습니다.

같은 문서는 PCIM을 IETF Policy Framework Working Group과 DMTF의 Common Information Model 작업 사이에서 공유되는 노력으로 위치시켰습니다. 이후 문서들이 정보 모델을 구체적인 구현으로 매핑할 것이며, 그 한 예로 LDAPv3 기반 디렉터리를 들 것이라고 말했습니다. 이 문장은 중요합니다. 모델은 구현 경로에 대한 입력이었지, 어떤 전송 프로토콜, 디렉터리, 정책 서버 또는 라우터가 그것을 채택했다는 증거가 아니었다는 것입니다.

주변 아키텍처는 서로 다른 역할을 담당했다

이전의 정책 허용(admission) 프레임워크인 RFC 2753은 결정이 내려지는 정책 결정 지점(PDP)과 결정이 네트워크 요소에 영향을 미치는 정책 집행 지점(PEP)을 분리했습니다. 이어서 RFC 2748은 이 두 역할 사이에서 요청과 결정을 교환하기 위한 클라이언트/서버 프로토콜인 COPS를 정의했습니다. RFC 3084는 정책 정보 기반을 프로비저닝하기 위한 COPS 사용법을 명세했습니다. 이들은 인접한 아키텍처 계층을 다루지만, 어느 것도 PCIM과 혼동되어서는 안 됩니다. 전송 프로토콜, 프로비저닝된 데이터 모델, 정보 스키마는 서로 다른 질문에 답합니다.

이 분할은 측정 문제를 드러냅니다. 디렉터리에 규칙이 있을 수 있고, PDP가 그것을 평가할 수 있으며, PEP가 결정을 받을 수 있고, 라우터가 설정을 설치할 수 있습니다. 각각은 서로 다른 이벤트입니다. 저장소에서 PCIM 형태의 주체를 본다고 해서 어떤 장비가 어떤 정책 버전을 소비했는지, 결정 지점이 확장을 이해했는지, 집행 지점이 결정을 수락했는지, 패킷이 의도된 처리를 받았는지 알 수 있는 것은 아닙니다.

후속 문서는 모델을 바꿨을 뿐, 증거 기준을 바꾸지 않았다

2003년 1월에 발표된 RFC 3460은 PCIM을 갱신했습니다. 요소를 추가하고, 일부를 더 이상 사용하지 않거나 대체했으며, 규칙 우선순위의 표현 방식을 바꾸고, 관리자가 지정한 의사결정 전략을 도입했습니다. 이것은 정보 모델의 실제 진화였습니다. 이는 또한 이전의 어휘가 고정되지 않았음을 보여줍니다. 이후의 정책 작업은 규칙 집합과 평가 선택을 표현하는 구조를 수정할 수 있었습니다.

그러나 후속 문서만으로 일관된 실행이 증명되지는 않습니다. 의사결정 전략 필드를 명세하는 것은 모델에 어떤 선택을 표현할 수 있는지를 알려줄 뿐, 두 구현체가 동일하게 평가하는지, 같은 확장을 지원하는지, 같은 포워딩 동작을 설치하는지는 증명하지 않습니다. RFC 3198은 이후 비즈니스 수준의 정책 추상화와 장비별 파라미터를 구분하고, 이 둘 사이의 번역에는 외부의 기능과 설정 정보가 필요할 수 있다고 지적했습니다. 공유된 표현은 모호성을 줄일 수 있지만, 그 번역 작업을 없애지는 못합니다.

따라서 역사적 주장은 좁게 유지되어야 합니다. RFC 3060은 다양한 관리 환경에서 정책 정보를 재사용 가능하게 만들려는 시도를 문서화했습니다. 저자들은 또한 그 한계를 문서화했습니다. 공통 주체가 보편적인 알고리즘과 동등하지는 않았다는 것입니다. 표준 기록이 확립하는 것은 모델과 그 이후의 개정이며, 어떤 벤더가 이를 구현했는지, 얼마나 많은 네트워크가 사용했는지, 그들의 결정이 실제 운영에서 상호운용되었는지는 아닙니다.

오래 지속되는 교훈은 전체 체인을 요구하는 것입니다. 어떤 스키마와 확장이 존재했는가? 결정 지점이 어떤 정책 버전을 평가했는가? 어떤 알고리즘이 중첩과 순서를 해결했는가? 집행 지점이 무엇을 설치했는가? 네트워크는 실제로 무엇을 했는가? 상호운용 가능한 정책 기술은 가치가 있을 수 있습니다. 그러나 그것은 상호운용 가능한 결과에 대한 영수증은 아닙니다.

출처