요약

  • RFC 7149는 서비스 제공자 관점에서 컨트롤러 도달성, 부트스트랩 설계, 연속성을 제어와 포워딩의 분리에서 자동으로 따라오는 혜택이 아니라 운영 책임으로 드러내 보였다.
  • 이 메모는 IGP/BGP 없는 설계에서는 별도의 부트스트랩 프로토콜이나 네트워크가 필요할 수 있다고 보고, 운영자에게 그 비용을 기존 라우팅 시스템을 활용하는 비용과 비교하라고 요청한다. 또한 정책 결정 지점(PDP)과의 연결이 끊기더라도 기반 네트워크는 계속 동작해야 한다고 명시한다.
  • 이 RFC는 Informational 문서로서 실제 배포 현황 조사, 인터넷 표준, 실제 장애 보고가 아니라 설계 관점과 조건부 요구사항을 기술한다.

분리만으로 전부가 아니었다

소프트웨어 정의 네트워킹(SDN)은 흔히 깔끔한 분리로 소개되었다. 제어 플레인이 결정하고, 포워딩 플레인이 실행한다는 그림이다. 2014년 3월에 발표된 RFC 7149는 이러한 그림이 새로움을 과장할 수 있다고 지적했다. 라우터는 오랫동안 소프트웨어 라우팅 결정과 하드웨어 포워딩을 결합해 왔다. 더 실질적인 변화는 결정 로직을 네트워크 요소를 프로그래밍할 수 있는 논리적으로 중앙화된 개체로 옮긴 것이었다.

이러한 이동은 실용적인 의존성을 만들어냈다. 컨트롤러는 장치와 기능을 발견하고, 정책과 서비스 정보를 교환하고, 자원을 할당하고, 결정을 강제하고, 서비스가 이행되었는지에 대한 피드백을 받아야 한다. RFC 7149는 이것들을 서비스 제공자가 마주하는 네 가지 메타도메인으로 묶었다. 토폴로지 및 기능 발견, 서비스 노출 및 매개변수 협상, 동적 자원 할당 및 정책 강제, 그리고 이행 및 보증을 위한 피드백이 그것이다.

이 기능들은 네트워크 아키텍처를 제공자의 고객 약속과 연결한다. 메모의 잠정적 틀에서 서비스는 단순히 소프트웨어가 선택한 경로가 아니다. 고객과 매개변수를 협상할 수 있는 결정론적 산출물이다. 이는 유용한 관점이지만, SDN에 대해 보편적으로 채택된 정의는 아니다. 이것은 질문을 “컨트롤러가 있는가?”에서 “제공자가 합의된 서비스를 노출하고, 전달하고, 검증할 수 있는가?”로 바꾼다.

컨트롤러에는 자기 도메인으로 들어가는 경로가 필요했다

부트스트랩 문제는 이 의존성을 구체적으로 만든다. IGP나 BGP를 실행하지 않는 네트워크에서 컨트롤러는 장치를 발견하고 구성하기 위해 별도의 프로토콜이나 네트워크가 필요할 수 있다. 이러한 채널에는 비용이 따른다. 구축하고, 보안을 확보하고, 운영하고, 도달 가능하게 유지해야 한다. 이미 사용 중인 라우팅 시스템에 결정 지점을 통합하면 병렬 부트스트랩 패브릭을 피할 수 있지만, 그 설계는 해당 시스템의 동작과 경계에 묶이게 된다. RFC 7149는 제어 애플리케이션이 구성되지 않은 네트워크 위에 단순히 나타날 수 있다고 가정하기보다, 제공자가 이 대안들을 저울질하라고 요청한다.

실패 사례도 똑같이 시사적이다. 논의 중인 IGP/BGP 없는 환경에 대해 메모는 PDP와의 연결이 끊기더라도 기반 네트워크는 계속 동작해야 한다고 말한다. 이는 모든 컨트롤러 장애가 트래픽을 멈춘다는 주장도, RFC 7149가 그러한 장애를 관찰했다는 주장도 아니다. 특정 설계 선택에 대한 연속성 요구사항이다. 결정 지점을 분리한다면, 그것과의 통신이 사라졌을 때 무엇이 자율적으로 유지되는지를 명시하라는 것이다.

발견만으로 서비스가 준비되었다는 증거가 되지는 않는다. 컨트롤러는 고객 매개변수를 협상하지 않았거나, 정책을 설치하지 않았거나, 자원을 확인하지 않았거나, 보증 피드백을 받지 않은 채로도 장치를 인벤토리에 등록할 수 있다. 이 단계들을 구별함으로써 대시보드의 “연결됨” 상태가 운영 중인 서비스로 오해되지 않도록 한다.

아키텍처적 약속에서 제공자 근거로

RFC 7149는 또한 SDN에 하나의 필수 프로토콜이나 단일 전환 시점이 있다는 생각에 반대한다. OpenFlow는 하나의 도구이지 SDN의 동의어가 아니며, 기존 네트워크와 벤더 고유 시스템과의 점진적 통합을 예상한다고 말한다. 중앙 결정 개체는 단일 장애 지점이 되거나 포워딩 성능을 저하시켜서는 안 된다. 여러 PDP와 운영 관리가 메모가 제기하는 우려 사항 중 하나이다. 이는 아키텍처적 주의사항이지, 어떤 시스템이 이를 충족하는지에 대한 증거가 아니다.

이 구별은 역사적으로 중요하다. Informational RFC는 논쟁을 정리하고 운영자가 답해야 할 질문을 식별할 수 있다. 그러나 얼마나 많은 제공자가 이 아키텍처를 배포했는지, 그들의 서비스 수준 결과가 어땠는지, 특정 장애가 발생했는지는 확립할 수 없다. 이러한 주장에 필요한 근거는 배포 기록, 측정, 운영 보고서, 고객 결과물이지 메모의 발표 자체가 아니다.

따라서 이 문서의 지속적인 기여는 새로운 포워딩 원시 기능이라기보다 입증 책임의 위치가 바뀐 것이다. 프로그래밍 가능성이 네트워크의 도달성, 관측성, 폴백 동작에 대한 필요를 지워주지는 못한다. 오히려 제어 채널 자체를 서비스 설계의 일부로 만든다. 컨트롤러가 무엇을 명령할 수 있는지 묻기 전에, 제공자는 그곳에 어떻게 도달하는지, 무엇을 검증할 수 있는지, 그리고 결정 지점으로 돌아가는 경로가 사라졌을 때 네트워크가 무엇을 하는지 보여주어야 한다.

출처