الخلاصة

  • نشرت IETF في 5 سبتمبر 2026 النسخة 18 من Traffic Steering using BGP FlowSpec with SR Policy. وعند إغلاق البحث بقيت Internet-Draft في حالة AD Evaluation::External Party، وليست RFC معتمدة.
  • كانت النسخة 17 تفرض الرجوع إلى Redirect-to-IP العادي إذا وُجد هدف إعادة توجيه وغاب Color صالح. النسخة 18 تمنع هذا الرجوع عند وجود نية SR غير مكتملة، وتطلب إسقاط الحركة المطابقة أو تطبيق سياسة فشل محلية.
  • يبقى مسار FlowSpec الصالح في Loc-RIB ويستمر إعلانه حتى عندما تكون SR Policy متوقفة أو غير قابلة للحل أو غير مثبتة في FIB/TCAM. وجود السجل في مستوى التحكم لا يثبت ما حدث للحزمة.
  • تقول فقرة التوافق الحالية إن headend غير الداعم يمكنه تجاهل Prefix-SID غير المعروف والعودة إلى Redirect-to-IP. لذلك قد تُسقط الرسالة نفسها في جهاز وتُعاد توجيهها في جهاز آخر داخل بيئة مختلطة.
  • تناولت آخر مراجعة للفريق النسخة 13. وبعد النسخة 17 طلب Area Director من رئيسي IDR استطلاع الإجماع مجدداً. يجب أن يسمي الإغلاق النسخة ومصفوفة الفشل وسلوك التوافق التي وافق عليها الفريق فعلاً.

الحقل الناقص لم يعد إذناً بالمسار الأسهل

يوزع FlowSpec عبر BGP قواعد تحدد الحزم ثم تربطها بإجراء. تضيف المسودة توجيه الحركة إلى Segment Routing Policy: يقدم Redirect-to-IP نقطة النهاية، ويقدم Color Extended Community اللون، فيتكون المفتاح (Endpoint, Color). وفي وضع ثان خاص بـSRv6، يحمل BGP Prefix-SID معرّف خدمة ينفذ وظيفة معينة عند الخروج.

هنا توجد ثلاث رسائل متشابهة لا يجوز دمجها. Redirect-to-IP وحده، من دون أي سمة SR، يبقى إعادة توجيه IP عادية. الهدف مع Color صالح يختار SR Policy. أما وجود Prefix-SID مع الهدف وغياب Color الصالح، فيكشف نية استخدام SR من دون المفتاح الكافي لاختيار السياسة.

عاملت النسخة 17 الحالة الثالثة بتسامح: تتجاهل سمة الخدمة ويعود الموجّه إلى Redirect-to-IP. النسخة 18 تعكس القرار. لا يحق للجهاز الداعم أن يبحث عن سياسة افتراضية أو لون صفري، ولا أن يستخدم Prefix-SID، ولا أن يتصرف كأن الرسالة لم تحمل نية SR. تُسقط الحركة أو تُسلّم إلى سياسة الفشل المحلية المعلنة.

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

المسار يبقى والفعل يتوقف

تفصل النسخة 18 عمر سجل التحكم عن عمر إجراء التمرير. إذا كانت SR Policy متوقفة أو تعذر حلها أو فشل تثبيتها، يبقى مسار FlowSpec في Loc-RIB ما دام يجتاز تحقق BGP، ويواصل الانتشار إلى الجيران اللاحقين. فشل الطبقة الدنيا لا يبطل الرسالة تلقائياً.

أما إدخال التوجيه في مستوى البيانات فيجب ألا ينشط أو يجب أن يُعلّم بأنه Down. وإذا كانت السياسة عاملة لكن SID خدمة الخروج غير قابل للوصول في RIB/FIB المحلي، يمنع النص الرجوع الصامت إلى أقصر مسار IP. يوصي بالإسقاط كفعل محلي افتراضي، مع بقاء حق المشغل في اختيار سياسة أخرى. وتستمر إجراءات FlowSpec الصحيحة غير المتعلقة بالتوجيه، مثل تحديد المعدل.

يفيد هذا الفصل عند التعافي، إذ يمكن إعادة محاولة التثبيت من دون انتظار إعلان جديد. لكنه يجعل المؤشر الأخضر بجانب المسار دليلاً ناقصاً. يجب أن تسجل المعاينة أربع حالات مستقلة: قبول Loc-RIB، استمرار الإعلان، تثبيت FIB، ونتيجة حزمة اختبار.

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

الجهاز القديم يقرأ أمراً آخر

قد يدعم headend أساس FlowSpec وRedirect-to-IP من دون تنفيذ هذا الامتداد. وبما أن Prefix-SID سمة اختيارية انتقالية، يستطيع الجهاز تمريرها من دون فهمها، ويتجاهلها عند التوجيه المحلي ثم ينفذ إعادة التوجيه التي يعرفها.

تبقى البايتات واحدة وتتغير النتيجة. الجهاز الداعم للنسخة 18 يتعرف إلى نية SR الناقصة ويرفض الرجوع. الجهاز القديم لا يملك هذه الفئة الدلالية ويرى هدفاً صالحاً لإعادة التوجيه. لا يلزم تلف في الرسالة ولا سقوط جلسة BGP؛ تكفي فجوة قدرة لم تُسجّل.

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

الاختبار الحاسم هو اختبار الغياب: Redirect-to-IP صرف، وMode 1 وMode 2 صالحان، وColor مفقود أو تالف، وسياسة متوقفة، وSID غير قابل للوصول، وفشل FIB، ومستقبل غير داعم. لكل حالة ينبغي ربط Loc-RIB والإعلان وFIB وعدّاد الإسقاط أو إعادة التوجيه والحزمة المرصودة والإنذار والحجب والتعافي.

