요약

  • RFC 8362는 Extended LSA에 OSPFv3 U 비트를 설정하여, 해당 기능을 인식하지 못하는 라우터도 인코딩된 범위에 따라 이를 저장하고 플러딩할 수 있게 합니다. 따라서 일치하는 LSDB 항목은 전달의 증거이지, 해석, 기능 활성화, SPF 사용, RIB 선택 또는 패킷 포워딩의 증거가 아닙니다.
  • Acee Lindem은 Abhay Roy, Dirk Goethals, Veerendranatha Reddy Vallem, Fred Baker와 함께 RFC 8362를 공동 저술했습니다. 이 표준은 알 수 없는 선택적 정보와 잘못된 입력도 구분합니다. 알 수 없는 TLV는 무시되지만, 잘못 인코딩된 Extended LSA는 설치, 확인 응답 또는 플러딩되어서는 안 됩니다.

하나의 데이터베이스, 서로 다른 이해

한 OSPFv3 영역에 세 라우터가 있다고 상상해 보십시오. 첫 번째 라우터는 세 번째 라우터가 지원하는 확장 기능에서 정의한 정보를 담은 Extended Router-LSA를 생성합니다. 가운데 라우터는 그 확장 기능보다 오래된 구현입니다. 이 라우터는 LSA 기능 코드를 알지 못하고, 새 필드를 해석할 수 없으며, 이를 사용해 확장 기능의 결과를 계산할 수도 없습니다. 그러나 LSA는 이 라우터를 거쳐 세 번째 라우터에 도달할 수 있습니다.

이것은 우연한 관용이 아닙니다. OSPFv3는 LS Type에 U 비트와 플러딩 범위 비트를 둡니다. RFC 5340에 따르면 U=0인 인식되지 않는 LSA는 링크 로컬 범위를 가진 것처럼 처리됩니다. U=1이면 인식되지 않는 LSA는 해당 유형에 인코딩된 범위에 따라 저장되고 플러딩됩니다. RFC 8362는 Extended LSA에 새로운 기능 코드를 부여하며, 해당 기본 기능에 10진수 32, 즉 0x20을 더하고 U 비트를 설정하도록 요구합니다.

가운데 라우터도 실제 작업을 수행합니다. LSA를 수락할 수 있을 만큼 구조를 확인하고, 링크 상태 데이터베이스에 유지하며, 신뢰성 있는 플러딩에 참여합니다. 그러나 그것은 보관자일 뿐 의미론적 증인이 아닙니다. 운영자가 해당 라우터의 데이터베이스에서 LSA를 발견하더라도 방어 가능한 진술은 좁습니다. 이 라우터가 OSPFv3 규칙 안에서 이 식별된 광고를 수신하고 보유했다는 것입니다. 이 관찰은 라우터가 광고된 확장 기능을 구현했거나 이에 따라 행동했다는 것을 증명하지 않습니다.

라우팅 대시보드가 서로 다른 네 가지 주장을 하나의 녹색 표시로 합쳐 버리는 경우가 많기 때문에 이 구분은 중요합니다.

  1. 바이트가 도착했고 잘 구성된 LSA가 LSDB에 들어갔다.
  2. 구현이 LSA 또는 TLV 문법을 인식했다.
  3. 기능이 활성화되었고 인식된 정보를 의사결정에 사용했다.
  4. 그 결정이 RIB, FIB 및 패킷에 도달했다.

RFC 8362는 의도적으로 첫 번째 주장만 허용하고 나머지 세 가지는 요구하지 않습니다. 데이터베이스 존재 여부를 묻는 쿼리만으로는 그 간극을 메울 수 없습니다.

내용이 성장할 수 있도록 봉투가 바뀌었다

구형 OSPFv3 Router-LSA, Network-LSA, Inter-Area-Prefix-LSA, Inter-Area-Router-LSA, AS-External-LSA 및 Link-LSA는 고정 형식을 가집니다. 고정된 본문에 정보를 추가하려면 미래의 기능을 과거의 레이아웃에 결합하지 않고서는 어렵습니다. RFC 8362는 가변 정보를 유형-길이-값(TLV) 구조에 담는 Extended 버전을 정의합니다. TLV는 기능에 이름 있는 컨테이너를 부여하고, 서브TLV는 그 안에 더 세밀한 추가를 가능하게 합니다.

