요약

  • RFC 9933은 SR-Algorithm 값을 PCEP 경로와 제약 조건에서 볼 수 있게 합니다. 값 128–255의 경우, PCE는 여전히 승자가 된 Flexible Algorithm Definition, 그 메트릭, 제약 조건, 참여 노드 및 토폴로지 속성을 해석해야 합니다. 따라서 와이어에서 보이는 번호는 경로를 만들어낸 정책의 내구성 있는 지문이 아닙니다.
  • 운영자에게 필요한 것은 더 큰 라우팅 패킷이 아니라 정책 해석 영수증입니다. 중요한 계산마다 승자 FAD와 그 광고자 및 범위, 메트릭 사전, 순서화된 가지치기 규칙, 토폴로지 스냅샷, 완화된 모든 제약을 바인딩해야 합니다. 이는 민감한 네트워크 지도를 공개하지 않으면서 검토 가능성을 보존합니다.

6주 간격으로 캡처된 두 개의 경로 보고서를 상상해 보십시오. 둘 다 SR-Algorithm 130을 보여줍니다. 둘 다 같은 PCE에서 나왔습니다. 둘 다 기능 협상을 통과했고, 인증된 전송을 거쳤으며, 구문상 유효한 세그먼트 목록을 만들어냈습니다. 알고리즘 필드가 동일하기 때문에 대시보드는 이들을 같은 색으로 칠합니다.

그러나 첫 번째 경로는 공유 위험 그룹을 피하고 지연을 최소화하도록 계산되었습니다. 두 번째 계산이 이루어지기 전에 더 높은 우선순위의 Flexible Algorithm Definition이 나타났습니다. 그 정의는 번호 130을 유지하면서 메트릭을 운영자 정의 비용으로 바꾸고, 역방향 제외를 추가했으며, 승자 정의를 지원하지 않는 한 라우터를 참여 대상에서 제외시켰습니다. 번호는 움직이지 않았습니다. 정책이 움직였습니다.

이것은 프로토콜의 실패가 아닙니다. 성공적인 추상화가 만들어낸 기록 문제입니다. 컴팩트한 식별자는 분산 시스템이 정책을 매번 수행하지 않고도 복잡한 정책을 호출할 수 있게 합니다. 그렇기 때문에 이 식별자는 운영상으로 유용합니다. 동시에 그렇기 때문에 감사자는 식별자를 결정 그 자체로 다룰 수 없습니다.

RFC 9933, “Carrying SR-Algorithm in Path Computation Element Communication Protocol (PCEP)”은 깔끔한 사례 연구를 제공합니다. 이 문서는 PCEP를 확장하여 피어들이 Segment Identifier와 연관된 알고리즘을 신호로 보내고, SR-Algorithm 제약을 요청하고, 새로운 경로 메트릭을 교환할 수 있게 합니다. 표준은 기능 검사, 오류, 계산 규칙 및 운영자 가시성에 대해 명시적입니다. 그러나 Flexible Algorithm의 경우 다른 곳에서 학습된 정책 상태에 의존합니다.

거버넌스 질문은 패킷 캡처가 끝나는 지점에서 시작됩니다: 경로가 계산된 순간 이 번호는 어떤 정의로 해석되었으며, 그 변경에 책임을 진 사람은 누구인가?

RFC 9933이 실제로 와이어에 실어 보내는 것

RFC 9933은 2026년 7월에 발행된 IETF Standards Track 문서입니다. 이 문서는 MPLS 및 IPv6 상의 Segment Routing에 대한 PCEP 확장을 갱신합니다. 새로운 Algorithm 필드는 SR-ERO 및 SR-RRO 하위 객체와 함께 전송될 수 있으며, SR-Algorithm TLV는 LSPA 객체 안에 경로 계산 제약으로 위치할 수 있습니다.

이러한 추가 사항은 실제 상호운용성 문제를 해결합니다. PCE는 더 이상 모든 SID가 기본 최단 경로 알고리즘을 의미한다고 가정할 수 없습니다. PCC는 특정 SR-Algorithm을 요청할 수 있습니다. 보고서는 세그먼트와 연관된 알고리즘을 보존할 수 있습니다. 이 문서는 또한 최소 지연, 대역폭 및 사용자 정의 메트릭을 위한 메트릭 유형을 추가합니다.

