요약

  • RFC 5654는 2009년 9월의 Standards Track 문서로, Deborah Brungard가 다섯 명의 편집자 중 한 명입니다. 이 문서는 MPLS-TP 요구 사항이 구성 요소 역할을 하는 프로토콜 메커니즘과 절차의 동작에 대한 것임을 밝히고 있으며, 구현에 대한 요구 사항이 아니고 MPLS-TP 구현이 지원하는 기능에 대한 설명도 아니라고 명시합니다.
  • RFC는 전송 경로를 정적 또는 동적 구성으로 생성할 수 있음을 허용하며, 제어 평면이 없는 상태에서도 OAM과 보호를 포함해 MPLS-TP 네트워크와 그 경로가 완전히 동작할 수 있다고 말합니다. 이는 규정된 선택지이며, 특정 운영자가 설정한 경로, 트래픽, 보호 전환 또는 SLA 이행에 대한 현재 선택을 증명하는 것이 아닙니다.

프로파일은 도구 세트를 정의할 뿐 네트워크를 선택하지 않는다

‘프로파일’이라는 단어는 이미 완성된 세계의 모습, 즉 호환 기기, 정해진 토폴로지, 판매 가능한 서비스를 묘사하는 것처럼 들리기 쉽습니다. RFC 5654는 더 신중합니다. 이 문서는 MPLS Transport Profile에 대한 요구 사항을 정식화하면서, 그것이 이 프로파일을 구성하는 프로토콜 메커니즘과 절차의 동작에 관한 것임을 설명합니다. 구현에 대한 요구 사항이 아닙니다.

서론에서 이 경계는 실무적으로 다가옵니다. 이 문서는 MPLS 도구 세트에 어떤 기능이 있어야 하는지, 어떤 새로운 프로토콜 작업이 필요한지를 정의합니다. 구체적인 MPLS-TP 구현이 어떤 기능을 지원하는지는 설명하지 않습니다. 이는 Standards Track에 올라 ITU-T 작업에서 규범적으로 인용될 수 있도록 한 요구 사항 명세입니다. 공통 기준점이 중요할 수 있지만, 제품 기능 목록도, 운영 환경의 구성도, 특정 운영 방식을 선택하라고 운영자에게 명하는 것도 아닙니다.

이러한 기준점 이후에도 여러 결정이 남아 있습니다. 도구 세트는 로컬 시스템을 구축할 수 있는 능력을 말합니다. 구현에는 버전과 지원 범위, 상호 운용성 제한이 있습니다. 운영자는 토폴로지, 제공 방식, 보호 정책, 전환 일정, 서비스 경계를 선택합니다. 그다음 운영 보증은 특정 경로나 플로우가 주장된 대로 동작했는지를 관찰해야 합니다. RFC에 능력이 존재한다는 사실만으로는 이러한 후속 증거가 하나도 생기지 않습니다.

정적, 동적, 제어 평면 부재 — 서로 다른 상태들

RFC 5654는 MPLS-TP 전송 경로가 정적 또는 동적 구성으로 설정될 수 있다고 말합니다. 또한 제어 평면이 전혀 없는 상태에서도 OAM과 보호를 포함해 MPLS-TP 네트워크와 그 전송 경로가 언제든 온전히 동작할 수 있다고 규정합니다. 이 문구는 네트워크를 책임지는 주체에게 선택의 공간을 남겨두는 것이며, 이름이 지정된 네트워크의 방식을 대신 선택하지 않습니다.

제어 평면 섹션도 같은 구분을 유지합니다. MPLS-TP 네트워크는 제어 평면을 사용하지 않고도 운영 가능해야 합니다. 제어 평면을 사용하는 경우, 제어 평면 토폴로지와 데이터 평면 토폴로지의 독립성을 지원해야 하므로, 제어 평면의 장애가 곧 데이터 평면의 장애를 의미하지 않습니다. 또한 클라이언트 계층 또는 서버 계층의 특정 제어 평면과 무관하게 동작해야 합니다.

이 문구들은 무엇보다 성급한 결론을 금합니다. 동적 능력의 존재가 그것의 활성화를 증명하지 않습니다. 정적 제공의 허용이 정적 구성의 존재를 증명하지 않습니다. 두 유형의 장애를 구분할 수 있는 능력이 어느 한 평면의 현재 건강 상태를 증명하지도 않습니다. OAM이나 보호에 대한 요구 사항 역시 전환이 발생했는지, 올바르게 구성되었는지, 클라이언트 트래픽이 보호받고 있는지를 증명하지 않습니다. 각 주장에는 해당 상태가 속한 시스템의 증거가 필요합니다.