이 설계는 두 가지 별개의 문제를 해결합니다. 새로운 LSA 기능 코드를 통해 라우터는 확장 가능한 봉투와 레거시 봉투를 구분할 수 있습니다. U 비트는 그 봉투가 아직 그 의미를 배우지 못한 라우터를 통과할 수 있게 합니다. 이러한 메커니즘은 점진적 배포의 여지를 만들지만, 토폴로지의 일부만 이를 지원할 때 모든 미래 확장 기능이 어떻게 동작해야 하는지는 정의하지 않습니다. RFC 8362는 이 질문을 새로운 TLV 또는 서브TLV를 정의하는 사양에 명시적으로 맡깁니다.

알려진 Extended LSA 내부의 알 수 없는 정보에는 별도의 규칙이 있습니다. 인식되지 않는 TLV와 서브TLV는 구문 분석 및 처리 중에 무시됩니다. '무시됨'은 '프로토콜에서 삭제됨'과 같지 않고, '지원됨'과도 같지 않습니다. 라우터는 구성 요소에 의미를 부여하지 않으면서도 플러딩을 위해 주변 LSA를 보존할 수 있습니다. 확장 기능 작성자는 부분 배포가 무해한지, 기능을 제한하는지, 의도된 결과를 무효화하는지를 여전히 밝혀야 합니다.

후속 작업은 이 구분이 왜 여전히 유효한지 보여줍니다. RFC 9492는 애플리케이션별 링크 속성에 OSPFv3 Extended LSA를 사용합니다. 이는 애플리케이션을 위한 속성 광고와 해당 애플리케이션을 링크에서 활성화하는 일을 분리합니다. 따라서 수신자는 구조화된 정보를 관찰할 수 있지만, LSA가 이동하는 모든 곳에서 관련 애플리케이션이 활성화되어 있다고 추론할 권한을 얻지는 않습니다.

알 수 없음은 잘못된 형식이 아니다

전방 호환성은 새롭고 잘 구성된 의미를 허용하는 데 달려 있습니다. 깨진 인코딩을 유통할 필요는 없습니다. RFC 8362는 경계를 분명히 긋습니다. Extended LSA의 길이 정보가 일관되지 않거나 다른 인코딩 오류가 있으면, 수신 구현은 이를 LSDB에 설치해서는 안 되고, 확인 응답해서도 안 되며, 플러딩해서도 안 됩니다. 오류는 카운트되고 기록되어야 합니다.

이는 하나의 포괄적인 '지원되지 않음' 범주가 아니라 세 가지 운영 대응 클래스를 만듭니다.

  • 알려져 있고 유효함:정의된 구조를 구문 분석하고 관련 확장 기능과 구성에서 허용한 동작만 적용합니다.
  • 알 수 없지만 잘 구성됨:U 비트 규칙이 적용되는 곳에서는 인코딩된 범위 안에서 보유하고 플러딩하되, 의미론적 참여를 주장하지 않습니다.
  • 잘못된 형식:LSDB와 플러딩 프로세스에서 격리하고, 거부 사실을 운영 근거로 노출합니다.

두 번째와 세 번째 클래스를 혼동하면 상반된 실패가 발생합니다. 모든 알 수 없는 유형을 버리면 전방 호환 플러딩이 깨지고, 더 새로운 라우터가 구형 라우터를 가로질러 유효한 상태를 교환하지 못할 수 있습니다. 새로움이 구조적 실패를 면책한다고 여겨 잘못된 입력을 플러딩하면 장애 영역이 커집니다. 유용한 제어는 '낯선 것을 수용한다' 또는 '낯선 것을 거부한다'가 아니라, 새로움과 무효성을 구분할 수 있는 파서와 텔레메트리 경로입니다.

근거의 언어는 그 구분을 보존해야 합니다. 잘못된 형식의 Extended LSA에 대한 카운터는 거부 주장을 뒷받침합니다. 알 수 없는 LSA 보기는 보관 주장을 뒷받침합니다. 디코딩된 TLV 보기는 인식 주장을 뒷받침합니다. 어느 것도 단독으로 경로가 선택되었거나 트래픽이 변경되었다는 것을 증명하지 않습니다.

