요약

  • Rob Shakir는 현재 IETF Datatracker 기록에서 9개의 RFC에 저자로 이름을 올리고 있다. 관련 문서들은 라우팅 요구사항, 복원력 사용 사례, 세그먼트 라우팅 아키텍처, MPLS 데이터 플레인, OSPF 확장에 걸쳐 있다. 이 기록은 협력적 표준화 작업의 역사를 뒷받침한다. 그가 세그먼트 라우팅, OpenConfig, YANG 또는 벤더 중립적 네트워크 관리를 발명했다는 주장까지는 뒷받침하지 않는다. [1]
  • 그의 OpenConfig 작업은 전혀 다른 형태의 기여를 드러낸다. 네트워크 인스턴스와 경로 재분배 문서들은 포워딩 테이블, 스위칭 컨텍스트, 경로의 이동을 서로 다른 벤더가 만든 장치에 매핑될 수 있는 방식으로 기술하려고 시도한다. 이 설계는 장치들이 동일하지 않기 때문에 정확히 유용하다. 공통 모델은 그 차이를 지우지 않는다. 운영자가 의도를 공유된 위치에서 진술하고, 플랫폼이 지원할 수 없을 때 명시적 거부를 받을 수 있게 해준다. [7] [8] [9]
  • 가장 강력한 결정 패턴은 실패 시 닫힘(fail-closed) 기술이다. OpenConfig의 재분배 지침은 특정 임포트 정책도 기본 임포트 정책도 존재하지 않으면 경로를 재분배해서는 안 된다고 규정한다. RFC 8402 역시 신뢰 경계와 명시적 세그먼트 정보에 대한 필터링 요구사항을 규정한다. 두 경우 모두 공유 기술은 무엇이 일어나도 되는지뿐 아니라 무엇이 일어나서는 안 되는지를 정의하기 때문에 가치가 있다. [4] [8]
  • 이 작업에는 눈에 보이는 인수인계도 담겨 있다. Shakir와 관련된 초기 네트워크 모델 초안들은 만료되었고, 현재의 IETF BGP YANG 모델은 다른 저자 그룹 아래서 계속 진행 중이며 아직 작업이 완료되지 않았다. 이것이 초기 설계 전부가 살아남았다는 증거는 아니다. 인프라 지식은 원래 기여자들을 넘어 이동하고 수정에 열려 있을 수 있다는 증거다. [1] [9] [10] [11] [12]

그 결과는 유명인 이야기가 아니라 운영 연속성에 관한 인물 수준의 이야기다. Shakir의 기여는 다른 사람들이 읽고, 구현하고, 거부하고, 개정하고, 이어받을 수 있는 문서들 안에 자리한다. 한계 역시 똑같이 공개적이다. 모델은 벤더의 동작을 보장할 수 없고, 표준은 배포를 증명할 수 없으며, 경로 기술은 독립적인 운영자의 정책을 대신 결정할 수 없다.

문제는 두 대의 올바른 라우터가 용어를 두고 갈라질 때 시작된다

두 제조사의 라우터로 이루어진 네트워크를 상상해 보라. 두 장치 모두 목적지 테이블을 가질 수 있다. 두 장치 모두 BGP, 즉 독립 운영되는 네트워크들이 서로 어떤 인터넷 주소에 도달할 수 있는지 알려주는 프로토콜로부터 경로를 학습할 수 있다. 두 장치 모두 고객을 별도의 가상 라우팅 컨텍스트에 둘 수 있다. 트래픽 수준에서는 두 장치가 비슷한 일을 수행할 수 있다.

그러나 관리 수준에서는 그 일을 서로 다르게 노출할 수 있다. 한 시스템은 설정을 인터페이스 아래에 두는 반면, 다른 시스템은 가상 라우팅 인스턴스 아래에 둘 수 있다. 한 장치는 라우팅 프로토콜마다 별도의 테이블을 유지하는 반면, 다른 장치는 여러 프로토콜로부터 학습한 경로를 하나의 공유 테이블에 넣을 수 있다. 한 장치는 지원하지 않는 기능을 요청받으면 구조화된 오류를 반환하는 반면, 다른 장치는 요청을 수락한 뒤 벤더 고유의 관례에 따라 해석할 수 있다.

수작업으로 일하는 엔지니어는 그 차이를 익힐 수 있다. 팀은 별도의 런북을 유지하고 별도의 명령을 사용할 수 있다. 어려움은 네트워크를 자동화하고, 감사하고, 다른 그룹에 넘겨야 할 때 커진다. 프로그램은 라우터 A에서 쓰인 단어가 라우터 B에서는 약간 다른 범위를 가진다는 사실을 사람이 기억해 주기를 기대할 수 없다. 의도와 상태에 대한 안정적인 기술이 필요하다. 그 기술은 트래픽을 실수로 이동시키지 않을 만큼 정밀해야 하면서, 동일한 내부 설계도에서 태어나지 않은 장치에도 매핑될 만큼 넓어야 한다.

여기서 데이터 모델이 이야기에 등장한다. 데이터 모델은 설정 그 자체가 아니다. 네트워크 요소가 무엇을 담고 있고 운영자가 그것에게 무엇을 하기를 원하는지 말하는 구조화된 어휘다. 많은 네트워크 관리 시스템이 사용하는 YANG 모델링 언어에서 이 어휘는 트리로 배열된다. 자동화 시스템은 그 트리의 경로를 주소 지정하고, 값을 설정하고, 운영 상태를 읽을 수 있다. 기대는 공유된 트리가 서로 다른 명령줄 인터페이스마다 작업을 다시 쓰지 않고 소프트웨어가 여러 플랫폼에서 작동하게 하는 것이다.

