الخلاصة
- تضيف المراجعة العاشرة لمسودة OPSAWG الخاصة بجدولة اختبارات OAM مبدأً واضحاً: تغيير قالب اختبار منفرد لاحقاً ينبغي ألا يبدل سلسلة سبق ضبطها من دون تنبيه. وتستبدل المسودة قائمة الإحالات إلى الاختبارات بقائمة تضم الاختبارات المنفردة داخل السلسلة، مع تغيير أسماء في نموذج YANG.
- تقول الفقرات إن للمستخدم السيطرة على ترتيب الاختبارات لأن اختلافه قد يغير النتائج المبلغ عنها. لكن قائمة
unitary-testالجديدة لا تحتوي عبارةordered-by userالتي كانت في المراجعة التاسعة. ووفق RFC 7950 يكون ترتيب القائمة للنظام إذا غابت العبارة. هذه فجوة في مسودة قيد النقاش، لا حادثة تشغيل مثبتة.
تبدأ بعض تحقيقات الأعطال بسؤال بسيط عن إمكان الوصول، ثم تنتقل إلى قياس التأخير، وبعده إلى تتبع المسار. لو قُدمت النتائج منفصلة من دون تسلسلها، لصعب تفسير ما إذا كان القياس الثاني قد جرى في الظروف نفسها التي افترضها المحقق. لذلك فإن خطة التشخيص نفسها جزء من الدليل. تقترح مسودة draft-ietf-opsawg-scheduling-oam-tests نموذجين بلغة YANG يتيحان لأنظمة الإدارة والتنسيق جدولة اختبارات OAM المنفردة وسلاسلها. الوثيقة ما زالت Internet-Draft تابعاً لفريق عمل، وليست RFC معتمدة أو وصفاً لنظام منشور.
الجديد في النسخة العاشرة أنها تفصل بين قالب قابل لإعادة الاستخدام وسلسلة جرى إعدادها فعلاً. تقول الفقرة 4.2 إن تغيير القالب في وقت لاحق لا ينبغي أن يغيّر السلسلة القائمة خفية. وتستخدم البنية الجديدة مدخلات unitary-test ضمن السلسلة، بدلاً من قائمة test-ref القديمة. معنى ذلك بالنسبة إلى القارئ هو ضرورة معرفة ما إذا كانت تجربتان قد نفذتا الخطة نفسها قبل مقارنة نتائجهما. لكنه لا يثبت أن تطبيقاً يحتفظ اليوم بنسخة تاريخية من الخطة أو يمنع كل أنواع الانجراف.
أما ترتيب المدخلات فغير محسوم. يكرر النص أن ترتيب المستخدم مؤثر في المخرجات وأن إعلان ordered-by user لازم. وكان الإعلان موجوداً في قائمة المراجعة التاسعة، ثم غاب عن القائمة الجديدة. وصف القائمة يذكر ترتيب المستخدم وترتيب النظام معاً، من دون أن يحدد في الصياغة الرسمية أيهما نافذ. تحسم RFC 7950 معنى هذا الغياب في لغة YANG: القيمة الافتراضية هي ترتيب النظام. لا يمكن لعبارة تفسيرية وحدها أن تمنح واجهة الضبط ضماناً مختلفاً.
السؤال الموجه إلى مراجعي المسودة محدد، لا اتهام لمورّد. إن كان المطلوب سلسلة يرتبها المشغّل، فكيف تُكتب تلك الأولوية وتُقرأ ثانية وتنعكس في التنفيذ؟ وإن كان ترتيب النظام مقبولاً، فلماذا يعد النص بنتيجة مبنية على ترتيب يختاره المستخدم؟ أضافت النسخة نفسها فئة أدق لتعارض الأولوية ووسعت أنواع معرف العقدة؛ وهما تعديلان مختلفان لا يجيبان عن هذا السؤال.
تعتمد المسودة على عناصر الجدولة في RFC 9922. وقد ناقش BTW سابقاً لماذا لا تثبت صلاحية موعد متكرر استمرار الإذن بتنفيذ فعل ما. المسألة هنا مستقلة: حتى حين يكون التنفيذ مأذوناً، هل يمكن للقارئ أن يعيد بناء الاختبارات التي أجريت وترتيبها؟ الموعد والإذن وتسلسل الدليل ليست شيئاً واحداً.
المصادر
- https://www.ietf.org/archive/id/draft-ietf-opsawg-scheduling-oam-tests-10.txt
- https://www.ietf.org/archive/id/draft-ietf-opsawg-scheduling-oam-tests-09.txt
- https://datatracker.ietf.org/doc/draft-ietf-opsawg-scheduling-oam-tests/
- https://www.rfc-editor.org/rfc/rfc7950.html#section-7.7.7
- https://www.rfc-editor.org/rfc/rfc9922.html
إحاطة الأعضاء
سياق أعمق للملف الشخصي
سجّل الدخول بمستوى العضوية المناسب لفتح الإحاطة الكاملة وملاحظات المصادر.
للدائرة الاستراتيجية فقط
الدائرة الاستراتيجية
مفتوح لجميع القراء. افتح إحاطات الملف الشخصي بعد الانضمام وتسجيل الدخول.
انضم إلى الدائرة الاستراتيجيةلأعضاء تحالف القيادات فقط
تحالف القيادات
لأصحاب الأصول الفكرية المؤهلين وللإدارة؛ سجّل الدخول للوصول إلى إحاطات التحالف.
انضم إلى تحالف القيادات

