الخلاصة

  • تقترح المراجعة 07 نموذجي YANG: أحدهما لاختبار OAM مفرد، والآخر لسلسلة يحدد المستخدم ترتيبها، مع فترة أو تكرار وحالات تشغيل ونماذج أجهزة مركبة عبر schema mount.
  • لا تثبت حالة success وحدها أن النسخة المقصودة نفذت في النافذة المقصودة، أو أن الخطوات والقياسات كانت كاملة وقابلة للمقارنة، أو أن السبب فريد، أو أن التغيير مخول، أو أن الخدمة تعافت.

جدولة التحقيق لا تعني حسمه

يتكون تشخيص الشبكة عادة من عدة مشاهدات: فحص الاستمرارية، تتبع المسار، قياس الفقد والتأخير، تضييق النطاق إلى عقدة أو وصلة، ثم إعادة الاختبار خلال زمن ظهور الخلل. يحول draft-ietf-opsawg-scheduling-oam-tests-07 هذه الخطوات إلى بنية مشتركة. يصف ietf-oam-unitary-test الاختبار وعقد الشبكة المستهدفة، بينما يجمع ietf-oam-test-sequence الاختبارات بترتيب يختاره المستخدم ويضيف الفترة أو قاعدة التكرار.

هذه فائدة تنظيمية واضحة. غير أن الشاشة قد تعرض خطة وعدّاداً وحالة نهائية فتبدو وكأنها تعرض سبب العطل نفسه. السجل يمكن أن يكون صحيحاً تماماً ضمن طبقة الجدولة، ويبقى غير كافٍ لإثبات ما حدث للحزم أو للمستخدمين.

يبين Datatracker أن المراجعة 07 ما زالت Internet-Draft نشطة في فريق OPSAWG ومقصودة لمسار Standards Track. ليس لها رقم RFC، ولم يبدأ IESG معالجتها. ويسجل التاريخ مراجعتين مبكرتين من OPSDIR وPERFMETRDIR بنتيجة Has Issues، فيما لم تكتمل مراجعة YANG Doctors. لذلك لا يجوز وصفها كتنفيذ أو نشر أو امتثال مثبت.

الإيصال الأول: هوية الخطة

يعيد المشروع استخدام حالة الجدول والنسخة والتوقيت المحلي وآخر تكرار والتكرار التالي والعدادات من RFC 9922. ويمكن للاختبار المفرد أن يحدد عدة عقد وأن يركب نموذج OAM خاصاً بالجهاز تحت root.

ينبغي أن يثبت إيصال الخطة بصمة الإعداد، وترتيب الاختبارات، والعقد، والمعاملات، وقاعدة الزمن والمنطقة الزمنية، وهوية مكتبة YANG والنماذج المركبة، وصاحب الموافقة. يسمح RFC 9922 للجهة التي تستخدم التجميع بإدارة version، بل وقد لا تستخدمه. لذلك لا يضمن رقم النسخة وحده تطابق المحتوى. يجب ربط كل تشغيل بالإعداد الدقيق الذي انطلق منه.

الإيصال الثاني: التطبيق لا مجرد القبول

تتضمن الحالات المقترحة planned وconfigured وready وon-going وstop وerror وsuccess، وتضيف السلسلة failure. وهي تصف ما يعتقده التنفيذ الذي يبلغ عنها.

قبول تعديل عبر NETCONF أو RESTCONF لا يثبت أن كل جهاز طبق المقصود. يفصل RFC 8342 بين running وintended والإعداد المطبق وحالة operational. قد يوجد إعداد في المقصود ولا يظهر في التشغيل الفعلي. لهذا يجب مقارنة الحالتين لكل عقدة وحفظ القدرات ونسخة المخطط وحالات التطبيق الجزئي.

وتشير مراجعة OPSDIR إلى أن النص يتحدث عن الاستخدام عند الطلب لكنه لا يعرف RPC أو action معيارية للتشغيل الفوري. لا ينبغي نسبة عمليات النماذج الدنيا إلى هذه المسودة نفسها.

الإيصال الثالث: واقعة التنفيذ المحددة

قاعدة التكرار تصف موعداً متوقعاً، وليست هوية تشغيل. قد تؤدي إعادة التشغيل أو التأخير أو المحاولة الجديدة أو تراكب النوافذ أو انتقال المتحكم أو تعديل الساعة إلى جعل last-occurrence والعداد غير كافيين.

يحتاج كل تشغيل إلى معرف مستقل يربط الوقت المخطط ببداية ونهاية فعليتين، ونسخة الخطة، وهوية المنسق، ومصدر الساعة وحد خطئها، وسلسلة المحاولات، والعقد التي وصلت إليها المهمة فعلاً. نجاح اختبار بعد انتهاء نافذة الحادث لا يصف بالضرورة حالة الشبكة أثناءها.