일반 규칙이 행정적 경계를 지우지는 않는다

RFC는 하나의 계층 네트워크 또는 서로 다른 계층 네트워크에 대해 서로 다른 행정 그룹이 책임질 수 있음을 인정합니다. 클라이언트 계층으로부터 MPLS-TP 계층 네트워크의 주소 체계나 토폴로지 같은 정보를 숨길 수 있어야 한다고 요구합니다. 운영자의 선택에 따라 계층 간에 SRLG나 도달 가능성 같은 제한된 요약 정보가 전달될 수 있습니다.

이것은 의도적으로 절제된 일반 규칙입니다. 경계를 가능하게 만들 뿐 경계를 없애지 않습니다. 클라이언트 계층이 하위 토폴로지 전체를 볼 권리를 자동으로 얻는 것이 아니며, 구현 자체가 운영자의 행정 모델을 드러내는 것도 아닙니다. 요약 정보가 공개되었다면 그 출처, 범위, 최신성, 정책은 여전히 검증 가능한 사실입니다. 공개되지 않았다면, RFC가 단지 허용하는 메커니즘으로부터 상상 속의 보편적 토폴로지를 재구성할 수는 없습니다.

동작하는 시스템은 자신의 영수증을 제시해야 한다

구체적인 전송 주장에는 문서 자체보다 더 긴 증거 사슬이 필요합니다. 구현 기록은 소프트웨어 버전과 지원 기능을 보여줄 수 있습니다. 관리 또는 제어 시스템은 제공 방식, 경로의 의도, 신호 처리의 작용을 보여줄 수 있습니다. 전송 평면은 설정된 상태와 카운터를 보여줄 수 있습니다. OAM은 무엇을, 언제, 어떤 종단점 사이에서 검증했는지를 기록할 수 있습니다. 보호 기록은 발동 조건, 작용, 결과를 보여줄 수 있습니다. 최종적으로는 서비스 측정만이 합의된 클라이언트 경계에서의 결과를 보여줄 수 있습니다.

RFC는 이러한 영수증 중 어느 하나도 대체하지 않습니다. 특정 시스템이 설계될 수 있는 공통 언어를 제공할 뿐입니다. RFC는 공급자의 지원 매트릭스, 인벤토리, 토폴로지, 경로, 플로우, 장애, 보호 이벤트, 클라이언트 경험을 증명하지 않습니다. 이를 그런 증거로 사용하는 것은 표준과 운영자를, 이용 가능한 능력과 실제 이루어진 도입을 혼동하는 일입니다.

여기서 Lu Heng의 최소 공통 명세와 지역화된 이후 결정 사이의 구분이 유용합니다. 공통 명세는 공통이어야 하는 것을 조율하고, 이후의 결정은 시스템을 가동하는 주체에게 남습니다. 조율 산출물은 공개되었다는 이유만으로 운영 현실이 되지 않습니다. RFC 5654의 힘은 바로 자신의 도구 세트를 보편적인 구현 지시로 바꾸지 않는 데 있습니다.

Brungard의 편집 작업은 인정하되, 남의 권한을 부여하지 않는다

RFC 5654는 Ben Niven-Jenkins, Deborah Brungard, Malcolm Betts, Nurit Sprecher, Shigeru Ueno를 편집자로 명시합니다. IETF Datatracker의 Brungard 공개 프로필은 그녀를 식별하며 편집자 초상의 기반이 된 공개 사진의 출처를 제공합니다. 이는 제한적인 귀속을 뒷받침합니다. 그녀는 공동 요구 사항 문서를 편집했습니다.

그러나 이 출처들은 그녀가 RFC를 혼자 썼거나, 후속 구현을 선택했거나, 현재의 IETF 또는 ITU-T 결정을 관리하거나, 운영자의 네트워크를 운영하거나, 전송 서비스를 보증한다는 것을 증명하지 않습니다. 정확한 귀속은 과장보다 강력합니다. 그것은 공통 기술 경계에 대한 작업을 인정하면서, 구현, 구성, 관찰, 실제 네트워크에 대한 책임을 로컬 주체에게 남겨둡니다.

증거의 경계

이 출처들은 RFC 5654의 내용과 그 안에 표현된 한계를 확립합니다. 특정 운영자의 현재 MPLS-TP 사용, 도입 위치, 실제 경로, 토폴로지, 제어 평면 상태, OAM 결과, 보호 작용, 트래픽, 클라이언트 경험은 확립하지 않습니다. 여기서 설명한 영수증 사슬은 이러한 경계에 대한 운영적 독해이며, RFC에 대한 새로운 요구 사항이 아닙니다.

출처