الخلاصة

  • يصف RFC 9791، وهو RFC من فئة Informational منشور في يوليو 2025، حالة استخدام NFFRR: بعد إصلاح سريع أول قد يؤدي إصلاح ثانٍ للحزمة نفسها إلى حلقة، فتُستخدم علامة لمنع FRR إضافي. لكنه لا يعرّف إجراء NFFRR كاملاً ولا يمنح NFFRR تخصيصاً مستقلاً قابلاً للاستدلال منه على النشر.
  • المسودتان draft-kompella-mpls-nffrr-04 وdraft-li-mpls-mna-nffrr-01 منتهيتان. إشاراتهما وآلياتهما وقيم TBA أو المقترحات الخاصة بالبتات والتخصيصات ليست سجلاً حالياً ولا دليلاً على تطبيق مصنّع أو تشغيل بيني.
  • المشكلة الأعمق ليست «هل يمكن وضع علامة؟» بل «من يملك سلطة التضحية بإصلاح لاحق؟». صلاحية هذا القرار تعتمد على صحة تصور العطل والطوبولوجيا، وعلى قدرة العقد التالية على فهم العلامة، وعلى حدود الثقة، وعلى إمكان إعادة بناء سبب الإسقاط بعد الحادث.
  • حتى 2026-09-20 لا يظهر NFFRR كتخصيص في سجل IANA MPLS Network Actions. لذلك يجب الفصل بين حالة الاستخدام الموثقة، والبنية العامة لـ MNA، وأي إجراء NFFRR معياري مستقبلي لم يُعرّف بعد.

من حلقة محلية إلى قرار عابر للعقد

يضع القسم 2.1 من RFC 9791 المشكلة بصياغة عامة: بعد أن تعيد FRR الأولى توجيه حزمة بعيداً عن عطل، قد تصادف الحزمة عقدة أخرى تطبق FRR ثانية فتحدث اضطراباً أو حلقة. والحل الذي يعرضه النص على مستوى حالة الاستخدام هو تمييز الحزم التي خضعت بالفعل لإعادة توجيه كي لا تُخضع لإصلاح سريع آخر.

لكن التفاصيل التي تجعل المثال حاداً تظهر أوضح في المسودة المنتهية. في EVPN active-active، تعطل CE2 الحقيقي الواحد يظهر أمام PE2 وPE3 كفشل كل منهما في وصلة منفصلة. يحاول PE2 حماية الحركة فيرسلها عبر المسار الاحتياطي إلى PE3. ويحاول PE3 حماية ما يراه عطلاً ثانياً فيعيدها إلى PE2. لا تحتاج الحلقة هنا إلى جهاز «يتصرف بجنون»؛ تنشأ من تركيب قرارين محليين لهما منطق معقول تحت مشاهدتين ناقصتين.

من هنا تتغير وظيفة العلامة. عند أول تحويل، لا تقول العقدة فقط «لقد طبقت FRR». بل تطلب من مستقبل لاحق: إذا واجهت فشلاً آخر، لا تستخدم خيار الحماية الذي كنت ستستخدمه عادة. أي إن PLR الأول يصدر قيداً على حرية PLR الثاني. وإذا كان المصير البديل هو الإسقاط، فالقرار الأول قد يكون سبباً في التضحية عمداً بفرصة توصيل لاحقة كي يحمي المسار المشترك من حلقة واستهلاك متكرر للسعة.

معيار حالة استخدام، لا ترخيص نشر

من المهم تثبيت حدود الوثائق. RFC 9791 Informational، صدر في يوليو 2025، ويعرض حالات استخدام لـ MPLS Network Actions. أما RFC 9789، الصادر أيضاً في يوليو 2025، فيقدم إطار MNA: النطاقات، بنية الإشارات، مفهوم القدرة، وReadable Label Depth، والحاجة إلى أن يعرف من يستخدم MNA قدرات العقد التي ستمر بها الحزمة.

ثم جاء RFC 9994، وهو Proposed Standard من يونيو 2026، ليعرّف الترميز العام لـ MNA داخل المكدس، مواضع Network Action Sub-Stack ونطاقات I2E وHop-by-Hop وSelect، وقواعد التعامل مع إجراء غير معروف. إذا كانت قيمة U تساوي 0 تتجاوز العقدة الإجراء غير المعروف وتنتقل إلى الإجراء التالي؛ وإذا كانت U تساوي 1 تُسقط الحزمة، مع عداد محلي موصى به وإمكان إخطار محدود المعدل للمشغل.

