الخلاصة

  • اكتملت في 27 سبتمبر مراجعة مبكرة أجراها Donald Eastlake لصالح Routing Area Directorate، وصنفت المشروع «Not ready». إنها ملاحظة مراجع على مسودة نشطة لمجموعة IDR، لا رفض من IESG ولا تغيير نافذ في BGP.
  • تقترح النسخة 13 التحقق من وصول الموجّه التالي في قاعدة تمرير مستوى البيانات المختار بصيغة SHOULD، وتجيز فحص توافر المسار بصيغة MAY. لكنها لا تقول صراحة هل يستبعد الإخفاق ذلك المسار من اختيار الأفضل.
  • يطالب المراجع بمطابقة الفحص للحالة التي ستستخدمها الحزم بالفعل؛ فمدخل LDP أو معرّف Segment Routing أو النفق أو الحل العودي ليست أدلة متكافئة على المسار نفسه.

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

الحدث الجديد هو اكتمال المراجعة. وضع Donald E. Eastlake III تاريخ 25 سبتمبر على نصه، وسجل IETF اكتمالها في 27 سبتمبر بنتيجة «Not ready». ما زالت النسخة 13، المؤرخة 14 سبتمبر، Internet-Draft نشطة داخل مجموعة IDR وتستهدف صفة Proposed Standard؛ تظهر لدى IESG بحالة «I-D Exists» ومن دون موعد اجتماع. عبارة تحديث RFC 4271 في رأس الوثيقة مقيدة بالموافقة. سبق للمجموعة أن أجرت Last Call ومراجعة مدير مجال عام 2020 من دون إكمال المسار آنذاك. لذلك لا تعني هذه النتيجة أن IESG رفضت النص أو أن قواعد BGP الحالية تغيرت.

في القسم الثالث عبارتان قصيرتان تحملان أصل الخلاف. الأولى تقول إن قابلية الوصول إلى الموجّه التالي SHOULD أن تُحسم في قاعدة تمرير بروتوكول مستوى البيانات الذي اختارته السياسة. والثانية تقول إن فحص توافر المسار بواسطة OAM MAY أن يُجرى على المستوى نفسه. تترك المسودة اختيار السياسة وآلية القياس خارج نطاقها. يوافق المراجع على واقعية الفجوة، لكنه يسأل عن نتيجة الإخفاق: تنص RFC 4271 بالفعل على استبعاد الطريق غير القابل للحل من وظيفة القرار في مرحلتها الثانية. لا تنص النسخة 13 بوضوح على أن فشل أي من الفحصين الجديدين يجعل الطريق غير قابل للحل بهذا المعنى. صيغة MUST التي يقترحها Eastlake تعديلٌ مطلوب، وليست شرطاً قائماً في النص.

ثم يأتي سؤال الدليل الصحيح. قد يعتمد الوصول عبر MPLS على ملصق مشتق من LDP، أو SID لبادئة Segment Routing، أو نفق RSVP-TE أو SR Policy، أو طريق BGP موسوم يستدعي حلاً عودياً. وربما يستخدم جار متصل مباشرة مدخلاً بلا ملصق. العثور على مدخل ناجح في قاعدة أخرى لا يثبت سلامة القاعدة التي ستتبعها الحزم. يريد المراجع أن يتبع الاختبار آلية التمرير المختارة والتسلسل العودي نفسه؛ وإلا فقد يختار تنفيذان مختلفان مسارين مختلفين انطلاقاً من معلومات BGP متطابقة.

هناك حد قائم ينبغي عدم تجاهله. تعتبر RFC 9012 الطريق غير قابل للحل إذا خلا حقل Tunnel Encapsulation من نفق ممكن. تسأل المراجعة عما تضيفه المسودة لهذا الحكم، من دون أن تثبت تناقضاً بين النصين. وتحذر أيضاً من اهتزاز إشارة OAM، أو إشارات حياة كاذبة، أو اختلاف أحكام موجّهات IP بما قد يخلق دورات تمرير. هذه مخاطر تصميم محتملة، لا حوادث مثبتة ولا إحصاءات عن الاستخدام الفعلي.

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

المصادر