“벤더 중립”이라는 표현은 결과를 실제보다 완전해 보이게 만들 수 있다. 중립성은 하드웨어 능력이 동일해진다는 뜻이 아니다. 모델이 한 벤더의 사적 계층 구조를 네트워크를 기술하는 유일한 정통 방식으로 재현해서는 안 된다는 뜻이다. 모델은 여전히 포워딩 칩, 프로토콜 지원, 테이블 구조, 오류 동작의 차이와 마주해야 한다. 플랫폼이 원래는 유효한 모델링된 요청을 수행할 수 없을 수도 있다.

Shakir와 관련된 공개 문서들은 그 문제를 숨기지 않기 때문에 특히 유용하다. OpenConfig 네트워크 인스턴스 사용 사례 문서는 평면 스위치, 프로바이더 에지 라우터, 하이브리드 장치를 다루며, 모든 장치가 하나의 내부 구조를 가진 것처럼 가장하지 않는다. 문서는 심지어 유연한 모델이 하드웨어가 수행할 수 없는 요청을 허용할 때 장치가 어떻게 응답해야 하는지까지 다룬다. 서술된 경우, 구현은 침묵 속 편차로 지원을 주장하는 대신 요청을 거부해야 한다. [7]

그 거부는 공통 모델의 실패가 아니다. 중요한 출력이다. 명시적인 “아니오”는 운영자에게 기록하고, 테스트하고, 처리할 수 있는 사실을 준다. 침묵 속 재해석은 더 위험한 상태를 만든다. 자동화는 성공한 것처럼 보이는데 장치는 다른 일을 하는 것이다. 이 차이는 정확한 레지스트리 기록과 의례적인 서류를 가르는 차이와 같다. 가치는 기록이 실행 중인 시스템이 실제로 할 수 있는 일과 일치하는지에 있다.

이 작업에서 Shakir의 문서화된 역할에는 한계가 있다. OpenConfig 페이지는 “Rob Shakir & OpenConfig WG members”를 기여자로 명시한다. 이 표현은 중요하다. 그것은 집단적 모델과 그 설명에 대한 참여를 뒷받침한다. 그가 혼자 구조를 결정했거나, 모든 플랫폼에서 구현했거나, 운영자들이 균일하게 채택했다는 것을 입증하지는 않는다. 인물 수준의 기여는 저자 및 기여 기록에서 보인다. 운영 결과는 워킹그룹 참여자, 구현자, 벤더, 네트워크 팀 사이에 분산되어 있다.

네트워크 인스턴스는 기능이 되기 전에 경계다

2015년 OpenConfig 네트워크 인스턴스 인터넷 초안은 이 설계 문제에 대한 이른 시점의, 날짜가 찍힌 시각을 제공한다. 이 초안은 레이어 3 라우팅 항목, 레이어 2 포워딩 항목, 또는 둘 모두를 담을 수 있는 일반적 구성체를 기술한다. 일상적인 말로, 네트워크 인스턴스는 장치 안의 이름이 붙은 포워딩 세계다. 그것은 기본 라우팅 테이블, 고객의 사적 라우팅 컨텍스트, 스위칭 서비스, 또는 특정 플랫폼이 지원하는 그 조합을 나타낼 수 있다. [9]

초안은 이 모델이 서비스 프로바이더 장비와 OpenConfig 회원들의 논의를 중심으로 의도적으로 형성되었다고 밝힌다. 그 인정은 유용하다. 모델은 어디에서도 만들어지지 않는다. 그것은 기여자들이 아는 네트워크, 관리해야 하는 장치, 피하려는 실패를 반영한다. 구성체를 일반적이라고 부르는 것이 보편적이라는 뜻은 아니다. 저자들이 하나의 장치 계열에 구조를 고정하지 않고 몇 가지 공통 형태를 다룰 수 있는 기술 수준을 추구했다는 뜻이다.

이후의 OpenConfig 사용 사례 문서는 그 추상을 서로 다른 장치 유형에 대고 시험한다. 단순한 레이어 2 스위치는 하나의 전역 VLAN 공간만 필요할 수 있다. 프로바이더 에지 라우터는 서브인터페이스에서 서로 다른 서비스를 종단하고 그것들을 별도의 포워딩 컨텍스트에 넣을 수 있다. 하이브리드 장치는 일부 트래픽을 전역 컨텍스트에서 스위칭하면서 다른 트래픽을 사적 인스턴스를 통해 라우팅할 수 있다. 모델은 그 변형들을 공유된 아이디어 주위에 배치한다. 인터페이스 또는 서브인터페이스는 네트워크 인스턴스와 연관되고, 인스턴스는 그에 해당하는 포워딩 컨텍스트를 담는다. [7]

비전문가에게 가장 가까운 비유는 서로 다른 출입 규칙을 가진 방들이 있는 건물이다. 물리적 문은 한 방 또는 다른 방으로 들어갈 수 있고, 각 방은 자기만의 목적지 목록을 담을 수 있다. 모델은 모든 건물이 같은 내부 벽을 가졌다고 가정하지 않고 운영자가 방 이름을 짓고 문을 연결하게 해야 한다. 또한 두 방이 우연히 존재한다는 이유만으로 통로를 열어서도 안 된다.

마지막 지점은 경로가 테이블 사이를 이동할 때 결정적으로 중요해진다. 네트워크는 여러 라우팅 프로토콜을 돌리거나 여러 라우팅 컨텍스트를 유지하는 경우가 많다. 한 곳에서 학습한 경로를 다른 곳에서도 보이게 해야 할 수 있다. 이것을 경로 재분배라고 한다. 필요할 수 있지만, 루프를 만들고, 경로를 잘못된 서비스에 노출하고, 로컬 경로를 더 넓은 광고로 바꾸는 방법이기도 하다.