표준은 무분별한 사용을 허용하지 않습니다. 확장을 사용하기 전에 양쪽 피어 모두 지원을 광고해야 합니다. 협상된 기능 없이 기능을 사용하려는 시도는 invalid-operation 오류를 발생시킵니다. 잘못된 형식의 객체나 알 수 없는 SID에 대해서도 정의된 실패 동작이 있습니다. PCE가 요청된 제약 조합 하에서 경로를 찾을 수 없으면, 느슨한 답을 조용히 만들어내는 대신 빈 경로나 NO-PATH를 반환해야 합니다.

이것들은 강력한 프로토콜 속성입니다. 피어들이 이 기능을 이해했고 응답이 처리 계약을 준수했음을 확립합니다. 그러나 알고리즘 번호에 부착된 정책이 변경되지 않았음을 확립하지는 않습니다.

값 0과 1의 경우 주변 의미론이 등록되어 있습니다: shortest path first와 strict shortest path first입니다. 값 2–127은 표준이 관리하는 공간으로 남아 있습니다. 값 128–255는 다릅니다. 이들은 Flexible Algorithm입니다. 그 번호들은 운영자가 구축하고 광고하는 정의를 가리킵니다.

이 구분은 로그 한 줄에서 놓치기 쉽습니다. “SR-Algorithm: 130”은 완전해 보입니다. Flexible Algorithm의 경우 이것은 정책 문서라기보다 데이터베이스 키에 가깝습니다.

승자 FAD가 바로 작동 중인 정책이다

RFC 9350은 Flexible Algorithm Definition, 즉 FAD를 계산 유형, 메트릭 유형 및 제약 조건 집합으로 정의합니다. 128에서 255 사이의 구성된 번호가 그 번들과 연관됩니다. 같은 광고 범위 내의 라우터들은 포워딩이 일관되고 루프 없이 유지되도록 정의에 합의해야 합니다.

합의는 결정론적 선출을 통해 만들어집니다. 참여 라우터들은 먼저 수치적으로 가장 큰 우선순위를 가진 FAD 광고를 선호합니다. 최고 우선순위가 동률이면, 가장 큰 IS-IS System-ID 또는 OSPF Router ID를 가진 라우터의 광고를 선택합니다. RFC 9350은 그 결과를 승자 FAD(winning FAD)라고 부릅니다.

이 선출은 작동 중인 정책이 번호만으로 완전히 명명되지 않는다는 뜻입니다. 그것은 번호, 현재 광고들, 선출 규칙의 조합입니다. 새로운 고우선순위 광고는 알고리즘을 재번호화하지 않고도 승자를 바꿀 수 있습니다. 동률은 상위 수준의 경로 기록에는 보이지 않을 수 있는 발신자 신원으로 해결될 수 있습니다. 광고 라우터는 자신의 정의가 수신자에게 고려되기 위해 알고리즘에 참여할 필요조차 없습니다.

RFC 9350은 분산 컴퓨팅 문제를 신중하게 다룹니다. 노드가 선택된 정의의 계산 유형, 메트릭, 제약, 플래그 또는 하위 TLV를 지원할 수 없으면 참여를 중단하고 연관된 포워딩 상태를 제거해야 합니다. 정의 변경은 네트워크 전체의 재계산과 재수렴을 유발할 수 있습니다. 이러한 안전장치는 새로운 상태를 일관되게 만듭니다. 그러나 새로운 상태가 왜 승인되었는지에 대한 제도적 역사를 보존하지는 않습니다.

이것이 첫 번째 중요한 감사 경계입니다. 이후의 운영자는 알고리즘 130을 조회하여 유효한 현재 FAD를 볼 수 있습니다. 그러나 이는 어제의 계산에서 어떤 FAD가 승자였는지, 경쟁 광고 중 무엇이 졌는지, 변경 창구가 승인되었는지, 변경이 임시로 의도된 것인지를 드러내지 않습니다.

하나의 번호가 서로 다른 영역에서 정당하게 다른 의미를 가질 수 있다

두 번째 경계가 있습니다: 범위입니다. RFC 9350은 FAD 범위를 영역(area)으로 만듭니다. 특정 Flex-Algorithm이 모든 영역에서 동일한 정의를 가질 필요는 없다고 명시적으로 말합니다. 같은 번호가 한 영역에서는 지연을, 다른 영역에서는 대역폭을 최적화할 수 있습니다.

