الخلاصة

  • في 25 أغسطس 2026 وافق IESG على draft-ietf-idr-sr-policy-seglist-id-14 بصفته Proposed Standard. وعند تثبيت حزمة الأدلة بقي النص Internet-Draft نشطاً في طابور RFC Editor، بينما ظل سجل IANA يعرض القيمة 19 كتخصيص مؤقت.
  • معرّف Segment List ID ذو 32 بت فريد فقط داخل Candidate Path واحدة. ليس هوية عالمية، ولا يجعل ترتيب SID غير قابل للتغيير. لذلك يجب ربط المعرّف بالسياق والمحتوى الحالي وتحديث BGP المستلم وقرار SRPM وحالة البرمجة وحركة المرور.

لوحة خضراء لا تعني مساراً ثابتاً

قبل نافذة صيانة، تسمي وحدة التحكم قائمة من ثلاث تعليمات مرتبة بالرقم 42. تستخدم عملية NETCONF وسلسلة القياس ولوحة الضمان الرقم نفسه. أثناء التغيير تستبدل وحدة التحكم ترتيب SID، لكنها تحتفظ بالرقم. لا يظهر انقطاع في الرسم وتبقى الحالة خضراء.

هذا اختبار تحليلي وليس حادثة منسوبة إلى مشغل أو مورّد. ما استمر هو المرجع، لا التعليمات التي كان يشير إليها. إذا كان مفتاح قاعدة البيانات هو 42 وحده فقد ضاع Candidate Path. وإذا احتفظ النظام بالمسار والرقم من دون وقت أو بصمة للمحتوى، فقد يدمج حالتين تاريخيتين مختلفتين.

الموافقة ليست نهاية مسار النشر

يقول إعلان 25 أغسطس إن المراجعة 14، التي أعدتها مجموعة Inter-Domain Routing، أُقرت كـ Proposed Standard. لكن Datatracker في 28 أغسطس كان لا يزال يعرض Active Internet-Draft وحالة RFC Ed Queue، مع انتظار فحص المراجع والتنسيق واستمرار إجراء IANA بعد تغيير النسخة. يحمل النص تاريخ 24 أغسطس، وحُدث السجل في 26 أغسطس، وتنتهي صلاحية المسودة في 25 فبراير 2027.

كان سجل IANA العام يعرض القيمة 19 كتخصيص مؤقت سُجل في 19 ديسمبر 2025 وينتهي بعد عام، مع إحالة إلى مراجعة أقدم. موافقة IESG، وصدور RFC مرقّم، والتسجيل الدائم، والنشر التشغيلي أربع وقائع منفصلة.

المعرّف يحل مشكلة مطابقة حقيقية

قد تحتوي SR Policy على عدة Candidate Paths، وقد تضم كل واحدة عدة قوائم مقاطع. يحدد RFC 9830 كيف ينقل BGP معلومات المسار المرشح إلى headend الذي يكتب تعليمات المقاطع في الرزم.

من دون رقم موجز قد يكرر القياس عن بُعد ترتيب SID كاملاً، ثم تقارن وحدة التحكم العناصر واحداً واحداً. كما تحتاج إعدادات YANG أو NETCONF إلى الإشارة إلى قائمة جرى تعلمها عبر BGP. يقلل العدد من البيانات ومن كلفة الربط، لكنه لا ينشئ كياناً عالمياً.

يوضع الـ sub-TLV الاختياري داخل Segment List من النوع 128 تحت SR Policy Tunnel Type ذي النوع 15. نوعه 19 وطوله ست ثمانيات، منها أربع للعدد غير الموقّع، فيما ترسل الأعلام والمحجوزات بصفر. القيم من 1 إلى 0xffffffff معرّفات، والصفر يعني عدم التخصيص ويعادل غياب الـ sub-TLV.

السياق جزء من المفتاح

يجب أن يكون المعرّف غير الصفري فريداً بين القوائم داخل Candidate Path واحدة فقط. يمكن أن يتكرر قانونياً في مسار مرشح آخر أو سياسة أخرى أو headend آخر من دون أن يدل على التعليمات نفسها. ولهذا يجب أن يتضمن أي مرجع خارجي هوية Candidate Path.

حتى الزوج المكوّن من المسار والمعرّف ليس هوية تاريخية كاملة. تسمح المواصفة ببقاء ID مع تغيير ترتيب SID. فهو أقرب إلى خانة قابلة للتعديل منه إلى عنوان مشتق من المحتوى.

يتطلب سجل التدقيق NLRI الخاص بالسياسة، بما في ذلك Distinguisher وColor وEndpoint، وهوية Candidate Path، والمعرّف، والترتيب الكامل لـ SID، ووقت نفاذ الربط أو رقم مراجعته أو بصمته. التقارب مع معرّف BGP-LS في RFC 9857 أو مراجع YANG/NETCONF لا ينشئ فضاء أسماء عالمياً؛ على كل مستهلك حفظ النطاق والنوع والحداثة.

لكل خطأ نتيجة مختلفة

إذا لم يكن الطول ست ثمانيات يصبح NLRI المرتبط مشوهاً ويطبق RFC 7606 إجراء treat-as-withdraw. سحب وصف التحكم لا يثبت أن حركة المرور انتقلت بأمان.

إذا ظهر الـ sub-TLV عدة مرات داخل قائمة واحدة يأخذ المستقبل الأول ويتجاهل البقية. أما تكرار ID غير صفري بين قوائم Candidate Path نفسها فهو خطأ دلالي يتولاه SRPM، وقد يعامل جميع تلك القوائم كأنها بلا ارتباط بالمعرّف.

في أسطول مختلط قد يعد headend قديماً المسار غير قابل للاستخدام عند وجود sub-TLV غير معروف، وفق السلوك الافتراضي في RFC 9830. لذلك توصي المسودة بالإعلان الانتقائي للعقد التي تدعم الامتداد. كلمة «اختياري» تصف الترميز ولا تضمن انعدام الأثر التشغيلي.

BGP يحمل الوصف، بينما يجري SRPM التحقق. بعد ذلك تأتي قابلية الاستخدام والاختيار النشط والبرمجة في headend ومرور الرزم. سلسلة الدليل تفصل بين نسخة الوثيقة وحالة IANA، وقدرة كل نظير، وUPDATE المستلم، وربط المسار بالمعرّف والمحتوى، وقرار SRPM، والاختيار، والبرمجة، والعدادات المرتبطة بالمراجعة نفسها، والنتيجة المرصودة.

تحذر المسودة أيضاً من أن المعرّفات قد تكشف علاقات تشغيلية حساسة، لذا ينبغي قصرها على أجهزة وتطبيقات موثوقة في نطاق SR. أما التخصيص بين وحدات التحكم وإعادة الاستخدام والنسخ والاحتفاظ والتراجع فتقع خارج نطاق النص. وبيانات H3C وZTE مبنية على المراجعة 3، ومحدثة في فبراير 2025، ومقدمة ذاتياً؛ ليست اعتماداً من IETF ولا تحققاً مستقلاً.

المصادر