OpenConfig 경로 재분배 문서는 구체적인 벤더 차이에서 출발한다. 어떤 시스템은 각 프로토콜이 자기만의 라우팅 정보 베이스를 갖는 것으로 다루고, 어떤 시스템은 여러 프로토콜이 공통 테이블에 흘러들게 한다. 공유 모델은 그 설계들 중 하나를 복제하고 다른 쪽을 틀렸다고 선언할 수 없다. 그 대신 테이블 사이의 명시적 연결을 사용해 어떤 경로가 어떤 정책 아래 이동할 수 있는지 표현한다. [8]

그 문서에서 가장 중요한 문장은 편의에 관한 것이 아니다. 임포트 정책이 없고 기본 임포트 정책도 존재하지 않으면 어떤 경로도 재분배해서는 안 된다고 규정한다. [8] 다시 말해 모델의 안전한 의미는 “달리 지시받지 않으면 전부 옮긴다”가 아니라 “운영자가 규칙을 공급하기 전까지는 아무것도 옮기지 않는다”다.

이것은 운영 책임에 관한 결정이다. 모델은 모든 네트워크에 대해 어떤 경로가 정당한지 결정하지 않는다. 그 결정을 현지 운영자가 명시적으로 내리도록 요구한다. 공유 언어는 선택을 기록할 뿐, 장치를 실행하는 네트워크의 권한을 대신하지 않는다. 이것은 실용적인 형태의 분권화다. 각 운영자는 통제권을 유지하되, 선택의 구조는 소프트웨어와 사람이 검사할 수 있을 만큼 보이게 된다.

Shakir는 경로 재분배 페이지의 기여자로 명시되어 있다. 다시 말하지만 이 증거는 프로젝트 문서 안에서의 구체적 역할을 뒷받침한다. 그가 경로 재분배를 만들었거나 배포된 네트워크의 정책을 직접 선택했다는 주장이 아니다. 그 페이지의 가치는 그것이 보존하는 추론에 있다. 서로 다른 구현이 존재한다. 모델은 둘 모두에 매핑되어야 한다. 테이블 사이의 이동에는 명시적 연결이 필요하다. 정책이 없으면 경로는 열리지 않고 닫혀야 한다.

이 규칙들은 인수인계 동안 모델을 유용하게 만든다. 새 팀은 테이블 연결과 그에 연관된 정책을 검사할 수 있다. 감사자는 경로가 규칙이 허용해서 경계를 넘었는지, 아니면 장치 기본값이 오해되어 넘었는지 물을 수 있다. 자동화 시스템은 의도된 설정과 반환된 상태를 비교할 수 있다. 이것 중 어느 것도 구현이 올바르다는 것을 보장하지 않는다. 구현을 시험할 수 있는 기록을 만든다.

공통 모델은 불일치를 드러낼 때 가장 가치가 있다

네트워크 자동화는 흔히 변경을 더 빠르게 하는 방법으로 서술된다. 속도는 가치의 한 부분일 뿐이며, 그 밑에 있는 기술이 모호하면 부채가 될 수 있다. 빠른 시스템은 사람이 알아차리기 전에 수백 대의 장치에 같은 실수를 재현할 수 있다.

공통 모델은 그 전파를 멈출 몇 가지 기회를 만든다. 유형과 범위를 정의해 잘못된 값을 거부할 수 있다. 의도된 설정과 관측된 운영 상태를 분리할 수 있다. 경로가 테이블 사이를 이동하기 전에 정책 참조를 요구할 수 있다. 플랫폼이 요청을 지원할 수 없을 때 구조화된 오류를 반환할 수 있다. 두 벤더의 명령줄이 전혀 관련이 없더라도 테스트가 같은 경로를 두 벤더에 걸쳐 비교하게 할 수 있다.

이 통제들은 정직한 매핑에 의존한다. 벤더는 공유 모델을 자기 구현으로 번역해야 하고, 운영자는 모델의 어느 부분이 안전한지 결정해야 하고, 도구는 거부된 요청과 부분 지원을 다루어야 한다. 어느 층이든 모델을 마케팅 체크박스로 취급하면 겉보기 일관성이 실제 차이를 감출 수 있다.

OpenConfig 네트워크 인스턴스 페이지는 개별 스위칭 능력에 대해 모델을 지나치게 강제하지 않음으로써 이를 인정한다. [7] 그 선택에는 트레이드오프가 있다. 유연성은 하나의 구조가 더 많은 하드웨어를 커버하게 하지만, 특정 장치가 실행할 수 없는 요청도 허용한다. 제안된 답은 명시적 거부다. 모델은 능력을 보장하지 않는다. 묻고, 그 답이 아니오라는 것을 배우는 절제된 방법을 만든다.

이것은 구현 세부사항 이상이다. 정확한 운영 기록이 어떤 모습인지 정의한다. 장치가 무시했는데도 어떤 기능이 활성화되어 있다고 말하는 설정 데이터베이스는 불완전한 데이터베이스보다 나쁘다. 다음 엔지니어에게 잘못된 자신감을 준다. 상태 텔레메트리도 마찬가지다. 스키마에는 존재하지만 제대로 채워지지 않은 필드는 사고 대응 시스템을 오도할 수 있다.

