الخلاصة

  • أوضحت RFC 3139 أن سياسة مثل Gold تحتاج إلى topology وstatus وcapability قبل أن تصبح إعدادات محلية مختلفة على منصات مختلفة.
  • يمكن لمترجمين أن يعملوا في سلسلة، لكن واحداً فقط يعمل على جهاز في اللحظة نفسها. اعتماد السياسة والمرشح والكتابة والتأكيد والنتيجة إيصالات مستقلة.

لم يفهم الراوتر اسم الخدمة

يستطيع المشغل التعبير عن السلوك المتوقع بجملة قصيرة. لكن الراوتر يحتاج interface وclassifier وqueue وscheduler ومعلمات خاصة. وقد يختلف التنفيذ بين vendors والمسار الرئيسي والاحتياطي.

جعل التجريد الهدف قابلاً للإدارة، لكنه لم يجعله configuration. السياسة المعتمدة ليست حالة الجهاز ولا دليلاً على أن packet تلقى المعاملة.

صدرت RFC 3139 في يونيو 2001 بوصفها Informational ولم تختَر بروتوكولاً. جاءت بعد مخاوف من تشتت حلول COPS/PIB وSNMP/MIB والحلول الخاصة بالتقنيات. وبعد نقاش لم يحسم كل القضايا، جمعت متطلبات مشتركة.

لذلك تصف MUST خصائص مطلوبة، لا تطبيقاً قائماً أو نتيجة نشر.

ثلاث طبقات احتاجت إلى ترجمة

فرقت الوثيقة بين high-level policy وnetwork-wide configuration وdevice-local configuration. الأولى للسلوك، والثانية صيغة مشتركة، والثالثة تفاصيل آلة بعينها.

يعبر configuration-data translator الطبقات. وقد يكون إنساناً أو برنامجاً مركزياً أو وسيطاً أو وظيفة داخل الجهاز. الموقع غير مفروض.

تحتاج الترجمة إلى topology وcapability وstatus وperformance وmonitoring. يمكن لمرشح صحيح الصياغة أن يعتمد خريطة قديمة. وإذا غابت معلومات لازمة للتحويل بلا خطأ، وجب اكتشاف ذلك والتصرف؛ لا يجوز تحويل الجهل إلى نجاح صامت.

مترجمون في السلسلة وكاتب واحد عند الجهاز

يمكن لمراحل متعددة أن تحول الهدف إلى model ثم technology profile ثم أوامر vendor. لكن RFC 3139 قالت إن مترجماً واحداً فقط يعمل على جهاز محدد في وقت محدد.

لم تحدد lock أو lease أو election. حدّدت invariance. قد ينتج controllerان مرشحين منطقيين من revisionين مختلفين، ثم يخلط interleave classifier جديداً مع scheduler قديماً وexpiry مفقوداً.

نجاح الأمرين لا يثبت حالة متماسكة. لذلك طلبت الوثيقة منع misconfiguration الناتج من concurrent shared write. يجب حفظ writer وrevision وinput snapshot ونافذة الاستبعاد. Last-write-wins يرتب التخزين ولا يعيد المقصد.

قد يقع الخطأ بين جهازين صحيحين

تحتاج تغييرات network إلى إضافة أو تعديل أو حذف أو dump أو restore بصورة متزامنة عند الضرورة. ليست كل partial configuration خطأ، لكن route قبل filter قد يكشف traffic، وmark قبل دعم core قد يضيع الخدمة، ونصف migration قد يصنع loop.

طلبت RFC اكتشاف error واستعادة failure ومنع partial غير مناسب. لم تضمن distributed atomic commit ولا rollback موحداً.

ينبغي فصل batch orchestration عن قبول الجهاز والحالة المخزنة والحالة المطبقة ونتيجة traffic. لكل واحد شاهد مختلف.

الاستجابة السريعة بدأت قبل العطل

كان مطلوباً إعداد عدة local configurations مسبقاً حتى لا يبدأ failover بتنزيل ضخم. Preload ليس activation، وactivation ليس دليلاً على صلاحية المرشح وقت الحدث.

كما طُلبت منصات وعناصر redundant. لكن redundancy تخلق سؤال ownership: من يكتب، وأي snapshot ورث، وكيف مُنع leader القديم؟ مثيلان بلا fencing يعيدان مشكلة الكاتب المزدوج.

feedback أغلق حلقة الجهاز فقط

يجب أن يعيد الجهاز confirmation وstatus وmonitoring وevents. لكن هل success يعني parse أم validate أم candidate أم commit أم effective أم forwarding؟

ينبغي تفسير local state في سياق network-wide. قد تكون queue موجودة على مسار لم يعد مستخدماً، وقد يكون اختلاف محلي هو الترجمة الصحيحة لجهاز مختلف.

تأكيد كل الأجهزة لا يثبت end-to-end service. قد يسلك traffic طريقاً آخر أو يفشل classifier. Gold installed غير Gold experienced.

للتهيئة زمن سلطة

طلبت RFC effective time وexpiration time. قد تكون القيمة مخزنة ومستقبلية، أو حاضرة ومنتهية. وقد يجعل clock skew أو restore قاعدة قديمة فعالة من جديد.

يحتاج الإيصال إلى زمن الإنشاء والنفاذ والانتهاء ومرجع ساعة الجهاز والفترة المرصودة. «موجود» لا يعني «يحكم الآن».

والتزويد الناتج من event يحتاج event identity وpolicy revision وwriter وlifetime، وإلا تحول feedback السريع إلى oscillation.

الأمن جزء من صحة الانتقال

طلبت الوثيقة access control وauthentication وintegrity وreplay protection وprivacy والتتبع على مستوى host وuser. الإعداد الصحيح من writer غير مخول يظل انتقالاً غير صحيح.

يمكن replay لسياسة كانت مشروعة أن يعيد topology منتهية. المصادقة تحدد المرسل؛ السلامة تحمي bytes؛ الحداثة والتفويض يحددان حقه الآن.

عند drift نحتاج policy وprojection وsnapshot وtranslator وcandidate وresponses وerrors وfeedback قبل الكاتب التالي، لا final diff فقط.

التطور لا يبرر إخفاء نقص المعنى

كان على models وmessages وtypes أن تتطور من دون استبدال fleet، مع الاستفادة من MIB/SMI. قد يجهل translator قديماً field جديداً أو يدعم device جزءاً منه. يمكن أن تبقى syntax صحيحة والنية ناقصة.

تحتاج السلامة capability discovery ومعالجة صريحة للمجهول وvisible degradation. RFC 3139 لم تضمن تنفيذ كل جهاز قديم لكل policy مستقبلية.

جعل RFC 3535 ثم NETCONF وNMDA بعض الحدود ملموسة: datastore وlock وvalidate وcommit وintended/applied/operational. إنها سياق لاحق، لا وظائف منفذة ضمن RFC 3139 عام 2001.

قالت السياسة ما ينبغي أن يكون. وحدها الترجمة المنضبطة والكاتب الحصري والتنسيق والfeedback والقياس قالت ما أصبح واقعاً.