요약

  • 10월 28일 자 개인 인터넷 초안은 PCEP가 일반 SRv6 SID와 압축 SID 컨테이너의 내부 필드를 기준으로 트래픽을 고를 수 있도록 두 종류의 FlowSpec TLV를 제안한다. 양쪽이 S 기능 비트를 먼저 알리는 조건이 붙는다.
  • 합의되지 않았거나 형식이 잘못된 규칙을 받으면 PCC는 Type 30 PCErr를 보내야 한다. 초안이 적은 오류값은 TBD_EV인데 IANA 배정 요청에는 없다. 현행 등록부에는 지원 불가와 잘못된 형식을 가르는 별도 값이 이미 있다.

주소는 쪼개 읽고, 거절 이유는 뭉개 쓴다

PCEP에서 PCE는 경로와 흐름 규칙을 제어하고, 라우터 쪽 PCC가 그 규칙을 적용한다. 새 초안은 IPv6 목적지 주소를 통째로 보는 단계에서 더 들어간다. 일반 SRv6 SID의 locator·function·argument를 따로 골라 일치시키고, 압축 SID 컨테이너에서는 locator block·locator node·function을 지정한다. 제어기가 패킷 주소의 내부 구조까지 지목하는 셈이다.

초안은 라우터에게 문턱도 남겨 둔다. 세션을 세울 때 PCE와 PCC가 모두 새 S 비트를 광고해야 이 TLV를 쓸 수 있다. PCC는 전달받은 필드 길이의 합계가 128비트를 넘는지도 검사한다. 넘으면 잘못된 TLV다. 제어기가 아무리 상세한 명령을 보내도, 주소보다 긴 도면을 현장 장비에 강요할 수는 없다.

문턱에서 돌려주는 영수증이 문제다. 5.2절은 S 비트를 협상하지 않았거나 TLV가 잘못됐으면 PCC가 Error-Type 30과 Error-Value TBD_EV를 담은 PCErr를 반드시 보내라고 쓴다. 7절은 IANA에 S 비트와 두 TLV 형식 번호를 요청하지만 오류값은 요청하지 않는다. IANA의 PCEP 번호표에는 Type 30의 1부터 5까지가 배정돼 있고 6부터 255까지는 미배정이다. 초안이 의무화한 응답의 숫자는 아직 없다.

기존 규칙은 오히려 구분이 분명하다. 기반 문서인 RFC 9168은 지원하지 않는 FlowSpec에 값 1, 형식이 잘못된 FlowSpec에 값 2를 쓴다. SRv6 초안은 두 사유를 하나의 미래 값 이름으로 묶었다. 기존 값 둘을 그대로 쓰면 원인을 구분할 수 있고, 새 값을 원하면 IANA에 요청해야 한다. 현재 문장은 어느 쪽을 택했는지 말하지 않는다.

자동 배포에서는 이 차이가 다음 행동을 가른다. '지원하지 않음'이라면 제어기는 그 장비에 SRv6 필터를 다시 밀어 넣지 말아야 한다. '형식 오류'라면 규칙을 만든 쪽의 길이 계산이나 인코딩을 고쳐 다시 보내야 한다. 두 상황이 임의의 오류 번호 하나로 뭉개지면 운영자는 장비 지원 범위를 의심할지, 생성된 규칙을 조사할지부터 다시 추적해야 한다. 거부 메시지는 단순한 실패 표시가 아니라 복구 순서를 정하는 입력이다.

평상시의 성공만 시험하면 이 빈칸은 숨어 버린다. 다른 회사 장비끼리 유효한 규칙을 주고받다가 한쪽이 거부하는 순간, 상대는 오류값을 읽고 다음 행동을 정한다. 각자가 TBD_EV를 임의의 숫자로 채우면 제어와 실행의 경계에서 말이 어긋난다. 규칙을 받지 않겠다는 사실보다 왜 받지 않았는지가 운영에 더 중요할 때가 있다.

IETF Datatracker는 이를 개인 인터넷 초안으로 분류한다. 다음 개정판이 값 1·2를 지정하거나 새 값을 요청하면 판정할 수 있다. 지금은 명령의 비트 배열보다 거부 응답의 한 칸이 더 급한 설계 결정이다.

출처