gRPC Network Management Interface, 즉 gNMI에 대한 Shakir의 초기 작업도 같은 경계에 속한다. 2017년 3월에 보관된 초안은 그를 Anees Shaikh, Paul Borman, Marcus Hines, Carl Lebsack과 함께 나열한다. 이 초안은 구조화된 경로와 메시지를 사용해 네트워크 설정과 상태를 검색하고 수정하기 위한 초기 인터페이스를 기술한다. [10] 이 초안은 현재 표준이 아니며, 그렇게 제시되어서도 안 된다. 그것의 연표상 위치는 더 좁다. 기여자들이 공유 모델이 소프트웨어에서 사용 가능해질 수 있도록 하는 전송 및 조작 표면을 만들고 있었다는 것이다.

모델과 인터페이스의 구분이 중요하다. 모델은 데이터가 무엇을 뜻하고 어떻게 배열되는지 말한다. 인터페이스는 클라이언트가 데이터를 어떻게 요청하고 변경을 어떻게 보내는지 말한다. 완전한 자동화 시스템에는 둘 다, 그리고 인증, 권한 부여, 구현, 테스트, 롤백이 필요하다. 어떤 단일 문서도 그 전체 시스템을 공급하지 않는다.

Datatracker는 현재 OpenConfig gNMI, 네트워크 인스턴스, 운영 상태, 모델 카탈로그, 모델 구조 초안들을 Shakir의 만료된 인터넷 초안으로 나열한다. [1] “만료”는 “무가치”의 동의어가 아니다. 인터넷 초안은 임시 작업 문서다. 수정되거나, 대체되거나, 다른 출판 장소로 옮겨지거나, 포기될 수 있다. 만료 상태는 책임 있는 작성자가 그것들을 현재 표준이라 부르지 않게 한다. 동시에 기여자들이 풀려던 질문들의 공개적 흔적을 남긴다.

그 흔적은 유용하다. 네트워크 관리는 제품 안에 숨는 경향이 있기 때문이다. 명령이 작동할 수 있지만, 벤더가 왜 그 계층 구조를 선택했는지, 다른 구현이 어떻게 다른지는 공개되지 않는다. 공개 초안과 프로젝트 문서는 설계 논쟁의 적어도 일부를 노출한다. 이후 기여자들이 그 작업을 재사용하고, 거부하고, 재구성할 수 있게 한다. 기록은 문서가 같은 제목의 RFC가 되지 않더라도 이동 가능해진다.

세그먼트 라우팅은 질문을 장치 상태에서 경로 표현으로 옮겼다

OpenConfig 작업은 장치가 설정과 상태를 어떻게 노출하는지 다룬다. Shakir의 RFC 기록은 라우팅 도메인 안에서 경로가 어떻게 표현되는지까지 이른다. IETF Datatracker는 그를 RFC 7855, 즉 2016년 Source Packet Routing in Networking의 문제 정의 및 요구사항, RFC 8355, 즉 2018년 복원력 사용 사례, RFC 8402, 즉 2018년 세그먼트 라우팅 아키텍처, RFC 8660, 즉 2019년 MPLS 데이터 플레인 명세, RFC 8665, 즉 2019년 세그먼트 라우팅을 위한 OSPF 확장의 저자들 중 하나로 나열한다. [1] [2] [3] [4] [5] [6]

세그먼트 라우팅은 추상적으로 들릴 수 있지만 중심 아이디어는 접근 가능하다. 전통적인 트래픽 엔지니어링 시스템은 네트워크 내 여러 지점에 경로 관련 상태를 유지할 수 있다. 세그먼트 라우팅은 ingress 노드가 세그먼트라고 불리는 순서 있는 지시 목록을 표현해서 패킷을 도메인을 통해 안내하게 한다. 데이터 플레인에 따라 그 지시들은 MPLS 레이블 또는 IPv6 세그먼트 식별자로 표현될 수 있다. 네트워크에는 여전히 라우팅 프로토콜, 토폴로지 정보, 정책, 올바르게 설정된 장치가 필요하다. 세그먼트 라우팅은 일부 경로 의도가 표현되는 위치를 바꾸지만, 운영 책임을 제거하지 않는다.

RFC 8402는 집단적 작업이다. 저자 목록에는 Clarence Filsfils, Stefano Previdi, Les Ginsberg, Bruno Decraene, Stephane Litkowski, Rob Shakir가 포함되며, 추가 기여자와 검토자도 명시한다. [4] 그 구조 자체가 증거의 일부다. 독립적인 구현들에 걸쳐 사용되는 아키텍처는 한 사람의 사적 아이디어로는 신뢰할 수 없다. 검토, 프로토콜 상호작용, 보안 분석, 운영자와 벤더의 서로 다른 전제를 견뎌야 한다.

이 아키텍처는 공유 기술에 경계가 포함되어야 하는 이유도 보여준다. RFC 8402는 세그먼트 라우팅 도메인 가장자리의 라우터가 신뢰된 도메인 내부의 세그먼트와 연관된 레이블을 겨냥한 외부 트래픽을 필터링해야 한다고 규정한다. 명시적 라우팅 정보가 기본값으로 관리 도메인 너머로 새어 나가서는 안 된다고 규정한다. [4] 이것들은 장식적인 보안 메모가 아니다. 세그먼트 목록은 패킷이 어디로 가는지에 영향을 줄 수 있다. 신뢰되지 않은 트래픽이 내부 지시를 부과할 수 있다면, 운영자에게 통제를 주는 같은 메커니즘이 외부인에게 원치 않는 형태의 통제를 줄 수 있다.