لكن RFC 9994 لا يعرّف NFFRR. وكذلك لا ينبغي قراءة البت TBA في draft-li-mpls-mna-nffrr-01، أو مقترحات SPL والقدرات في draft-kompella-mpls-nffrr-04، كأنها تخصيص قائم. المسودتان انتهتا، وسجل IANA المعني لم يكن في 2026-09-20 يسجل NFFRR.

هذا التفريق حاسم: وجود إطار ترميز صالح لا يجعل كل فعل تصوره المؤلفون فعلاً معيارياً مسجلاً.

سلامة FRR ليست خاصية للعلامة وحدها

يعود أصل الإصلاح السريع في MPLS إلى أعمال مثل RFC 4090، لكن ضمان أن البديل «آمن» لا ينفصل عن نموذج العطل والطوبولوجيا. يوضح RFC 5286 أن تغطية Loop-Free Alternates تعتمد على شكل الشبكة، وأن فشلاً أوسع من الفشل الذي صُمم البديل لحمايته قد يؤدي إلى حلقات مؤقتة. ويوسع RFC 7490 الفكرة باستخدام Remote LFA ومساحات P وQ للحصول على حماية إضافية.

وفي Segment Routing، يقدم RFC 9855 TI-LFA، مع مسار إصلاح مبني على المسار المتوقع بعد التقارب ضمن افتراضاته المحددة. لا تلغي هذه الوثائق الحاجة إلى نموذج عطل؛ بل تبين أن عبارة «بديل خالٍ من الحلقة» لها شروط هندسية.

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

العلامة الكاذبة والمفقودة والمتقادمة

المسودة draft-kompella-mpls-nffrr-04 تذكر صراحة خطراً أمنياً: يستطيع LSR خبيث أو مخترق إدخال NFFRR في مكدس التسميات، فيمنع حماية كانت ستعمل لولا ذلك ويتسبب في فقد غير ضروري. وهذا يضع NFFRR في مساحة الثقة نفسها التي يناقش RFC 5920 جوانبها العامة في أمن MPLS/GMPLS: من يحق له إدخال معلومات تؤثر في المعالجة، وكيف تُحمى الحدود من الحقن والانتحال.

لكن التهديد لا يقتصر على علامة زائفة. العلامة المفقودة تعيد إمكانية FRR ثانية والحلقة التي أراد النظام منعها. والعلامة المتقادمة قد تستمر مع حزمة بعد أن تغير السياق الذي بررها، فتقيد قراراً لاحقاً بناءً على حالة لم تعد ممثلة لما يعرفه المستقبل. والعلامة المنتحلة تحول «منع الحلقة» إلى وسيلة حرمان من الحماية. أما العلامة التي تُقرأ بمعنى مختلف، أو لا تُفهم أصلاً، فتدخلنا في قواعد الإجراء غير المعروف وفي اختيار U، لا في معنى NFFRR نفسه.

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

المسار مختلط القدرات هو اختبار السلطة الحقيقي

يجعل RFC 9789 معرفة القدرات جزءاً من الإطار، بينما يضع RFC 9994 قواعد فعلية لوضع NAS بحيث تكون قابلة للقراءة لدى العقد المعنية. وهذا يمنع اختزال القضية إلى «أدخل العلامة وانتهى الأمر».

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

إيصال تقييد FRR

أقترح هنا، بصفتي الكاتب، «إيصال تقييد FRR» كأداة حوكمة تشغيلية. هذا اقتراح تحريري من Daniel Kade، وليس مطلباً في أي RFC مذكور. الغرض منه أن يصبح قرار منع FRR ثانية قابلاً للمراجعة بعد وقوعه بدلاً من أن يختفي داخل سلوك forwarding سريع.

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

الفكرة ليست تسجيل كل حزمة كسجل إداري ثقيل. المطلوب الحفاظ على سلسلة دليل كافية لشرح لماذا تحولت «حماية» إلى «منع حماية».

المصادر