이 유연성은 프로토콜 내부의 모호성이 아닙니다. 각 영역에는 정의된 광고 집합과 결정론적 승자가 있습니다. 모호성은 불충분하게 명시된 기록에 존재합니다. “알고리즘 130”이라고만 말하는 보고서는 값을 해석하는 데 필요한 범위를 버린 것입니다.

이 문제는 통화 표기 없는 금액, 또는 관할권 없는 법령 번호와 유사합니다. 숫자는 정확하면서도 규칙을 식별하지 못할 수 있습니다. 도메인 간 컨트롤러, 장애 검토자 또는 용량 계획자는 값이 어떤 영역, 레벨, 정책 네임스페이스에서 해석되었는지 알아야 합니다.

RFC 9933은 다중 도메인 변동이 어렵다는 것을 인정합니다. 이 문서는 단일 종단 간 계산의 여러 부분에 걸쳐 서로 다른 SR-Algorithm 제약, 또는 서로 다른 승자 FAD 메트릭과 제약을 사용하는 것을 자신의 범위 밖으로 둡니다. 이 경계는 여러 범위를 하나의 레이블로 뭉개는 글로벌 대시보드에 대해 운영자를 더 경계하게 만들어야 합니다.

바람직한 대응은 지역적 변동을 금지하는 것이 아닙니다. 지역화된 정책이야말로 Flexible Algorithm의 목적인 경우가 많습니다. 대응은 지역적 의미가 보편적 의미로 오해되지 않도록 패킷 외부에 충분한 출처 정보를 수반하는 것입니다.

요청이 완전한 정책을 담고 있지 않다

Flexible Algorithm 값에 대해 RFC 9933은 PCE가 자신의 Traffic Engineering Database로부터 계산한다고 말합니다. 그 데이터베이스는 IGP 확장이나 BGP-LS 같은 메커니즘을 통해 학습된 FAD, 노드 참여, 애플리케이션별 링크 속성을 담고 있을 것으로 기대됩니다. 따라서 경로는 요청과 변화하는 증거 환경 양쪽의 함수입니다.

이 문서는 특히 최적화 메트릭에 대해 명확합니다. PCE는 FAD가 지정한 메트릭을 사용해야 합니다. PCC가 PCEP 요청에 최적화 메트릭을 포함하더라도 PCE는 그것을 무시해야 합니다. PCE는 PCEP 처리 규칙에 따라 FAD의 제약과 요청의 직접 제약을 모두 적용합니다. PCC는 FAD 고유의 제약을 요청에 복사해서는 안 됩니다. 그렇게 하면 바람직하지 않은 동작이 생길 수 있기 때문입니다.

이것은 좋은 프로토콜 인수분해입니다. 분산 정의 상태를 모든 요청 안에 복제하는 것을 피합니다. 동시에 이는 나중에 저장된 요청을 재생하는 것이 반드시 같은 결정을 재생하는 것은 아니라는 뜻이기도 합니다. 승자 FAD, 토폴로지 속성, 참여 노드 또는 규칙 집합이 바뀌었다면, 같은 요청이 올바르게 다른 경로를 낼 수 있습니다.

따라서 경로 보고서는 PCEP 산출물로서는 완전할 수 있지만 감사 산출물로서는 불완전할 수 있습니다. 무엇이 요청되고 반환되었는지는 보여주지만, 응답을 올바르게 만든 정책 환경은 보여주지 않을 수 있습니다.

메트릭은 숫자 안에 지역적 제도를 담는다

RFC 9843은 이 논점을 심화합니다. 이 문서는 Flexible Algorithm에 대역폭 및 지연 제약, 자동 대역폭 메트릭 계산, 일반 메트릭을 추가합니다. 또한 메트릭 유형 128–255를 운영자가 지역 사용을 위해 할당하는 의미를 위해 예약합니다.

그 지역 공간은 강력합니다. 운영자는 재무 비용, 지터, 에너지 노출 또는 표준 레지스트리가 아직 명명하지 않는 다른 속성을 모델링할 수 있습니다. 그러나 “메트릭 130”을 사용하는 경로 비용은 메트릭 130에 대한 지역 사전이 이용 가능할 때만 이해할 수 있습니다. RFC 9843은 사용자 정의 메트릭이 영역이나 레벨을 넘을 때 모든 도메인이 값에 동일한 의미를 할당해야 한다고 경고합니다.