이 경계는 경로 재분배 기본값과 비슷하다. 두 경우 모두, 유용한 정보는 메커니즘이 존재한다는 이유만으로 한 컨텍스트에서 다른 컨텍스트로 넘어가서는 안 된다. 임포트 정책은 경로가 테이블 사이를 이동하는 것을 허가하고, 도메인 경계는 외부 트래픽이 내부 세그먼트 지시를 사용할 수 있는지 통제한다. 표준이나 모델은 문을 기술하고, 운영자는 그것을 구현할 책임을 유지한다.

RFC 8660과 RFC 8665는 아키텍처가 어떻게 더 구체해지는지 보여준다. 하나는 MPLS 데이터 플레인과의 운용을 설명하고, 다른 하나는 세그먼트 라우팅 정보를 광고하는 OSPF 확장을 정의한다. [5] [6] 아키텍처만으로 라우터가 상호운용 가능해지지는 않는다. 프로토콜에는 독립적인 구현들이 따를 수 있는 인코딩, 광고, 오류 동작이 필요하다. 추가 문서 하나하나가 모호성을 좁히면서 동시에 구현이 불완전하거나 틀릴 수 있는 또 하나의 지점을 만든다.

Shakir의 기여는 이 층들에 걸친 공동 저자십을 통해 보인다. 기록은 그를 단독 설계자로 보여주지 않고, 어떤 단락이 누구에게서 나왔는지도 보여주지 않는다. 더 유용한 주장을 뒷받침한다. 그는 문제 정의, 복원력 질문, 아키텍처, 프로토콜별 세부사항을 연결하는 협력적 작업의 집합에 참여했다.

그 연속을 채택 이야기로 바꾸고 싶은 유혹이 있다. 이 글의 출처들은 그것을 허락하지 않는다. 출처들은 프로덕션 배포를 세지 않고, 장애율을 비교하지 않고, 특정 텍스트 때문에 신뢰성이 개선된 사적 네트워크를 식별하지도 않는다. Standards Track 상태는 문서가 IETF 프로세스를 통과했다는 뜻이지, 모든 벤더가 구현했고 모든 운영자가 올바르게 활성화했다는 뜻이 아니다. 공개 결과는 명세와 그것이 규정한 경계다.

복원력은 승리 선언이 아니라 선택의 집합이다

RFC 8355는 복원력을 보장된 속성이 아니라 사용 사례의 집합으로 기술하기 때문에 특히 가치가 있다. 이 문서는 경로 보호, 무관리 및 관리형 로컬 보호, 루프 회피, 여러 보호 기법의 공존을 다룬다. [3]

이 범주들은 네트워크가 실패를 준비할 수 있는 서로 다른 지점들을 기술한다. 로컬 수리는 근처 라우터가 중앙 컨트롤러를 기다리지 않고 실패한 링크를 우회해 트래픽을 옮기게 할 수 있다. 관리형 접근은 특별히 계획된 우회를 설치할 수 있다. 네트워크는 여러 방법을 조합할 수 있지만, 그 상호작용은 복잡성을 만들 수 있다. 루프 회피가 중요한 이유는 실패 쪽으로 트래픽을 되돌려 보내는 수리가 상황을 악화시킬 수 있기 때문이다.

공개 프로필에서 중요한 사실은 Shakir와 다른 저자들이 “네트워크를 복원력 있게 만들었다”는 것이 아니다. RFC는 그것을 증명할 수 없다. 뒷받침되는 사실은 그들이 세그먼트 라우팅 환경에서 보호의 사용 사례와 제약을 문서화했다는 것이다. 이 차이는 기술적 정확성과 기여 표기를 모두 보호한다. 장비 벤더가 메커니즘을 구현하고, 운영자가 설계와 임계값을 선택하고, 네트워크 팀이 실패 동작을 테스트하고, 트래픽 결과는 토폴로지, 설정, 소프트웨어, 실제 사건에 달려 있다.

같은 주의가 무관리(management-free) 보호에도 적용된다. 그 이름은 관리가 더 이상 필요 없다는 인상을 줄 수 있다. 문맥상 그것은 보호되는 모든 자원마다 사전 설정된 우회를 요구하지 않는 수리 방식을 기술한다. 네트워크에 계획, 모니터링, 정책이 필요 없다는 뜻이 아니다. 자동화된 로컬 대응은 여전히 올바르게 분산된 토폴로지와 세그먼트 정보에 의존한다. 포워딩 시스템의 나머지와 공존해야 한다.

이것은 Shakir의 기록에서 반복되는 교훈이다. 추상은 반복적이고 벤더별인 작업을 없앨 때 유용하다. 운영자가 추상을 책임의 부재로 오해하면 위험해진다. 모델은 같은 요청을 여러 장치에 표현할 수 있지만, 누군가는 각 장치가 그것을 어떻게 매핑하는지 검증해야 한다. 세그먼트 목록은 경로를 표현할 수 있지만, 누군가는 도메인 경계를 보호해야 한다. 복원력 메커니즘은 빠르게 반응할 수 있지만, 누군가는 그것이 올바른 실패에 반응하는지 테스트해야 한다.

공개 표준은 그 의무들을 검사 가능하게 만든다. 보안 및 관리 가능성 고려사항이 매력적인 능력과 같은 문서에 놓인다. 대안과 공존 문제가 이름 지어진다. 저자와 기여자가 나열된다. 기록은 좋은 운영을 보장하지 않지만, 운영자에게 구현이나 설계를 검토할 공통 문서를 준다.

그래서 실패와 한계는 인물 프로필에서 제거되어서는 안 된다. 그것들은 성공 이야기 뒤의 사소한 면책이 아니다. 실제 작업을 식별한다. 운영 시스템을 기술한다는 것은 안전하지 않은 입력을 어떻게 거부하는지, 능력이 없을 때 어떻게 동작하는지, 신뢰된 컨텍스트와 신뢰되지 않은 컨텍스트를 어떻게 분리하는지, 책임을 어떤 지점에서 운영자에게 넘기는지를 명시하는 것이다.

