요약

  • RFC 9862는 SR Policy를 PCEP 연합(Association)으로, 각 후보 경로(Candidate Path)를 LSP로 표현한다. 후보 경로가 신호 단위지만, 그 신호된 선택 일부가 그 경로들을 모두 포함하는 정책을 지배한다.
  • Drop-Upon-Invalid는 후보 경로의INVALIDATIONTLV에 실려 전달된다. 어떤 후보 경로 하나라도 이 기능을 활성화하면 해당 SR Policy 전체에서 활성화되며, 그 효과는 모든 후보 경로가 무효가 된 이후에야 나타난다.
  • 정책 전체 드롭 수취 기록은 역량 협상, 완전한 후보 경로 멤버십, 구성 및 운영 플래그, 전체 무효 전환, 선택된 드롭 운반 경로, 관측된 패킷 결과를 함께 결합해야 한다. 이는 Daniel Kade의 편집상 제안이며, RFC 필드도 IETF 요구사항도 아니다.

한 경로 옆의 빨간 플래그는 국소적인 것처럼 보인다. 한 행에 놓여 있고, 하나의 LSP 객체로 도착하며, 하나의 식별자에 붙일 수 있다. 따라서 관리 시스템은 그것을 해당 경로의 속성으로 저장할 수 있다. RFC 9862는 이 저장 위치를 기술적으로 정확하게 만들면서, 단순한 해석은 틀리게 만든다.

INVALIDATIONTLV는 Drop-Upon-Invalid 구성을 후보 경로 수준에서 실어 나른다. 그러나 이 기능은 그 경로 하나만을 위해 활성화되는 것이 아니다. 어떤 후보 경로라도 구성 필드의 D 플래그를 실고 있으면, Drop-Upon-Invalid는 SR Policy 전체에서 활성화된다. 그 결과는 두 번째 조건이 참이 되기를 기다린다: 정책 내 모든 후보 경로가 무효가 되는 것이다. 그 시점에 정책은 드롭 상태에 진입하고, 이 기능이 활성화된 후보 경로 중 선호도가 가장 높은 것을 선택하며, 관련 트래픽을 계속 끌어당긴 뒤 일반적인 폴백을 허용하는 대신 헤드엔드에서 폐기한다.

하나의 객체가 지시를 실었다. 하나의 집합이 문턱을 넘었다. 정책의 동작이 바뀌었다. 패킷이 그 결과를 치렀다. 이것은 서로 다른 네 개의 범위이며, 어느 것도 다른 것으로 안전하게 대체할 수 없다.

프로토콜은 경로 단위로 말하지만 결정은 집합에 산다

세그먼트 라우팅 정책은 이미 정책 자체와 그 정책을 실현하는 방식들을 구분한다. 하나의 정책은 하나 이상의 후보 경로를 담을 수 있다. RFC 9862는 PCEP을 확장해 정책을 새로운 SR Policy 연합(SRPA)으로, 각 후보 경로를 그 연합 안의 LSP로 표현한다. 이는 이해할 수 있는 매핑이다. PCEP의 신호 단위는 LSP이므로, 후보 경로가 스피커가 광고·갱신·보고할 수 있는 대상이 된다.

이 매핑에는 증거상의 결과가 따른다. SR Policy에 관한 정보는 후보 경로 수준에서 실려 전달되며, 그 의미가 한 경로만으로는 평가될 수 없을 때도 그렇다. SRPA는 멤버들을 묶어 주지만, 하나의 LSP 기록은 관리 평면이 연합 식별자와 멤버십을 시간에 걸쳐 보존하지 않는 한 그 집합을 재구성하지 못한다.

그래서 SRPA 식별자가 중요하다. 정책은 색(color)과 엔드포인트로 식별되고, 후보 경로는 자체의 발신자(originator)와 식별자(discriminator)를 갖는다. 하나의 후보 경로는 최대 하나의 SRPA에만 속할 수 있고, 그 식별자는 PCEP 세션 내에서 안정적으로 유지되며, 정책 내부의 중복은 무효다. 이 제약들 덕분에 상관(correlation)이 가능해진다. 그러나 경로가 변경되고, 세션이 재시작되고, 텔레메트리가 경보를 낸 객체만 샘플링한 이후에는 운영자를 위해 그 상관을 대신 수행해 주지는 않는다.

