요약

  • MEF의 이더넷 트리(Ethernet Tree) 서비스는 각 어태치먼트 회선에 루트(root) 또는 리프(leaf) 역할을 부여했습니다. 리프는 루트와 통신할 수 있지만 다른 리프와는 통신할 수 없습니다. 반면 일반 VPLS 포워딩은 어태치먼트 회선을 대등한 피어로 취급했습니다.
  • RFC 7152의 가상의 두 에지 예제는 목적지 MAC 주소와 프레임 전달만으로는 부족한 이유를 보여주었습니다. 원격 제공자 에지는 프레임이 유입된 회선의 역할을 알지 못했습니다.
  • 이 2014년 메모는 복수의 루트, 한 에지에서의 혼합 역할, 하위 호환성 등 기능 요구사항을 명시했습니다. 이후 RFC들이 프레임워크와 메커니즘을 정의했지만, 표준 기록은 배포나 서비스 결과를 입증하지 않습니다.

분석

규칙은 어태치먼트에 속했다

이더넷 트리(Ethernet Tree)는 루티드 멀티포인트 서비스입니다. 루트 어태치먼트 회선은 루트와 리프 모두와 통신할 수 있습니다. 리프는 루트와 통신할 수 있지만, 트래픽이 한 리프에서 다른 리프로 흘러서는 안 됩니다. 이 규칙은 모든 어태치먼트가 서로 통신할 수 있는 이더넷 LAN(E-LAN) 서비스와 다릅니다.

이 구분은 서비스가 제공자 네트워크를 넘어가기 전까지는 단순해 보입니다. RFC 7152의 예제에서 두 개의 제공자 에지(PE) 라우터가 각각 하나의 루트 회선과 하나의 리프 고객 회선에 연결되어 있습니다. 두 라우터는 가상회선(의사회선, pseudowire)을 통해 이더넷 프레임을 교환합니다. 두 번째 에지가 첫 번째 에지에서 온 프레임을 수신하면, 그 프레임이 원격 제공자 에지로부터 도착했다는 사실은 알 수 있습니다. 그러나 첫 번째 에지에서 어느 로컬 어태치먼트 회선이 프레임을 공급했는지, 그리고 그 회선이 리프였는지는 반드시 알 수 없습니다.

이 불확실성은 목적지 MAC을 아는 경우에도 문제가 됩니다. 프레임의 목적지는 그것이 향하는 곳을 식별할 뿐, 유입 회선에 부여된 서비스 역할을 함께 담지 않습니다. 원격 에지가 역할을 알지 못하면 유니캐스트, 알려지지 않은 유니캐스트, 브로드캐스트, 멀티캐스트 트래픽에 대해 리프 간 통신 제한을 신뢰할 수 있게 적용할 수 없습니다. RFC는 자신의 토폴로지를 가상의 예제라고 명시하며, 전형적인 서비스에 대한 서술이 아니라고 밝힙니다.

VPLS는 연결성은 전달했지만 이 정책은 전달하지 않았다

기존 VPLS 모델은 어태치먼트 회선을 동일하게 취급하고 인스턴스 내에서 any-to-any 연결성을 제공했습니다. 이는 이더넷 LAN을 에뮬레이션하는 데는 유용했습니다. 그러나 MEF의 E-Tree 서비스가 요구한 루티드 포워딩 관계를 표현하지는 못했습니다. 누락된 정보는 단순히 또 하나의 고객 주소가 아니었고, 프레임이 제공자 코어를 통과한 뒤에도 의미를 유지해야 하는 서비스 어태치먼트의 속성이었습니다.