표준화된 대역폭 메트릭조차도 정책 입력을 가집니다. 링크는 명시적 값을 광고할 수 있으며, 이는 자동 도출을 재정의합니다. 그렇지 않으면 승자 FAD가 기준 대역폭 또는 메트릭이 계산되는 임계값을 공급할 수 있습니다. 기준을 바꾸면 SR-Algorithm 번호를 바꾸지 않고도 도메인 전체의 경로 비용이 바뀔 수 있습니다.

이것은 단순한 구성 세부 문제가 아닙니다. “비용”이 지연, 용량, 돈 또는 내부 가중 혼합을 의미하도록 선택하는 일은 희소한 인프라를 배분합니다. 어떤 트래픽이 어떤 시설을 통과하는지, 어느 고장 여유가 소모되는지를 결정합니다. 메트릭 사전은 기관의 운영 정책의 일부입니다.

따라서 유용한 기록은 메트릭 유형 바이트 이상을 포함해야 합니다. 사용자 정의 메트릭의 경우 의미 버전, 단위, 정규화 규칙, 소유자, 시행 일자가 필요합니다. 자동 도출 메트릭의 경우 도출 방법과 매개변수가 필요합니다. 그렇지 않으면 이후 검토자가 산수를 재계산하면서도 그 산수가 무엇을 나타냈는지 잘못 이해할 수 있습니다.

평가자도 입력과 함께 변한다

경로 계산은 메트릭을 선택하고 최소화하기만 하는 것이 아닙니다. 정의를 위반하는 링크를 가지치기합니다.RFC 9917은 IANA “IGP Flex-Algorithm Path Computation Rules” 레지스트리를 순서화된 가지치기 규칙 집합으로 만들었습니다.

이제IANA 레지스트리는 제외된 관리 그룹, 공유 위험 그룹, include-any 및 include-all 그룹, 누락된 메트릭, 대역폭 및 지연 임계값, 역방향 관리 그룹에 대한 검사를 나열합니다. 등록 정책은 Expert Review이며 규칙 수에 고정된 상한이 없습니다.

순서화된 레지스트리는 버전이 매겨진 평가자입니다. 두 구현은 같은 FAD와 토폴로지를 가지고도 하나가 오래된 규칙 집합을 적용하거나 새로운 제약에 대한 지원이 없으면 달라질 수 있습니다. RFC 9933은 지원되지 않는 조합에 대해 계산 실패를 요구함으로써 대응합니다. 이것은 적합성을 보호하지만, 벌거벗겨진 NO-PATH 응답은 여전히 조사자에게 어떤 규칙과 어떤 증거가 마지막 후보를 배제했는지 묻게 만들 수 있습니다.

이것은 자동화된 거버넌스에서 익숙한 약점입니다. 기관은 입력과 출력을 보존하면서 평가자 역시 상태라는 점을 잊습니다. 신용 모델에는 버전이 있습니다. 제재 스크리닝에는 목록 날짜가 있습니다. 경로 계산기에는 가지치기 순서와 구현 빌드가 있습니다. 재현성은 셋 모두를 요구합니다: 입력, 정책, 평가자.

목적 함수, 알고리즘, 메트릭은 동의어가 아니다

PCEP에는 이미 또 하나의 중요한 추상화가 있습니다.RFC 5541은 최적의 후보 경로 또는 경로 집합을 선택하는 데 사용되는 목적 함수를 정의합니다. PCC는 목적 함수를 필수(required) 또는 희망(desired)으로 표시할 수 있습니다. 단순히 희망인 경우, PCE는 로컬 기능과 정책에 따라 다른 함수를 선택할 수 있습니다.

RFC 9933은 SR-Algorithm이 목적 함수를 대체하지 않는다고 직접 말합니다. 알고리즘 번호도 메트릭 유형과 같은 것이 아닙니다. 계층들은 상호작용하지만 서로 다른 질문에 답합니다:

  • SR-Algorithm은 계산 계열을 제한하고, Flexible Algorithm의 경우 FAD 네임스페이스를 선택합니다;
  • FAD는 계산 유형, 메트릭 유형, 제약을 공급합니다;
  • 목적 함수는 유효한 후보 중 PCE가 무엇을 최적화해야 하는지 지정합니다;
  • 토폴로지 데이터베이스는 현재 증거를 공급합니다;
  • 처리 규칙은 어떤 선택적 객체가 완화되거나 무시될 수 있는지 결정합니다.

