요약
- RFC 9917은 2026년 1월에 발표된 IETF Proposed Standard로, RFC 9350과 RFC 9843을 갱신합니다. 이 RFC는 링크의 역방향 방향에 대한 어드민 그룹(Administrative Group)을 Flex-Algorithm 경로 계산에 반영합니다.
- 전형적인 시나리오는 원격 수신기가 CRC 오류 같은 입력 오류를 발견하는 것이며, 운영자가 자체 기준값에 따라 역방향 엣지에 확장 어드민 그룹(Extended Administrative Group)을 설정합니다. 이후 상응하는 제약을 활성화한 승리 FAD(winning FAD)가 이를 반영하면 순방향 엣지를 제외할 수 있습니다.
- 이는 자동 장애 감지가 아니며, 물리 링크를 대칭으로 만들지도 않습니다. 안전하게 도입할 수 있는지는 텔레메트리 귀속, 설정 및 해제 기준값, 인코딩 검증, 규칙 순서, 혼합 지원, 수렴 및 롤백 증거에 달려 있습니다.
메커니즘: 역방향 증거가 순방향 토폴로지에 영향을 주는 방식
RFC 9917의 모델에서 순방향 엣지와 역방향 엣지는 경로 계산에서 각각 관찰 가능한 방향성 대상입니다. 원격 장비가 입력 방향의 오류를 감지하면, 운영 정책에 따라 이 관측을 역방향 엣지의 확장 어드민 그룹으로 매핑할 수 있습니다. 여기서 '기준값'은 운영자가 정의하는 임계값이며, RFC 9917이 운영자를 대신해 선택한 수치가 아닙니다. 또한 규격은 어떤 구현이든 인터페이스 텔레메트리를 이 마킹으로 자동 매핑한다고 보장하지 않습니다.
세 가지 제약은 각각 exclude, include-any, include-all이며, IS-IS와 OSPF 양쪽에 대해 동시에 정의됩니다. exclude는 역방향 엣지가 지정된 어드민 그룹을 갖지 않을 것을 요구하고, include-any는 지정된 집합 중 적어도 하나를, include-all은 집합 전체를 요구합니다. 이 조건들은 실제 사용 중인 승리 FAD, 배포된 규칙, 수신 장비의 구현 능력이 함께 허용하는 경우에만 관련 Flex-Algorithm 계산에 영향을 줍니다. 이들은 보편적으로 강제되는 네트워크 능력이 아니며, 모든 라우터가 각 제약을 지원한다는 증거도 아닙니다.
순서, 형식, 비정상 입력
RFC 9917은 새로운 역방향 제약을 경로 계산 규칙 8, 9, 10으로 배치하며, RFC 9350과 RFC 9843에 이미 존재하는 순차 프루닝 규칙 뒤에 이어 붙입니다. 이 등록 순서는 의미 체계의 일부입니다. 기존 규칙의 상대적 순서는 바꿀 수 없고, 규칙을 삭제하거나 병합하거나 중복할 수도 없습니다. 따라서 설정 담당자는 '동등해 보이는' 규칙을 재배열해 상호운용성 문제를 해결할 수 없습니다.
역방향 어피니티 sub-TLV의 길이 형식이 잘못된 경우 무시되며, 중복되어 나타날 때는 수신 측이 IS-IS와 OSPF 각각의 규정된 처리 동작을 수행합니다. 규격은 이러한 예외에 대한 프로토콜 처리 경계를 제시하지만, 명시되지 않은 사항을 추가적인 벤더 동작으로 확대 해석해서는 안 됩니다. 인수 검수 시에는 원시 인코딩, 파싱 결과, 중복 출현 처리, 각 노드가 최종적으로 얻는 토폴로지를 확인해야 합니다.
플러딩과 반복 재계산
오류 카운트가 기준값 부근에서 오르내리면, 역방향 어드민 그룹이 자주 설정되고 해제되어 IGP 플러딩과 반복적인 경로 재계산을 유발할 수 있습니다. RFC 9917은 서로 다른 설정(set) 및 해제(clear) 기준값을 사용해 히스테리시스를 형성하고, 일반 IGP 플러딩 스로틀링과 결합할 수 있다고 언급합니다. 이는 진동을 완화하는 제어 수단일 뿐, 특정 토폴로지의 안전 매개변수가 아닙니다. 마킹 변화, LSDB/FAD 상태, 경로 재계산 횟수, 트래픽 이동, 수렴 시간도 함께 관찰해야 합니다.
운영자의 결정
활성화하기 전에 일곱 가지 질문에 답해야 합니다. 입력 오류 텔레메트리의 소유자가 누구이며, 누가 이를 역방향 어피니티로 변환할 권한을 갖는지; 설정/해제 기준값이 설명 가능한지; RFC 7308 확장 어드민 그룹 인코딩이 종단간 검증되었는지; 관련 모든 노드가 사용하는 승리 FAD가 일치하는지; IS-IS/OSPF와 각 규칙에 대한 지원 범위가 명확한지; 최악의 경우 플러딩과 수렴이 수용 가능한지; 검증되지 않은 자동화에 의존하지 않고 마킹을 해제하고 롤백할 수 있는지입니다.
이 분석은 역방향 방향 증거를 순차적 IGP Flex-Algorithm 프루닝 입력으로만 다룹니다. 이는 RFC 9916의 PCEPS 리플레이, RFC 9915의 DHCPv6 리스 수명 주기, RFC 9914의 RPL 경로 프로젝션, RFC 9912의 RAW 복구와도 다릅니다. 이 주제들은 본문의 링크 방향, 어드민 그룹 또는 규칙 순서 증거를 대체할 수 없습니다.
증거 대장
| 주장 | RFC 근거 |
|---|---|
| 역방향 엣지의 어드민 그룹이 순방향 엣지를 프루닝할 수 있음 | RFC 9917, 요약, 1절 및 3절 |
| 원격 입력 오류, CRC 오류 예시와 역방향 확장 어드민 그룹 | RFC 9917: 사용 시나리오, 3절 |
| exclude, include-any, include-all이 IS-IS와 OSPF에 적용됨 | RFC 9917, 5~10절 |
| 잘못된 길이의 무시와 중복 출현 처리 | RFC 9917, 5~10절 |
| 규칙 8, 9, 10과 불변의 등록 순서 | RFC 9917, 11절, 12.3절, 12.3.1절 |
| Flex-Algorithm, 승리 FAD와 기존 프루닝 | RFC 9350 |
| 선행하는 대역폭, 지연, 메트릭 및 제약 | RFC 9843 |
| 확장 어드민 그룹 인코딩 | RFC 7308 |
| Proposed Standard 상태, 2026년 1월 발표 및 갱신 관계 | RFC 9917: 전면부 |
운영 인수 경로
먼저 실험 토폴로지에서 텔레메트리 소유자, 순방향·역방향 엣지 식별자, 승리 FAD를 확인합니다. 다음으로 저위험 기준값으로 설정과 해제를 각각 트리거하고, RFC 7308 인코딩, IS-IS/OSPF 파싱, 규칙 8~10의 실제 순서, 프루닝된 순방향 엣지를 검증합니다. 이어서 형식 오류와 중복 sub-TLV를 주입하고 규격이 정한 수신 동작을 기록합니다. 마지막으로 혼합 지원 노드에서 플러딩, 재계산, 수렴, 서비스 경로를 측정하고, 일반 IGP 스로틀링과 히스테리시스 효과를 검증하며, 마킹 해제, 원 FAD 복원, 정책 철회 및 증거 보존을 리허설합니다. 어느 한 단계라도 관측할 수 없다면, 결정은 '미채택 또는 격리된 파일럿에 한함'을 유지해야 하며, 결여된 증거를 지지 근거로 삼아서는 안 됩니다.
출처
회원 브리핑
프로필 심층 컨텍스트
올바른 멤버십 등급으로 로그인하면 전체 브리핑과 출처 노트를 볼 수 있습니다.
Strategic Circle 전용
Strategic Circle
모든 독자에게 공개됩니다. 가입 후 로그인하면 프로필 브리핑를 열람할 수 있습니다.
Strategic Circle 가입하기Leadership Alliance 전용
Leadership Alliance
자격을 갖춘 IP 자산 소유자 및 운영진을 위한 콘텐츠입니다. 로그인하면 Leadership Alliance 브리핑을 열람할 수 있습니다.
Leadership Alliance 가입하기