RFC 9862는 또한 역량 교환을 요구한다. 양쪽 피어는 SR Policy 연합을 사용하기 전에 지원을 광고한다. 이 역량을 광고한 스피커는 자신이 발원하는 모든 SR Policy LSP에 대해 그 연합을 포함해야 한다. 별도의SRPOLICY-CAPABILITYTLV는 계산 우선순위, explicit-null 동작, 무효화(invalidation), 스테이트리스 운영에 대한 지원을 노출한다. 요구되는 협상된 역량 없이 수신된 객체는 오류이며, 피어가 그 기능을 조용히 수용했다는 증거가 아니다.

따라서 역량 증거가 답하는 것은 좁은 질문이다: 이 PCEP 세션의 양쪽 끝에 그 어휘가 존재했는가? 그것은 어떤 후보 경로가 유효했는지, 모든 멤버가 관측되었는지, 나중에 트래픽이 드롭되었는지를 증명하지 않는다.

같은 글자 D가 서로 다른 두 사실을 가리킨다

INVALIDATIONTLV에는 두 개의 플래그 필드가 있다. 구성 필드에서 D는 그 후보 경로에 Drop-Upon-Invalid가 활성화되어 있음을 뜻한다. 운영 필드에서 D는 그 동작이 실제로 활성화되어 LSP가 트래픽을 드롭하고 있음을 뜻한다. 같은 글자는 편리한 프로토콜 표기이지만, 운영 기록에서 이 두 상태는 절대로 합쳐져서는 안 된다.

구성은 의도다. 정책이 특정 장애 조건에 도달하면 무엇이 일어나야 하는지를 말한다. 운영 플래그는 그 조건 이후에 선택된 상태에 대한 보고다. 어느 쪽도 그 자체로 데이터 평면 결과를 증명하지 않는다. 패킷 카운터, 포워딩 동작, 그 상태의 지속 시간은 별개의 관측으로 남는다.

방향도 문제가 된다. PCE에서 PCC로 가는 메시지에서 구성은 클라이언트에게 그 동작을 활성화할지 비활성화할지 알려 준다. PCC에서 PCE로 가는 보고는 현재 설정과 LSP가 드롭 상태인지 여부를 모두 돌려준다. 시스템이 메시지 방향, 스피커 식별자, 타임스탬프 없이 최신 값만 저장하면, 지시를 확인 응답과, 의도된 설정을 관측된 결과와 혼동할 수 있다.

정상 동작이 반사실(counterfactual) 기준선을 제공한다. LSP가 다운되거나 무효가 되면 보통 트래픽을 더 이상 끌어당기지 않아, 트래픽이 다른 LSP나 IGP로 이동할 수 있게 한다. Drop-Upon-Invalid는 의도적으로 정반대를 한다: 헤드엔드가 트래픽을 계속 끌어당긴 뒤 폐기한다. 의도하지 않은 경로로 흘러들어가는 것이 트래픽 거부보다 나쁘다면, 이는 합리적인 안전 결정일 수 있다. 그러나 설정이 낡았거나, 범위가 잘못 지정되었거나, 오해된 경우 심각한 장애를 만들 수도 있다. 표준은 메커니즘을 제공할 뿐, 보편적인 위험 선호를 제공하지 않는다.

마지막 무효 경로가 결정적 사건이다

SR Policy는 그 모든 후보 경로가 무효일 때 무효가 된다. 이것은 집합 술어(set predicate)이며, 어떤 개별 경로도 자신에 대해 그렇게 진실로 선언할 수 있는 속성이 아니다. 첫 번째 무효 경로는 회복력을 줄일 수 있다. 두 번째는 선호되는 대안을 바꿀 수 있다. 마지막 유효 경로가 무효가 될 때 정책의 경계선을 넘는다.