이동한 대상은 무엇으로 식별되는가

'동일한 LSA'라는 표현에도 규율이 필요합니다. RFC 5340은 LSA를 LS Type, Link State ID, Advertising Router로 식별합니다. 시퀀스 번호, 체크섬, 에이지는 어느 인스턴스가 현재인지 판단하는 데 도움이 됩니다. 체크섬은 LS age 필드를 제외하며, age는 광고가 보유되고 플러딩되는 동안 증가합니다.

따라서 모든 홉에서 바이트 단위의 동일한 보존을 약속하기보다 프로토콜 식별자와 인스턴스 데이터를 연관 짓는 편이 더 안전합니다. 전달 영수증을 찾는 운영자는 유형, 범위 비트, 광고 라우터, 링크 상태 ID, 시퀀스 번호, 체크섬을 관찰 시각 및 수신 인터페이스 또는 영역과 함께 기록해야 합니다. LS age는 경로 서사에 도움을 줄 수 있지만, 불변의 페이로드 바이트로 오인해서는 안 됩니다.

그 영수증은 구형 중계 라우터가 기능을 갖춘 종단점 사이의 도달 가능성을 보존했는지 답할 수 있습니다. 그러나 모든 관찰자가 동일한 서브TLV를 디코딩했는지, 동일한 정책을 적용했는지, 동일한 포워딩 상태를 설치했는지는 증명할 수 없습니다. 이는 능력, 구성, 계산, 패킷 근거에 대한 별도의 결합입니다.

두 가지 마이그레이션, 어느 것도 존재만으로 인증되지 않음

RFC 8362는 레거시 LSA와 Extended LSA가 별도의 OSPFv3 인스턴스에서 동작하는 전체 마이그레이션을 설명합니다. 확장 인스턴스는 처음에 덜 선호되는 관리 거리를 받습니다. 운영자는 결과 RIB를 비교하고, 만족하면 선호도를 변경하고, 다시 검증한 뒤에야 레거시 인스턴스를 제거합니다. 이 순서는 성공적인 플러딩이 두 인스턴스를 동등하게 만든다고 가정하지 않고, RIB 비교를 게이트로 취급합니다.

이 문서는 스파스 모드 배포도 허용합니다. 레거시 LSA는 계속 일반 SPF 계산을 구동하고, Extended LSA는 새로운 기능에 필요한 정보만 운반합니다. 이렇게 하면 두 개의 완전한 인스턴스 비용을 피할 수 있지만, 확장 기능의 부분 배포 의미론이 결정적이 됩니다. 눈에 보이는 몇 개의 Extended LSA만으로는 기능을 갖춘 라우터가 필요한 토폴로지를 구성하는지, 필요한 모든 광고가 존재하는지, 새 기능이 의사결정에 영향을 주는지 알 수 없습니다.

두 접근 방식 모두 LSDB 스크린샷 이상의 것이 필요합니다. 전체 마이그레이션은 선호도 변경 전과 레거시 철회 전에 각각 경로별 예외 원장이 필요합니다. 스파스 모드는 능력 및 인접성 맵, 필요한 TLV 목록, 그리고 이를 사용하는 종단점에서의 기능 결과 근거가 필요합니다. 전달은 각 방법의 한 체크포인트일 뿐, 완료 증명서가 아닙니다.

관리 모델은 경계를 보존한다

2024년에 발표되었고 Lindem도 공동 저술한 RFC 9587은 OSPF용 YANG 모델을 정의합니다. 이 모델의 OSPFv3 상태에는 기본값이 false인 extended-LSA-support 제어와, 알 수 없는 TLV 및 서브TLV의 유형, 길이, 16진수 값을 노출하는 운영 표현이 포함됩니다.

이 필드들은 원시 가시성이 의미와 같다고 가장하지 않기 때문에 가치가 있습니다. 수집기는 불투명한 정보가 존재했는지, 어디에서 관찰되었는지, 확장 지원이 구성되었는지를 보여줄 수 있습니다. 그러나 결과를 확립하려면 구현 능력, 기능 상태, SPF 또는 애플리케이션 출력, RIB/FIB 근거, 그리고 주장이 서비스에 관한 경우 패킷 관찰이 여전히 필요합니다.

