الخلاصة

  • ينص RFC 9917، وهو معيار مقترح من IETF نُشر في يناير 2026، على قيود reverse-affinity تستعمل مجموعات Administrative Group الممتدة على الحافة العكسية كي تُبقي الحافة الأمامية أو تستبعدها أثناء حساب مسار Flex-Algorithm. وهو يحدّث RFC 9350 وRFC 9843.
  • الحالة العملية ليست «اكتشاف عطل ثم إصلاحه» آلياً. على المشغّل أن يملك القياس، ويحدد عتبة التعيين وعتبة الإزالة، ويتحقق من الترميز ومن FAD الفائز، ثم يختبر التقارب والتراجع.

كيف تعمل الآلية

تبدأ الحالة من حافتين موجّهتين: حافة أمامية تخرج عبرها الحركة، وحافة عكسية تمثل الاتجاه المقابل. قد يرى المستقبل البعيد أخطاء إدخال لا تظهر عند المرسل؛ ويذكر RFC CRC errors كمثال فقط. إذا تجاوز القياس عتبة يحددها المشغّل، يمكن وضع Extended Administrative Group على الحافة العكسية. عندئذ تقرأ عملية حساب المسار هذه الإشارة بوصفها قيداً على الحافة الأمامية المقابلة. RFC 9917 لا يحدد عتبة عامة ولا يثبت أن كل جهاز يربط القياس الحي تلقائياً بالمجموعة الممتدة.

توجد عائلات القيود الثلاث في كل من IS-IS وOSPF: exclude يستبعد الحافة عندما تتطابق المجموعة المطلوبة، وinclude-any يتطلب تطابق أي مجموعة من القائمة، وinclude-all يتطلب تطابق جميع المجموعات المطلوبة. المقصود هنا هو Reverse Administrative Group constraint؛ وليس ضماناً لتماثل الإرسال والاستقبال على المستوى الفيزيائي، ولا تفويضاً بأن كل موجّه يدعم كل قيد في كل Flex-Algorithm.

ترتيب القواعد والترميز

أضاف RFC 9917 قواعد حساب المسار 8 و9 و10 إلى سجل pruning مرتب، بعد قواعد RFC 9350 وRFC 9843 القائمة. هذا السجل ليس قائمة قابلة لإعادة الترتيب حسب تفضيل المورّد: لا يجوز تغيير الترتيب النسبي للقواعد الموجودة، ولا حذف قاعدة أو دمجها أو تكرارها. لذلك يجب أن يفوز FAD الصحيح أولاً، ثم تُقرأ القيود وفق ترتيبها المعياري؛ فقبول FAD نحوياً وحده لا يكفي إذا اختلفت الطوبولوجيا المحسوبة بين الموجّهات.

يحدد RFC 9917 أيضاً معالجة حالات الإدخال غير السليم على نحو يجب اختباره لا تخمينه: أطوال reverse-affinity sub-TLV المشوهة تُتجاهل، أما تكرار الظهور فيستدعي سلوك المستقبل المحدد لـIS-IS وOSPF. لا ينبغي تحويل ذلك إلى قاعدة تشغيلية إضافية أو افتراض أن كل تنفيذ يتعامل مع التكرار بالطريقة نفسها خارج النص المعياري. ويتولى RFC 7308 صيغة ترميز Extended Administrative Group، ولذلك يلزم فحص الطول والقيم والتكرار قبل إعلان نجاح التجربة.

خطر الانتشار والتقارب

إذا تغيرت المجموعة مع كل عينة قياس، فقد تنتشر تحديثات IGP ويتكرر حساب المسارات، فتتحول إشارة حماية إلى مصدر churn. يطرح RFC 9917 فصل عتبة set عن عتبة clear/unset لتقليل التذبذب، مع إمكان استخدام throttling العادي لـIGP. هذه وسائل تحكم محتملة، وليست عتبات تشغيلية مفروضة من RFC. يجب قياس زمن الانتشار، وعدد عمليات إعادة الحساب، وعدد تغييرات الحافة المستبعدة، وما إذا كان المسار البديل مستقراً عند التعيين والإزالة.

تحليل Theo March

القرار الجيد هو قرار سلسلة كاملة: من يملك telemetry؟ من يوافق العتبات؟ هل يثبت الجهاز ترميز RFC 7308؟ هل تتفق العقد على FAD الفائز وعلى ترتيب القواعد؟ هل يغطي الدعم IS-IS وOSPF والقيود الثلاثة؟ وهل يمكن رؤية الفرق بين الحافة الأمامية وخصائص الحافة العكسية؟ ينبغي أن تتضمن التجربة حالة set وحالة clear، وقياساً قبل وبعد، وسجلّاً لـFAD والطوبولوجيا المقلمة، وخطة rollback تعيد السياسة السابقة من دون انتظار استنتاج غير قابل للعكس.

هذه المذكرة ليست عن إعادة تشغيل PCEPS أو حماية TLS 1.3 المبكر في RFC 9916، ولا عن دورة حياة تأجير DHCPv6 في RFC 9915، ولا عن إسقاط المسارات في RPL كما في RFC 9914، ولا عن تعافي RAW في RFC 9912. موضوعها أضيق: جعل الدليل القادم من الاتجاه العكسي مدخلاً مرتباً إلى تقليم IGP Flex-Algorithm.

سجل الادعاء إلى RFC

الادعاء الدليل
reverse affinity، القواعد 8–10، وحالة Proposed Standard RFC 9917
نموذج Flex-Algorithm وFAD الفائز والقواعد السابقة RFC 9350
القيود السابقة وترتيبها قبل الإضافات الجديدة RFC 9843
ترميز Extended Administrative Group RFC 7308
قواعد RFC 9917 التفصيلية للـIS-IS وOSPF والتكرار والأطوال RFC 9917، الأقسام 5–12

مسار قرار القبول

  1. الملكية: عيّن مالكاً للقياس ومصدراً موثقاً للـinput errors؛ لا تفترض أن RFC 9917 يجمع القياس وحده.
  2. العتبات: اختبر set وclear كلّاً على حدة، مع توثيق سبب كل قيمة واختبار hysteresis.
  3. الترميز: تحقق من Extended Administrative Group، والأطوال المشوهة، والتكرارات، وسلوك IS-IS وOSPF المتوقع.
  4. السياسة: تحقق من FAD الفائز، ومن تطبيق exclude وinclude-any وinclude-all ومن بقاء ترتيب القواعد.
  5. الدعم والتقارب: أثبت تغطية الأجهزة، وراقب flooding وإعادة الحساب وزمن الوصول إلى مسار مستقر.
  6. القبول أو الرفض: اقبل فقط إذا كانت الملاحظة end-to-end والنتيجة قابلة للتفسير. وإلا فاعزل الإشارة، أعد السياسة السابقة، وسجّل سبب rollback.