요약

  • TLV Length 필드가 1옥텟이기 때문에 IS-IS TLV 하나의 값은 255옥텟으로 제한됩니다.
  • 동일한 타입과, 적용되는 경우 동일한 키를 가진 여러 발생(occurrence)은 하나의 IIH 또는 레벨별 LSP 세트 안에서 하나의 멀티파트 TLV(Multi-Part TLV)를 이룹니다.
  • 지원 수신자는 모든 발생을 처리하지만, 미지원 수신자는 하나를 선택하고 나머지는 무시하므로, 프로토콜 수용만으로 완전한 객체의 증거가 되지는 않습니다.

이 장애는 패킷이 유효할 수 있다는 점에서 미묘합니다. 방대한 정보 집합은 여러 발생으로 나뉘지만, MP-TLV를 지원하지 않는 수신자는 그 집합을 재구성하지 않습니다. 하나의 발생만 선택해 처리하고 나머지는 무시합니다. 그 결과 객체는 LSP가 구문 검사를 통과하고 데이터베이스에 들어갔음에도 불완전할 수 있습니다.

RFC 9885는 그룹화 규칙으로 이 문제를 다룹니다. 동일한 TLV 타입을 가지고, TLV 사양이 키를 제공하는 경우 동일한 키를 가진 발생들은 하나의 멀티파트 TLV로 처리됩니다. 이 규칙은 IIH 또는 레벨별 LSP 세트에 적용됩니다. 키는 RFC 9885가 재정의하지 않으며, 개별 TLV가 지정한 키 그대로 유지됩니다. MP-TLV 지원은 기존 TLV 인코딩도 그대로 둡니다. 이는 재조립 및 처리 지침이지 새로운 와이어 포맷이 아닙니다.

수신자 구분이 결정적입니다. MP-TLV를 지원하는 구현은 동일한 타입과 키에 속한 모든 발생의 정보를 처리합니다. 지원하지 않는 구현은 하나의 발생만 처리하고 나머지는 무시합니다. 따라서 구현은 RFC의 적용 범위 선언과 기능 광고(capability advertisement)를 통해 지원 여부와 범위를 가시화해야 합니다. 이 RFC는 배포 통제, 알림(alarm) 및 생성 제한도 다룹니다. 멀티파트 정보를 안전하게 소화할 수 없는 집단에 보내면 조용한 불완전성이 생길 수 있으므로 이러한 메커니즘이 중요합니다.

정밀한 실험용 픽스처는 인코딩된 정보가 256옥텟 이상인 하나의 객체를 사용해, 관련 TLV의 두 발생에 걸쳐 분할해야 합니다. 타입을 동일하게 유지하고, 적용되는 경우 키도 바이트 단위로 동일하게 유지합니다. 두 발생을 같은 IIH 또는 같은 레벨별 LSP 세트에 배치합니다. 지원 수신자와 미지원 수신자를 각각 따로 테스트합니다. 전자는 완전한 정보를 재구성하는 반면 후자는 하나의 발생만 유지하는지 확인합니다. 그다음 키만 바꾸고 파편들이 병합되지 않는지 검증합니다. 이 픽스처는 특정 벤더 구현을 가정하지 않고 경계, 그룹화, 미지원 동작을 테스트합니다.

Theo March 분석 — RFC 요구사항 아님:부분 배포는 단순한 호환성 체크박스가 아니라 완전성 문제로 다루어야 합니다. 운영자는 인접성이나 LSP 수용에서 완전성을 추론하기보다, 의도된 모든 발생이 수신·그룹화·반영되었다는 증거를 찾아야 합니다. 유용한 증거로는 키별 파트 수, 재구성된 길이, 폐기 또는 알림 이벤트, 변경 전후 객체 비교 등이 있을 수 있습니다. 이는 보증 관행이며, RFC 9885가 특정 텔레메트리 모델을 의무화한다는 주장이 아닙니다.

동결된 원문은 프로토콜 의미론과 배포 고려사항만을 뒷받침합니다. 현재 벤더 구현 커버리지, 배포 보급률, 관측된 운영 장애율, 또는 특정 네트워크에서의 성능·수렴 영향은 입증하지 않습니다. 이 브리핑에서 그러한 결론을 도출할 수 없습니다.

운영자 의사결정 경로:첫째, 객체가 255옥텟을 초과할 수 있는지 확인합니다. 둘째, TLV 타입과 그 자체의 키를 식별합니다. 셋째, 수신자가 광고한 MP-TLV 기능과 적용 범위를 확인합니다. 넷째, 동일 타입·동일 키 그룹화를 테스트합니다. 다섯째, 완전성 증거와 알림을 요구합니다. 여섯째, 수신 집단이 확인될 때까지 생성을 제한합니다. 마지막으로 변경 사항과 롤백 조건을 기록합니다. 어느 단계라도 알 수 없다면 생성을 비활성화하거나 호환 가능한 범위로 제한합니다.

출처