관리 데이터도 이동하면서 권위를 잃을 수 있습니다. 폴링 간격이 짧게 지속된 거부를 놓칠 수 있습니다. 컨트롤러가 범위 비트를 정규화해 없앨 수 있습니다. 기능이 비활성화된 뒤에도 데이터베이스가 오래된 LSA를 보유할 수 있습니다. 근거는 수집 시각, 원천 라우터, 모델 경로, 프로토콜 식별자를 보존해야 하며, 그래야 이후 보고서가 관찰을 시간을 초월한 사실로 바꾸지 않습니다.

제한된 저자적 실마리로서의 Acee Lindem

RFC 8362는 2018년 4월 Acee Lindem, Abhay Roy, Dirk Goethals, Veerendranatha Reddy Vallem, Fred Baker에 의해 발표되었습니다. 이는 RFC 5340의 OSPFv3 기본 사양과 RFC 5838의 주소 패밀리 확장을 갱신합니다. 현재 IETF 링크 상태 라우팅 워킹 그룹 페이지는 Lindem을 의장 중 한 명으로 기재하며, 이는 특정 시점의 조직적 역할이지 개방형 표준의 소유권이 아닙니다.

기록은 Lindem에 대해 정확한 주장을 뒷받침합니다. 그는 서로 다른 구현에 걸쳐 확장 가능한 OSPFv3 상태를 관찰 가능하고 배포 가능하게 만드는 공동 표준 작업에 참여했으며, 이후 그러한 상태가 운영적으로 어떻게 표현될 수 있는지 설명하는 데 기여했습니다. 그러나 그를 Extended LSA의 유일한 발명자, 모든 후속 TLV의 저자, 또는 벤더 동작과 네트워크 배포의 통제자라고 부르는 것은 뒷받침하지 않습니다.

이렇게 제한된 귀속은 기술적 교훈을 강화합니다. 합의는 권한이 의도적으로 분할된 메커니즘을 만들었습니다. 생성자는 무엇을 광고할지 통제합니다. 프로토콜은 유효한 알 수 없는 봉투가 어떻게 이동하는지 통제합니다. 구현은 무엇을 인식할지 통제합니다. 구성은 어떤 기능이 작동할 수 있는지 통제합니다. 라우팅 및 포워딩 시스템은 설치된 결과를 통제합니다. 운영자는 어떤 근거를 보존할지 통제합니다. 단 하나의 LSDB 행도 이 여섯 가지를 모두 대신할 수 없습니다.

전송만이 아니라 의미론을 위한 영수증

방어 가능한 운영 기록은 주장을 압축하는 대신 연결합니다.

  1. 전달:프로토콜 식별자, 인스턴스 데이터, 범위, 도착 시각, LSA가 보유된 라우터.
  2. 인식:각 라우터가 어떤 LSA, TLV, 서브TLV 문법을 이해하는지 보여주는 구현 및 버전 근거.
  3. 자격:사양이 요구하는 곳에서 관련 확장 기능 또는 애플리케이션이 활성화되어 있음을 입증하는 구성.
  4. 사용:인식된 정보가 의사결정에 들어갔음을 보여주는 SPF, 애플리케이션 또는 정책 출력.
  5. 설치:결과 경로, 다음 홉 또는 속성을 식별하는 RIB 및 FIB 근거.
  6. 효과:동일한 변경에 연결된 범위 제한적 패킷 또는 서비스 관찰.
  7. 거부:플러딩 시스템에 들어가지 않은 것을 보여주는 잘못된 입력 카운터 및 로그.

첫 번째 항목은 여섯 번째 항목의 약한 형태가 아닙니다. 그것은 다른 사실입니다. RFC 8362는 그 차이를 설계상 드러냅니다. 때로 라우터가 이해하지 못하는 정보에 대해 할 수 있는 가장 올바른 일은 이를 이해하는 라우터에 충실히 전달하는 것입니다. 신뢰성은 그 보관에 정당한 공을 인정하는 데서 시작하며, 그 이상은 아닙니다.

출처