만료된 초안도 성공적인 인수인계를 보여줄 수 있다

표준화 작업은 흔히 직선으로 서술된다. 개인이 아이디어를 내고, 문서를 쓰고, 그 문서가 표준이 된다. 네트워크 모델을 둘러싼 기록은 덜 깔끔하고 더 유익하다.

2015년 네트워크 인스턴스 초안은 Shakir를 저자로 명시하며 만료되었다. [9] 2017년 gNMI 초안은 저자 다섯 명을 나열하며 역시 만료되었다. [10] 그의 Datatracker 페이지에는 수십 개의 만료된 초안이 있고, 확인 시점에는 활성 인터넷 초안이 없다. [1] 출판 상태가 유일한 척도라면 그 역사는 오랜 미완성 작업 목록처럼 보일 것이다.

그러나 그 밑에 있던 주제는 사라지지 않았다. OpenConfig는 네트워크 인스턴스와 경로 재분배에 대한 현재의 프로젝트 문서를 유지한다. [7] [8] IETF는 설정, 정책, 운영 상태를 커버하는 벤더 중립적 BGP YANG 모델에 대해 계속 작업 중이다. 확인된 2026년 6월 버전은 이종 환경을 위한 것으로, 여러 벤더의 기존 구현에 매핑되어야 한다고 명시한다. [11]

현재 BGP 모델은 현재 저자 목록에 Shakir를 넣지 않는다. 그러나 그 역사는 그와 다른 기여자들을 포함한 이전의 저자 및 게시 확인 기록을 보존한다. [12] 이것은 유용한 경계를 만든다. 현재 초안을 “Shakir의 BGP 모델”이라 부르는 것은 부정확하다. 이전 계보가 존재하지 않았던 것처럼 가장하는 것도 불완전하다.

더 흥미로운 이야기는 이동(transfer)이다. 운영용으로 의도된 모델은 첫 저자들이 영구적으로 함께 있을 것에 의존해서는 안 된다. 요구사항은 바뀐다. 워킹그룹은 갭을 찾는다. 새 프로토콜 확장이 나타난다. 검토자는 보안 또는 모델링 문제를 발견한다. 구현자는 구조가 실제 장치에 잘 매핑되지 않는다는 것을 발견한다. 다른 저자들이 다음 버전의 책임을 맡는다.

현재 초안은 완성된 표준이 아니라 인터넷 초안이다. 바뀌거나, 대체되거나, 만료될 수 있다. [11] 그 불확실성은 공개 기록의 일부다. 그것은 인수인계가 완성된 승리로 서술되지 않게 한다. 동시에 새 저자들 아래서 작업이 계속되는 것은 그 문제가 한 사람의 사적 도구 안에 갇히지 않았음을 보여준다.

이것이 문서 계층에서의 운영 연속성이다. 이름, 버전, 역사는 이후의 독자가 모델이 어떻게 이동했는지 재구성하게 한다. 만료된 초안은 날짜가 찍힌 설계를 공급하고, 프로젝트 페이지는 현재의 사용 사례를 공급하고, 워킹그룹 문서는 현재의 표준화 상태를 공급한다. 어느 것도 배포된 네트워크의 주인이 아니다. 함께 모이면 구현자와 운영자가 실행 중인 코드와 비교할 수 있는 기록이 된다.

Shakir의 인물 수준 기여는 그런 용어로 기술될 때 가장 강하다. 그는 초기 초안과 협력적 RFC 저자 목록에 나타난다. 이후의 유지자와 저자들이 관련 작업을 이어간다. 증거는 모든 편집 결정이나 문장을 밝히지 않는다. 그의 작업이 모든 현재 문서의 머리에 그의 이름을 유지하지 않고도 계속될 수 있는 공개 프로세스에 들어갔다는 것은 보여준다.

그것은 영구 소유보다 더 내구적인 영향력의 형태다. 검증하기도 더 쉽다. 독자는 개인적 비전에 관한 주장을 받아들일 필요가 없다. 버전, 저자 목록, 현재 문서는 보인다. 갭과 변화도 보인다.

공유 모델이 동일하게 만들 수 없는 것

공통 모델에 대한 가장 강력한 논거가 동시에 그 최대 리스크의 원천이다. 장치들이 서로 다르기 때문에 운영자들은 서로 다른 장치에 걸쳐 하나의 방식으로 기능을 기술하기를 원한다. 장치들이 동일했다면 추상은 불필요했을 것이다. 추상이 차이를 너무 많이 숨기면 자동화가 그 밑의 장비보다 신뢰할 수 있는 것처럼 보이게 할 수 있다.

하드웨어는 능력을 서로 다른 수준에서 노출할 수 있다. 한 플랫폼은 요청된 스위칭과 라우팅 테이블의 조합을 지원할 수 있고, 다른 플랫폼은 그렇지 않을 수 있다. 하나는 상세한 운영 상태를 제공하고, 다른 하나는 그 일부만 반환할 수 있다. 하나는 변경을 트랜잭션으로 적용하고, 다른 하나는 중간 상태를 거칠 수 있다. 공유 스키마는 의도된 결과를 이름 지을 수 있지만, 빠진 실리콘, 소프트웨어, 롤백 동작을 만들어내지는 못한다.