그때에만 정책은 어떤 후보 경로가 Drop-Upon-Invalid를 활성화하고 있는지 확인한다. 그렇다면 정책은 드롭 상태에 진입하고, 활성화된 후보 경로 중 선호도가 가장 높은 것을 동작시킨다. RFC 9862는 PCE에 보고되는 운영 Dropping 플래그에 대해 하나의 후보 경로만 있으면 된다고 말한다. 이는 효율적인 신호 전달이다. 완전한 인과 기록이 아니다.

정책에 세 개의 후보 경로가 있다고 가정하자. 선호도가 가장 낮은 경로가 구성 D를 실고 있다. 이는 이전에 어떤 운영자가 특정 서비스에 대해 하드 실패를 원했기 때문이다. 선호도가 더 높은 두 경로는 이를 실지 않는다. 수개월 뒤 토폴로지 변화로 앞의 두 경로가 무효가 된다. 아직 하나의 경로가 유효하므로 아무것도 드롭되지 않는다. 그 마지막 경로가 실패할 때, 낮은 선호도 멤버에 붙어 있던 오래된 플래그 때문에 정책 전체 기능이 활성화된다. 드롭 운반 경로는 그때 D를 실은 경로들 중에서 선택된다. 최종 운영 D만 보는 모니터는 정책이 어디서 드롭을 보고하는지는 보여 줄 수 있지만, 어떤 지시가 정책을 이 상태에 적격하게 만들었는지, 언제 승인되었는지, 왜 그대로 남아 있었는지는 보여 주지 못한다.

선호도(preference) 역시 정확히 명명되어야 한다. 후보 경로 선호도는 최선의 경로를 선택한다; 값이 높을수록 이기며, RFC 9256은 기본값 100을 준다. RFC 9862의 계산 우선순위(computation priority)는 토폴로지 변화 이후 재계산 순서를 제어한다; 값이 낮을수록 우선순위가 높고, 조건부 기본값은 128이다. 이 숫자들은 방향이 반대인 서로 다른 대기열을 지배한다. 둘을 모두 “우선순위”라고 부르는 텔레메트리 스키마는 그럴듯하지만 뒤집힌 설명을 만들어 낼 수 있다.

부재와 로컬 재정의는 결정이지 빈 칸이 아니다

RFC 9862에는 여러 의도된 기본값이 있다. 계산 우선순위 역량이 활성화되어 있고 per-LSP TLV가 없으면 기본값은 128이다. explicit-null 레이블 정책이 없으면 로컬 구성이 결정한다. 그 explicit-null 동작은 SR-MPLS에 적용되고 SRv6에서는 무시된다; 인식되지 않는 값은 무시되며; 로컬 운영자 구성이 신호된 내용을 재정의할 수 있다.

이 규칙들은 반복되는 거버넌스 오류를 드러낸다: 누락된 필드를 “정책 없음”으로 취급하는 것이다. 때때로 부재는 기본값을 호출한다. 때때로 선택을 로컬 구성에 위임한다. 때때로 그 필드는 데이터 평면에 적용되지 않는다. 때때로 광고된 값이 운영자의 명시적 선택에 의해 대체된다. 하나의 데이터베이스 null은 이 넷을 모두 표현할 수 없다.

같은 규율이 무효화에도 적용된다. 드롭을 검토하는 운영자에게는 유효한 결정, 그 출처, 그 우선순위가 필요하다. D 플래그는 PCE로부터 받은 것인가, 로컬 구성에서 보존된 것인가, 연합 이후에 바뀐 것인가, 제거되었지만 아직 샘플링된 보고에 반영되지 않은 것인가? 어떤 소프트웨어 버전과 어떤 PCEP 세션이 그것을 해석했는가? 전체 무효 검사에 사용된 완전한 멤버십 집합이 운영자가 존재한다고 믿었던 집합과 일치했는가?

RFC 9862는 운영자가 광고된 SR Policy와 후보 경로 식별자를 볼 수 있어야 한다고 요구하고, 피어 역량과 정책에 연결된 LSP에 대한 가시성을 권고함으로써 도움을 준다. 그 가시성은 필요하다. 그러나 지속 가능한 설명은 여전히 관측들을 하나의 전환으로 결합해야 한다.

범위 확장에 대한 수취 기록

