정책 기반 관리에 있어서는 아직 표준이 정립되지 못했다. 표준화 기구가 존재하지 않는 것은 아니다. 이들은 존재하며, 수 년 동안 이것을 두고 작업해 왔다. 하지만, 이런 집단에서 보다 크고 복잡한 네트워크를 관리하는 데 따른 문제를 해결하기 시작한 것은 불과 최근에 들어와서다. 구성에 있어서 표준의 결핍은 진정한 정책 관리를 지연시키며, 장기적으로 볼 때 이것은 우리가 네트워크 안정성이라는 목표에 다가가는 것을 막는다.

대부분의 경우는 여전히 CLI가 왕이다. 그리고 명령어 라인 인터페이스는 대부분의 경우 전용이기 때문에, 업체마다 다르며 어떤 경우는 제품마다, 버전마다 달라지기도 한다. 그렇다고 해서 CLI가 나쁘다는 얘기는 아니다. 이것은 아스키(ASCII)기 때문에, SNMP ASN.1 표시보다도 이해하기가 훨씬 더 쉽다. 사실, 우리는 작은 변종들이 번거롭게 하지 않는다는 점에서 아스키에게 감사하고 있다. 조정 작업은 간단하다. 아스키는 스크립팅을 가능하게 한다. 소수의 전문가들은 표준이 없이 아스키를 이용해 네트워크의 구성을 정책 목표에 맞게 변경할 수가 있다. 그리고 아스키가 있고 표준이 없으면, 변종들이 존재할 수 있다.

많은 사람들에게는 시스코 시스템즈의 인터페이스가 기본 CLI 표준이 되고 있는데, 그것은 이 회사가 가진 방대한 설치 기반 덕분이다. 엔터라시스 네트웍스(Entrasys Networks)나 파운드리 네트웍스(Foundry Networks)조차도 시스코 CLI로 표준화 돼 있다. 하지만, 여기에는 문제가 있는데, 그것은 시스코의 CLI가 제품과 버전에 따라 다를 수 있다는 것이다. 이것은 명령어 스트럭처에서의 변종들과 전반적으로 무거운 업데이팅 프로세스로 인해 시달림 당하고 있다. 우리는 이런 결점들에 익숙해지고 있지만, 누군가는 벽에 머리를 박는 데 익숙해지는 사람도 있을 수 있다. 한편, 주니퍼 네트웍스와 익스트림 네트웍스는 처음부터 자신들의 CLI를 만들었다. 이들은 계층적이고 잘 조직화 돼 있으며, 가장 중요한 사실은 모든 제품에서 동일하다는 것이다.

그렇다고 우리가 CLI를 만병통치약으로 여기는 것은 아니다. 사실 CLI는 만병통치약이 아니라 단순한 하나의 접근 방안일 뿐이다. 주니퍼가 자사의 라우터 구성용 XML 인터페이스를 추가한 데 대해 말하자면, 하나의 접근 방안으로서는 좋은 아이디어지만, 그렇다고 해서 구성 프로시저를 표준화하는 것을 전혀 돕지는 못한다. XML도 마찬가지로 구성 정책을 정의 및 저장하는 데는 아무런 도움이 되지 못한다.

결론적으로 말하자면, 구성 변경을 위해 다양한 방식으로 네트워킹 인프라에 접근하는 것은 진정한 정책 관리를 제지할 뿐만 아니라 완전히 잘못된 접근 방식이다. 이기종 네트워크를 관리할 수 있게 되려면, PBNM(Policy Based Network Management) 소프트웨어가 훨씬 더 넓은 범주의 인프라 장비 형태, 모델 및 버전을 지원해야 한다. 그리고 PBNM 업체에서 새로운 소프트웨어를 발표할 때 지원되는 장비는 기존의 모든 형태, 모델 및 버전을 역 테스트(retrotest)할 필요가 있다. 인프라 장비 업체에서 새로운 형태, 모델 혹은 버전을 제공할 때 역시 코딩, 테스팅 및 갱신 작업이 완전히 다시 한번 이루어져야 하며, 이것은 보통 일이 아니다.

네트워크 안정이 첫 번째 요건

정책 관리는 안정된 네트워크에서 애플리케이션을 만들어내는 데 대한 것이다. 따라서, QoS(Quality of Service), 보안 및 VPN을 제공하는 것은 서비스 사업자들이 돈을 만들어내는 방법으로 언급되지만, 네트워크를 안정적으로 만들고, 그렇게 유지하는 것은 하나의 필수 전제조건이다. 그리고 이것은 표준이 없이는 쉬운 일이 아니다.

고려해야 할 다른 요소들이 있다. 표준을 제대로 갖게 되면 써드파티 개발자들이 사용자가 구입할 수 있는 네트워크 관리 툴을 구축하는 데 투자할 만한 경제적인 가치가 생길 가능성이 많아진다. 표준이 있을 경우 이러한 툴들은 보다 긴 시간 동안에 보다 폭넓은 제품을 관리할 수 있으며, 따라서 써드파티 개발자들이 더 나은 투자회수를 할 수 있게 해줄 것이다.

나아가, 표준은 CLI처럼 인간 대 기계가 아니라 기계 대 기계 커뮤니케이션용으로 만들어진다. 이러한 기계 대 기계 프로토콜은 또한 PBNM 시스템 개발을 한층 수월하게 해주며, 한 번에 많은 시스템을 관리할 수 있는 가능성을 높여준다. 즉 이들은 확장성이 더욱 뛰어나다.

이러한 신기술에서 한 가지 문제는 이들이 너무 많다는 것이다.

어떤 것들은 서로 보완 역할을 하지만, 기능이 상당히 중복되는 것들도 있다. 이것은 업체와 사용자 집단에 혼란을 야기한다. 업체들은 무엇을 이행해야 할지 알지 못하며, 고객은 무엇을 물어야 할지를 언제나 아는 것이 아니다. 업체들은 종종 각각의 일부만을 이행하며, 고객들은 모든 것을 요구하는 경우가 많다. 이것이 애플리케이션 업체와 사용자에게 일으키는 문제는, 방금 설명한 표준의 이점을 거의 없애버린다는 것이다.