الإيصال الرابع: اكتمال الخطوات والاعتماديات

القائمة ordered-by user، وتسمح المسودة باستمرار الاختبارات اللاحقة بعد خطأ في اختبار سابق. يحافظ ذلك على ما يمكن جمعه، لكنه يفصل بين انتهاء المرور على القائمة واكتمال إجراء التشخيص.

تسأل مراجعة PERFMETRDIR لماذا يقود stop إلى نجاح في مخطط الاختبار المفرد وإلى فشل في مخطط السلسلة. كما تطلب OPSDIR وضوحاً حول الخطأ والفشل والإشعارات والربط والاتساق والتراجع بين العقد. يجب أن يسرد الإيصال كل خطوة لازمة واعتمادها وعقدتها وتوقيتها ونتيجتها وتجاوزها وقرار الاستمرار، وأن يذكر الفرضيات التي بقيت ممكنة بسبب النقص.

الإيصال الخامس: معنى القياس

لا تعيد مسودة الجدولة تعريف تفاصيل المدخلات والنتائج، بل تعتمد على نماذج OAM للأجهزة، مثل نموذج TWAMP في RFC 8913. ويحدد RFC 8528 schema mount لربط شجرة نموذج بأخرى، من دون افتراض مصدر بيانات النسخة أو طريقة إنشاء نقطة التركيب.

لذلك يجب أن يعبر سجل القياس هذه الحدود: نوع الاختبار ومراجعته، معاملاته، المصدر والوجهة، الاتجاه، مجموعة الحزم، فئة التوجيه، الحجم والمعدل، النافذة الفعلية، الوحدة، الساعة، هوية الجهاز، النتيجة الخام أو بصمتها، ومسار الحفظ. الإشارة إلى ورقة مركبة لا تحمل هذه الدلالة كاملة.

يفرق RFC 7799 بين القياس النشط والسلبي والهجين. الحزم التي تولدها أداة الاختبار ليست افتراضياً نفس حركة الخدمة التي تأثرت.

الإيصال السادس: قابلية المقارنة مع الخدمة

يفصل RFC 10014 بين تطابق المسار الطوبولوجي والمساواة في معاملة التوجيه. قد تمر حزمة الاختبار بالعقد والوصلات نفسها لكنها تدخل صفاً آخر، أو تحمل QoS مختلفة، أو تختار فرع ECMP آخر، أو تتجنب policer أثر في العملاء.

يجب أن يحدد الإيصال ما اشتركت فيه الأداة والخدمة: المسار، التغليف، الفئة، مدخلات التجزئة، نطاق الصيانة، الزمن، الحمل ونمط الفشل. إذا اشتركتا في الطوبولوجيا فقط، فيجب أن يبقى الاستنتاج طوبولوجياً. الجدولة لا تخلق تطابق المعاملة بقرار إداري.

الإيصال السابع: فرضية السبب وسلطة التغيير

تستخدم المسودة تعبير candidate root cause بحذر. يميز RFC 9940 بين الحدث والعطل والمشكلة والعرض والسبب والتنبيه والإنذار والحادث، وقد يحتاج تحديد السبب إلى عدة مدخلات. ويصف RFC 8632 موارد السبب المحتملة بأنها تلميحات يفسرها تطبيق العميل.

ينبغي أن يحفظ إيصال التشخيص المشاهدات والتفسيرات المنافسة والفرضيات المستبعدة والثقة والنطاق وما قد يدحض الاستنتاج. ثم يحتاج التغيير إلى تفويض مستقل. السماح بإنشاء الاختبارات لا يسمح بتعديل المسارات أو QoS. يحافظ RFC 8341 على التحكم في الوصول كطبقة منفصلة؛ ويجب تسجيل صاحب القرار والسياسة والتغيير الدقيق ونطاق الأثر والنافذة وخطة التراجع.

الإيصال الثامن: واقع الخدمة بعد التغيير

قد يقبل المتحكم التغيير وتتحول الأداة إلى اللون الأخضر بينما يبقى العميل متضرراً. ربما انتقلت الحركة إلى مسار أسوأ، أو اختفى عرض واحد، أو ظهر تدهور جديد.

يجب أن يأتي إيصال النتيجة من السطح الذي يحمل الوعد: مجموعة الخدمة، شرط SLA، النافذة اللاحقة، إشارات مستقلة، إنذارات باقية، حالة التراجع، ومدة الاستقرار. إعادة الأداة نفسها مفيدة، لكنها ليست مستقلة عندما تكون قابلية مقارنتها بالخدمة موضع الخلاف.

تمنح OAM المجدولة لغة مشتركة لبداية التشخيص. وتأتي المصداقية من إبقاء الخطة والتطبيق والتنفيذ والقياس والسبب والتفويض والنتيجة سجلات مترابطة لا حكماً واحداً.