여기서 제안하는정책 전체 드롭 수취 기록(policy-wide drop receipt)은 정책 식별에서 시작한다: 각 피어에서 관측된 색, 엔드포인트, SRPA 식별이다. 관련 PCEP 세션에 대해 협상된 연합 및 무효화 역량을 기록한다. 그다음 결정에 사용된 후보 경로 멤버십 집합을 고정(freeze)한다. 각 경로의 발신자, 식별자, 선호도, 구성 D 값, 유효성 상태를 포함한다.

다음은 전환이다. 무효가 된 모든 경로에 대해 타임스탬프와 관측 출처를 기록하고, 마지막 유효 멤버가 문턱을 넘은 순간을 식별하며, 그 순간에 Drop-Upon-Invalid가 활성화되어 있던 후보 경로들을 보존한다. 드롭 운반 경로로 선택된 선호도가 가장 높은 활성화 경로, 운영 D 보고, PCE와 PCC의 메시지 방향, 의도된 상태와 보고된 상태 사이의 불일치 여부를 기록한다.

마지막으로 제어 평면 사건을 결과 증거에 결합한다. 트래픽이 계속 정책으로 스티어링되었는가? 헤드엔드 폐기를 보여 주는 카운터는 어느 것인가? 첫 드롭과 마지막 드롭은 언제 발생했는가? 트래픽은 어떤 후보 경로가 유효해졌기 때문에, 구성이 바뀌었기 때문에, 정책 멤버십이 바뀌었기 때문에, 아니면 정책 전체가 철수되었기 때문에 복구되었는가? 설정을 승인한 소유자, 그것이 보호한 예외나 서비스 등급, 검토일, 롤백 경로를 식별한다.

이 수취 기록은 토폴로지를 중앙 권위로 내보내자는 제안이 아니다. 연합과 경로 데이터는 민감한 정책 정보를 노출할 수 있으며, RFC 9862는 동일한 행정 권위 아래 있는 PCE와 PCC 사이에 TLS를 사용하는 인증·암호화 PCEP 세션에 대한 권고를 그대로 상속한다. 증거는 운영 결정에 필요한 만큼만, 범위가 지정되고 접근이 통제된 형태로 유지되어야 한다.

또한 이 수취 기록은 RFC 확장이 아니다. 이는 관리 시스템이 비트가 인코딩되는 장소와 권한이 행사되는 장소를 혼동하지 않도록 하는 편집적 방법이다.

동작 중인 코드는 패킷 수준에서 고리를 닫아야 한다

Lu Heng의 저작 속 독트린은 여기서 유용하다. 제도적 언어가 운영적 사실을 앞질어서는 안 된다는 원칙이기 때문이다. PCEP는 의도를 표현할 수 있고, SRPA는 멤버십을 정의할 수 있고,INVALIDATIONTLV는 설정을 실을 수 있다. 그 어느 관측도 그 자체로 패킷 결과가 아니다. 동작 중인 시스템이 헤드엔드가 트래픽을 계속 끌어당겼는지, 그 트래픽을 폐기했는지, 그 상태가 얼마나 지속되었는지, 무엇이 서비스를 복구했는지를 결정한다.

그렇다고 프로토콜이 무관해지는 것은 아니다. 프로토콜은 운영자에게 정확한 어휘와 예측 가능한 상태 기계를 준다. 또한 거버넌스가 존중해야 할 경계를 정의한다: IETF는 상호운용 가능한 동작을 표준화하고, 특정 서비스에 대해 제어된 드롭이 폴백보다 나은지는 운영자가 선택한다. 모니터링 시스템은 그 선택을 노출해야 하며, 조용히 내려서도 안 되고, RFC가 그 사업적 결과를 승인했다고 가장해서도 안 된다.

지속 가능한 교훈은 “중앙 통제는 위험하다”보다 좁고, “로그를 더 수집하라”보다 유용하다. 하나의 멤버가 제어를 실었지만 그 제어가 집합의 동작을 바꿀 때, 증거는 결과와 동일한 범위로 확장되어야 한다. 그렇지 않으면 모든 국소 기록은 정확할 수 있으면서도 그로부터 나온 설명은 거짓이 된다.

출처