따라서 RFC 7152는 완성된 해법을 선언하는 대신 요구사항을 정립했습니다. 요구사항에 부합하는 접근 방식은 리프 어태치먼트 간 통신을 금지하고, 복수의 루트를 허용하며, 한 제공자 에지에서 루트와 리프 회선이 공존하도록 허용해야 했습니다. 또한 해법이 어떤 레이어 2 VPN 기술에 적용되는지 밝히고, 기존 VPLS와 EVPN 배포에 미치는 장애를 최소화할 것을 요구했습니다. 일부 제공자 에지만 새 동작을 지원하는 경우, 요구사항은 해당 규격에 부합하는 에지 범위로 한정됩니다. 이 문구는 지원되지 않는 구간을 통한 종단 간 격리를 약속하는 것이 아니었습니다.

메모는 허브-앤-스포크 VPN, 도매 접속, 모바일 백홀, 클록 배포, 인터넷 접속, 방송 비디오, 기기 관리 같은 가능한 활용 환경을 열거했습니다. 이는 요구사항 문서에 나열된 사용 사례이지, 배포된 E-Tree 서비스의 전수 조사가 아닙니다. 또한 당시 IETF에서 논의 중이던 가상 프라이빗 멀티캐스트 서비스(VPMS)와 E-Tree를 구분했습니다. E-Tree는 루트-리프 규칙 아래에서 유니캐스트와 멀티캐스트 패턴을 모두 허용하는 반면, 멀티캐스트 서비스가 모든 E-Tree 흐름을 대체할 수는 없습니다.

표준 경로는 누락된 맥락을 명시적으로 만들었다

2014년 말에 발표된 RFC 7387은 E-Tree 아키텍처 프레임워크를 제공하며 두 가지 공백을 지목했습니다. 기존 레이어 2 VPN은 어태치먼트 회선의 역할을 구분하지 않았고, 원격 에지는 프레임이 루트에서 시작했는지 리프에서 시작했는지 알려주는 표시를 받지 못했습니다. 이후 RFC 7796은 VPLS에서 별도의 VLAN 식별자를 사용해 루트에서 시작된 프레임과 리프에서 시작된 프레임을 표시하고, 포워딩 장비가 리프 포트에서 프레임을 필터링할 수 있도록 하는 E-Tree 지원을 명시했습니다. RFC 8317은 E-Tree 지원을 EVPN과 PBB-EVPN으로 확장했습니다.

이 일련의 과정은 서비스 규칙이 어떻게 엔지니어링 요구사항이 되고, 그 뒤 일련의 프로토콜 메커니즘이 되었는지 보여줍니다. 그러나 이는 메커니즘이 얼마나 널리 구현되었는지, 특정 제공자가 그것을 시행했는지, 고객 트래픽이 실제로 올바르게 격리되었는지를 입증하지 않습니다. RFC 7152는 정보성(Informational) 요구사항 기록이며, 사고 보고서, 배포 연구 또는 인터넷 표준이 아닙니다.

이 역사적 교훈은 "이더넷 프레임은 출발지를 잃는다"는 것보다 좁습니다. 프레임은 프레임 수준의 주소를 유지하고, 전송 매체를 통해 도착합니다. 레이어 경계에서 사라질 수 있는 것은 그 프레임들에 포워딩 역할을 부여한 서비스 어태치먼트에 대한 제공자의 지식입니다. 네트워크는 비트를 전달하면서도, 서비스 계약을 지키기 위해 필요한 맥락을 갖지 못할 수 있습니다.

출처

RFC 편집자(RFC Editor)의메타데이터 기록은 이 RFC의 발표 상태를 확인합니다.

1차 기록은RFC 7152이며, 이 문서는 요구사항 집합을 정의하고 두 에지 예제를 가상의 것으로 표시합니다. 이후의RFC 7387,RFC 7796,RFC 8317은 프레임워크와 이후의 VPLS 및 EVPN 메커니즘을 문서화합니다. 이 출처들은 각 문서가 무엇을 명시하는지 확립할 뿐, 채택률, 제공자 구성 기록, 트래픽 측정 또는 명명된 운영 결과의 증명을 제공하지 않습니다.