إجماع النسخة 13 لا يتحدث باسم النسخة 18

يسجل تقرير الـshepherd أن المراجعة السابقة للفريق كانت أسبوعاً واحداً على النسخة 13 وحصلت على تأييد إيجابي. ثم أضافت مراجعة Area Director وضعين تشغيليين، وتسلسلاً لحل السمات، ووظائف خدمة أوسع، وقواعد للفشل والتوافق، ونصاً أكبر للتشغيل والأمن.

في 26 أغسطس، بعد صدور النسخة 17، طلب Area Director المسؤول من رئيسي IDR استطلاع الفريق مرة أخرى قبل التقدم. انتقل السجل إلى AD Evaluation::External Party. وفي 5 سبتمبر أضافت النسخة 18 تغييراً جوهرياً آخر: ألغت الرجوع في حالة النية الناقصة، وأدخلت فشل SID غير القابل للوصول، ووسعت قواعد تركيب المقاطع والحدود والرصد.

إعادة السؤال ليست زينة إجرائية. يمكن لمشارك أن يؤيد ربط FlowSpec بـSR Policy لكنه يرفض اختيار fail-closed. قد تعد خدمة أمنية الانحراف عن السياسة أخطر خسارة، بينما ترى خدمة توافر أن الإسقاط الممكن تجنبه أسوأ. rough consensus هو حكم بأن الاعتراض التقني فُهم وعولج، وليس تفويضاً ينتقل من جدول قديم كانت نتيجته معاكسة.

ينبغي أن يسمي الاستطلاع النسخة 18 وقراراتها: Color الناقص، وبقاء المسار، وفشل policy أو SID، وسلطة السياسة المحلية، وسلوك الجهاز غير الداعم. كما يجب أن يحفظ الإغلاق الاعتراضات وتعليل الرئيسين، لا كلمة «إجماع» منفصلة عن النص.

للكود العامل تاريخ أيضاً

تذكر فقرة التنفيذ أربعة موجهات وأربعة متحكمات شاركت في اختبار تشغيلي بيني نظمته China Mobile من يوليو إلى أكتوبر 2021. وتذكر استخداماً إنتاجياً في عمودها الفقري منذ أغسطس 2022. لكن التنبيه في الفقرة نفسها يقول إن البيانات قدمها مساهمون، ولم تُتحقق مستقلاً، ولا تعني تأييد IETF.

تحدد التواريخ نطاق البرهان. لا تربط المصادر المفحوصة اختبارات 2021 بمصفوفة النسخة 18، أو بحالة SID غير القابل للوصول، أو بقاعدة استبدال SID أو إلحاقه، أو بأسطول يجمع أجهزة داعمة وغير داعمة. لا تستطيع جملة جديدة أن تضيف بأثر رجعي حالة إلى اختبار قديم.

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

إيصال يربط النص بالجهاز والحزمة

يبدأ إيصال الإجماع ببصمة مصدر النسخة 18، وموعدي الاستطلاع، والسؤال الكامل، وأرشيف الردود، والاعتراضات، وتقييم الرئيسين. ويستخدم سجل التشغيل البيني النسخة نفسها، ويفرد صفوفاً لإعادة التوجيه العادية والوضعين الصحيحين وColor غير الصالح والسياسة المتوقفة وSID غير القابل للوصول وفشل FIB.

يقسم كل صف نتيجة الجهاز الداعم عن غير الداعم، ويفصل قبول المسار عن نشره وتثبيت الإجراء ونتيجة الحزمة. تكمل العدادات والإنذارات وحالة حجب السجلات السلسلة.

ثم يسجل النشر المرسل ومجموعات المستقبلين والنسخ والمرشحات ونطاقات SID المسموحة وسياسة الفشل وإعادة المحاولة والاختبار المحدود وشرط التراجع. يمكن ترميز العناوين الحساسة بأسماء ثابتة؛ لا يجوز إخفاء النسخة أو النتيجة. ويضاف التصحيح من دون محو الفشل الأول.

تعمل فكرة الحد الأدنى للمواصفة عند Heng Lu هنا كمقياس تحريري فقط. يجب أن يكون المعنى المشترك صغيراً وحتمياً وقابلاً للاختبار، بينما تبقى الخسارة المحلية قراراً للمشغل مع صاحب سلطة ودليل. لا اسم IETF ولا عبارة «سياسة محلية» يبرران فجوة قدرة خفية.

قد تكون النسخة 18 أفضل من 17. لكن عليها أن تحصل على موافقة تخص قاعدتها الحالية، وأن تثبت ما يفعله الجيلان من الأجهزة في لحظة الفشل. لا يستطيع إجماع النسخة 13 ولا اختبار 2021 القيام بذلك نيابة عنها.

المصادر

  1. IETF Datatracker — Traffic Steering using BGP FlowSpec with SR Policy
  2. IETF — نص النسخة 18
  3. IETF — نص النسخة 17
  4. IETF Author Tools — مقارنة النسختين 17 و18
  5. IETF Datatracker — سجل الوثيقة
  6. قائمة IDR — طلب إعادة استطلاع الإجماع
  7. IETF — تقرير الـshepherd
  8. RFC 8955 — Dissemination of Flow Specification Rules
  9. RFC 9256 — Segment Routing Policy Architecture
  10. RFC 7942 — Improving Awareness of Running Code
  11. RFC 7282 — On Consensus and Humming in the IETF
  12. Heng Lu — Minimum Initial Specification