이 계층 중 하나만 표시하는 운영 화면은 잘못된 확신을 부추길 수 있습니다. “알고리즘 130 성공”은 희망 목적 함수가 대체되었는지, 직접 제약이 무시되었는지, 새로운 FAD 메트릭이 엔지니어가 요청했다고 생각한 메트릭을 밀어냈는지를 드러내지 않습니다.

RFC 9753은 상태 기반 PCEP의 선택적 처리에 대한 책임성을 개선합니다. 피어들이 객체가 무시될 수 있음을 표시하는 방법과 무시된 객체가 보고되는 방법을 정의합니다. 그 처분은 증거 기록에 들어가야 합니다. 존재하지만 선택적이었던 제약은 필수였거나, 지원되지 않았거나, 아예 전송되지 않았던 제약과 제도적으로 다릅니다.

보안 전송은 정책에 버전을 매길 수 없다

RFC 9933은 PCEP를 TLS로 보호할 것을 권고하며 관련 PCEPS 지침을 인용합니다.RFC 9916은 그 보안 전송 프로파일을 현재 TLS 동작에 맞게 갱신합니다. 인증과 기밀성이 중요합니다: 공격자가 경로 요청을 재작성하거나 컨트롤러를 사칭해서는 안 됩니다.

그러나 완벽하게 인증된 메시지가 방금 변경된 정책을 호출할 수 있습니다. TLS는 보호된 세션에서 어떤 피어가 바이트를 보냈는지 증명할 수 있습니다. TLS는 어떤 변경 심의회가 FAD 우선순위 200을 승인했는지, 비용 사전이 왜 수정되었는지, 비상 정의가 지난 화요일에 만료되었어야 하는지 증명할 수 없습니다.

같은 구분이 기술 거버넌스에서 반복해서 나타납니다. 무결성은 가지고 있는 기록을 보호합니다. 그 기록이 나중에 필요할 증거를 담고 있다는 것을 보장하지 않습니다.

정책 해석 영수증

빠진 것은 모든 PCEP 패킷에 또 하나의 필수 필드여서는 안 됩니다. 라우팅 프로토콜에는 엄격한 성능, 상호운용성, 공개 제약이 있습니다. 거버넌스 기록은 운영 교환 옆에 존재할 수 있고 민감한 입력을 다이제스트로 참조할 수 있습니다.

이것을 정책 해석 영수증이라고 부릅시다. 중요한 계산 또는 정책 에포크마다 다음을 바인딩합니다:

  1. 요청 식별자, PCE 및 PCC 신원, 시간, 토폴로지 범위;
  2. SR-Algorithm 값과 그것이 나타난 위치 — SID 속성, 경로 제약, 또는 둘 다;
  3. 정규화된 승자 FAD와 그 암호학적 다이제스트;
  4. 승자 광고자, 우선순위, 동률 결정 입력, 광고 범위;
  5. 그 시점에 유효한 메트릭 사전 또는 도출 매개변수;
  6. 목적 함수 — 필수였는지, 희망이었는지, 대체되었는지 포함;
  7. 직접 PCC 제약과 모든 선택적 또는 무시된 객체의 처분;
  8. 순서화된 가지치기 규칙 레지스트리 스냅샷과 구현 버전;
  9. 토폴로지 데이터베이스, 노드 참여 집합, 관련 기능 제외에 대한 다이제스트;
  10. 결과 — ERO, 빈 ERO 또는 NO-PATH — 와 구조화된 이유;
  11. 변경 티켓, 승인 역할, 활성화 창구, 롤백 트리거, 다음 검토 일자.

영수증은 토폴로지, 상업적 링크 비용, 보안에 민감한 제외를 공개할 필요가 없습니다. 일반 뷰는 식별자, 해시, 버전, 이유 클래스, 관리 권한을 노출할 수 있습니다. 권한을 가진 감사자는 그러한 커밋먼트를 보호된 자료에 대해 검증할 수 있습니다. 목표는 급진적 투명성이 아닙니다. 통제된 검사 가능성입니다.

이 설계는 또한 두 종류의 변경을 분리합니다. 토폴로지 이벤트는 정책이 그대로인 상태에서 경로를 바꿀 수 있고, 정책 이벤트는 비슷한 토폴로지 하에서 경로를 바꿀 수 있습니다. 영수증이 둘 모두에 버전을 매긴다면, 장애 검토는 경로만으로 정책을 추론하는 대신 어느 종류가 발생했는지 알 수 있습니다.

출처