OpenConfig 네트워크 인스턴스 문서는 이 문제의 한 형태를 명시적 거부로 다룬다. [7] 그것은 필요하지만 충분하지 않다. 클라이언트는 그 거부를 실제 문으로 취급해야 한다. 모니터링은 그것에 경보를 발해야 한다. 변경 시스템은 대부분의 장치가 요청을 수락했다는 이유로 작업 전체를 성공으로 표시해서는 안 된다. 엔지니어는 지원되지 않는 기능이 선택사항인지, 필수인지, 근사시키기 위험한지를 이해할 방법이 필요하다.

성공적인 응답조차 모호할 수 있다. 장치는 설정을 수락하되 상태를 지연 후에 노출할 수 있다. 값을 정규화할 수 있다. 공유 필드를 서로 다른 경계 사례를 가진 벤더 메커니즘에 매핑할 수 있다. 이것이 모델 검증이 실행 중인 시스템까지 이르러야 하는 이유다. 설정 기록만으로는 트래픽이 의도된 경로를 따른다는 증거가 되지 않는다.

세그먼트 라우팅에는 나란히 놓이는 한계가 있다. 공유 아키텍처와 프로토콜 확장은 장치들이 세그먼트 정보를 교환하고 해석하게 한다. 그것들은 모든 네트워크에 대한 안전한 정책을 선택하지 않는다. 운영자가 신뢰 도메인을 정의하고, 그 경계를 필터링하고, 누가 경로를 부과할 수 있는지 통제하고, 토폴로지나 프로토콜 상태가 바뀔 때 어떻게 대응할지 결정한다. RFC 8402는 요구사항을 규정하지만, 종이 위의 요구사항은 구현과 운영을 통해서만 보호가 된다. [4]

복원력 메커니즘도 물리적 현실과 상호작용한다. 제어 시스템에 기술된 백업 경로는 기본 경로와 도관, 전원, 장치를 공유할 수 있다. 로컬 수리는 포워딩을 유지하면서 트래픽을 혼잡한 링크로 보낼 수 있다. 모델은 식별자와 정책을 노출할 수 있지만, 다른 증거 없이는 두 경로가 물리적으로 독립적이라는 것을 증명하지 못한다.

현재 BGP YANG 초안은 또 하나의 한계, 즉 폭(breadth)을 안고 있다. 확장 가능하게 유지하면서 일반적으로 배포된 BGP 기능, 정책 훅, 운영 상태를 커버하려 한다. [11] 커버하는 기능이 많아질수록 모든 구현이 모든 필드를 일관되게 해석하도록 하는 것이 더 어려워진다. 문서 자체가 검토 중이다. 그 미완성 상태는 당혹이 아니다. “표준”이라는 단어를 테스트의 대체물로 다루지 말라는 경고다.

이 한계들이 이야기를 지면에 고정시킨다. 공유 기술에 대한 Shakir의 기여는 이종 네트워크가 운영하기 어렵기 때문에 중요하다. 그렇다고 이종성을 없애지는 않는다. 모델과 아키텍처는 공개 계약을 만든다. 구현이 시험될 수 있는 이름, 유형, 관계, 기본값, 경계다. 시험은 여전히 일어나야 한다.

기여 표기는 기술 아키텍처의 일부다

이 기록의 문서들은 신용을 특이할 만큼 정밀하게 분배한다. RFC 8402는 저자 여섯 명과 추가 기여자를 명시한다. RFC 8355는 저자 네 명을 명시하고 또 한 명의 기여자를 감사한다. OpenConfig 페이지는 Shakir를 워킹그룹 회원들과 함께 크레딧한다. gNMI 초안은 저자 다섯 명을 나열한다. 현재 BGP YANG 초안은 이전 계보와 다른 활성 저자 그룹을 가진다. [3] [4] [7] [10] [11] [12]

그 목록들은 의례가 아니다. 독자에게 그 작업이 조직적이고 개인적인 경계를 넘었음을 말해준다. 라우팅 아키텍처는 기존 프로토콜과 상호작용해야 한다. 데이터 모델은 운영자와 구현을 반영해야 한다. 관리 인터페이스는 클라이언트와 서버를 지원해야 한다. 검토와 유지보수는 초기 저자가 떠난 뒤 결과를 바꾼다.

그 분배를 제거하면 기술적 서술이 약해진다. Shakir가 단독 창시자로 제시되면, 그 이야기는 공유 네트워크 인프라가 개인적 권위에서 나왔다고 시사한다. 출처 기록은 정반대를 보여준다. 공개 초안, 워킹그룹, 기여자, 검토자, 구현자, 이후 저자들이 그 기술을 한 사람의 환경 너머에서 사용 가능하게 만든다.

정밀한 기여 표기는 흔한 형태의 전기 과장에도 대항한다. RFC에 이름이 있다는 것은 IETF 기록에서 그 문서의 저자임을 증명한다. 그 사람이 모든 절을 썼고, 모든 아이디어를 시작했고, 모든 기능을 구현했고, 이후의 모든 배포를 일으켰다는 것을 증명하지 않는다. 기여자 크레딧은 문서화된 기여를 증명할 뿐, 사적 노동 분담을 밝히지 않는다. 저자 주소는 출판 시점의 소속을 기록하며, 현재 증거 없이 현재 직무로 변환되어서는 안 된다.

따라서 Shakir에 대해 가장 안전하고 가장 유익한 주장은 눈에 보이는 것들이다. IETF Datatracker는 그를 9개의 RFC와 연관시킨다. [1] 선별된 RFC들은 그를 세그먼트 라우팅 요구사항, 복원력, 아키텍처, MPLS, OSPF 작업의 집단적 저자 그룹 중 하나로 명시한다. [2] [3] [4] [5] [6] OpenConfig 페이지는 네트워크 인스턴스와 재분배 자료에서 그를 크레딧한다. [7] [8] 보관된 초안들은 네트워크 인스턴스와 gNMI에 대한 초기 작업을 기록한다. [9] [10] 현재 BGP 모델은 다른 저자들 아래서 계속되며, 그 역사는 이전 참여를 보존한다. [11] [12]

그 연속은 명확한 기여를 뒷받침한다. 운영자의 문제를 다른 사람들이 다듬고 구현할 수 있는 공개 구조로 바꾸는 일에 도움을 주었다. 그것은 성격, 사적 의도, 영웅성에 관한 주장을 요구하지 않는다. 문서들이 사안을 운반한다.

지속되는 결과물은 운영 중인 시스템과 맞닿을 수 있는 기록이다

네트워크는 두 종류의 현실을 통해 운영된다. 하나는 물리적이고 실행 가능하다. 패킷이 움직이고, 링크가 실패하고, 장치가 명령을 수락하거나 거부하고, 라우팅 테이블이 바뀐다. 다른 하나는 기술적이다. 인벤토리, 모델, 정책, 표준, 다이어그램이 시스템이 무엇을 담고 무엇을 해야 하는지 말한다.

어느 층도 홀로는 충분하지 않다. 정확한 기술 없이 실행되는 코드는 감사하고 넘겨주기 어려워진다. 실행 중인 시스템의 점검 없는 문서는 허구로 흘러간다. Shakir와 관련된 작업은 그 둘이 만나야 하는 지점에 놓인다.

네트워크 인스턴스 모델은 여러 종류의 장치가 구현을 시도할 수 있는 용어로 포워딩 컨텍스트를 기술한다. 경로 재분배 지침은 정책 경계를 기록하고 허가가 없으면 닫는다. gNMI 작업은 소프트웨어가 모델링된 설정과 상태를 어떻게 요청하는지를 다룬다. 세그먼트 라우팅 RFC들은 경로 지시와 프로토콜 확장이 어떻게 결합하는지 기술하면서 신뢰 및 필터링 경계를 규정한다. 복원력 사용 사례는 결과를 약속하지 않고 선택을 노출한다. 초안 역사는 그 기술들이 이후 유지자에게 어떻게 이동하는지 보여준다.

결과는 보편적 제어 플레인이 아니다. 독립된 네트워크는 여전히 자기 벤더, 정책, 모델, 배포 속도를 선택한다. 표준화 기구는 경로를 운영하지 않는다. 모델 저장소는 네트워크가 어떤 트래픽을 수락해야 하는지 결정하지 않는다. 가치는 조정이 소유라는 착각 없이 조정한다는 데 있다.

운영자에게 그 가치는 평범한 순간에 나타난다. 교체 라우터를 자동화가 기대하는 상태와 비교할 수 있다. 거부된 설정은 트래픽이 움직이기 전에 변경을 멈출 수 있다. 테이블 연결은 경로가 왜 다른 컨텍스트로 들어갔는지 보여줄 수 있다. 경계 규칙은 외부 트래픽이 내부 세그먼트 지시를 사용하는 것을 막을 수 있다. 새 팀은 버전 역사를 읽고 현재 모델이 오래된 초안과 다른 유지자를 가졌다는 것을 볼 수 있다.

이 순간들 중 어느 것도 전체 시스템이 안전하다는 것을 증명하지 않는다. 각각은 증거 한 조각을 만든다. 그 조각들은 장치, 경로 수집기, 변경 기록, 인시던트와 대조될 수 있다. 서로 어긋날 때, 그 불일치는 조사할 만큼 충분히 보인다.

이것이 Shakir의 문서화된 작업의 중심 한계이자 중심 성과다. 공유 모델과 표준은 현실을 강제로 따르게 할 수 없다. 네트워크 상태에 대한 주장을 시험할 만큼 구체적으로 만들 수 있다. 무엇이 거부되어야 하는지, 무엇이 신뢰 경계 안에 남아야 하는지, 로컬 정책이 어디서 시작되는지 규정할 수 있다. 저자십과 변경 역사를 보존해 기술이 인수인계를 견디게 할 수 있다.

가장 중요한 미해결 질문은 따라서 하나의 모델이 마침내 모든 라우터를 같아 보이게 할 것인지가 아니다. 운영자, 구현자, 표준화 그룹이 공유 기술을 실행 중인 동작에 충분히 가깝게 유지해서 차이가 놀람이 아니라 증거가 되게 할 것인지다. Shakir의 공개 기록은 인터넷을 위해 그 질문에 답하지 않는다. 그 질문을 정확하게 계속 물기 위해 필요한 종류의 작업을 보여준다.

출처

  1. IETF Datatracker,Rob Shakir 프로필.
  2. RFC Editor,RFC 7855: Source Packet Routing in Networking Problem Statement and Requirements.
  3. RFC Editor,RFC 8355: Resiliency Use Cases in SPRING Networks.
  4. RFC Editor,RFC 8402: Segment Routing Architecture.
  5. RFC Editor,RFC 8660: Segment Routing with the MPLS Data Plane.
  6. RFC Editor,RFC 8665: OSPF Extensions for Segment Routing.
  7. OpenConfig,네트워크 인스턴스 사용 사례.
  8. OpenConfig,네트워크 인스턴스의 경로 재분배.
  9. IETF Datatracker,draft-openconfig-rtgwg-network-instance-01.
  10. IETF Datatracker,draft-openconfig-rtgwg-gnmi-spec-00.
  11. IETF Datatracker,BGP-4를 위한 현재 YANG 모델.
  12. IETF Datatracker,BGP 모델 초안의 역사.