الخلاصة

  • نشر IETF في 19 أغسطس عند 09:22:08 UTC المراجعة 38 من مقترح استرجاع طوبولوجيا inter-AS عبر BGP-LS. والتغيير الموضوعي الوحيد عن المراجعة 37 هو حذف Multi-Topology Identifier، أي TLV 263، من قائمة واصفات Inter-AS Link NLRI المقترحة.
  • لا يختفي MT-ID من BGP-LS. إنما تغيّرت مادة تعريف الكائن الجديد، ولذلك تصبح سلامة سحب الهوية القديمة ومنع التكرار والحفاظ على عزل الطوبولوجيات هي الأدلة التالية المطلوبة.

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

يسجل سجل Datatracker إتاحة draft-ietf-idr-bgpls-inter-as-topology-ext-38 في 19 أغسطس عند 09:22:08 UTC. وتبيّن مقارنة بنيوية بين النصين الرسميين للمراجعتين 38 و37 أن التعديل التقني الوحيد، بعد رقم النسخة والتاريخ، هو إزالة سطر TLV 263.

يعالج المقترح فجوة بين نطاقات IGP. يتيح BGP-LS في RFC 9552 لكل نطاق أن يرسل طوبولوجيته إلى مستهلك مثل تطبيق SDN. وإذا كانت جهة تشغيل واحدة تدير عدة نطاقات وعدة أنظمة مستقلة، فقد يملك المتحكم خرائط داخلية منفصلة من دون أن يعرف الوصلات التي تربطها.

لذلك يقترح النص النوع 7، Inter-AS Link NLRI، ويضيف TLV لرقم النظام المستقل البعيد وآخرين لمعرّفَي IPv4 وIPv6 لموجه الحدود البعيد. يعلن كل طرف نصف وصلة أحادي الاتجاه، ثم يربط المستهلك النصفين ويجمع خريطتي النطاقين قبل حساب مسار من طرف إلى طرف.

كانت المراجعة 37 تسرد، بعد الحقول الجديدة، معرّفات الوصلة المحلية والبعيدة، وعناوين الواجهة والجار في IPv4، ونظائرها في IPv6، ثم MT-ID. أما المراجعة 38 فتتوقف عند عنوان جار IPv6. وتبقى الجملة التالية كما هي: قد يؤدي استخدام TLV أخرى كواصفات إلى صعوبة في مطابقة نصفي Inter-AS Link عندما تختلف تطبيقات المنتجين.

لا يعني ذلك إلغاء MT-ID من البروتوكول. فما زال RFC 9552 يعرّف النوع 263 بأنه Multi-Topology Identifier. وفي Link NLRI العادي يجب تضمينه إذا كانت وصلة IGP تنتمي إلى طوبولوجيا غير افتراضية، كما يجب إنشاء NLRI منفصل لكل معرّف طوبولوجيا. وتظل المراجعة 38 نفسها تذكر MT-ID ضمن معلومات الشبكة الحرجة في قسم الأمن.

التغيير المحدد يقع في عقد تعريف Inter-AS Link NLRI الجديد. قد يضم منتج يتبع المراجعة 37 الحقل 263 إلى المفتاح، بينما يحذفه منتج يتبع المراجعة 38. إذا عدهما المستهلك مفتاحين مختلفين فقد يحتفظ بنسختين من نصف الوصلة نفسه؛ وإذا دمجهما بلا تمييز فقد يطمس فرقاً مشروعاً بين طوبولوجيتين.

يضع RFC 9552 قاعدة واضحة لهذا النوع من الانتقال. عند إضافة TLV أو حذفه أو تعديله في Link-State NLRI، يجب على المنتج سحب NLRI القديم. وإلا فقد تبقى كائنات مكررة وغير متسقة في جدول BGP-LS. هذه قاعدة اختبار للمراجعة الجديدة، وليست دليلاً على وقوع عطل فعلي.

ويظهر سجل IANA لمعاملات BGP-LS طبقة أخرى لم تكتمل. وعند الاطلاع عليه في 19 أغسطس، كان يعرض 7 أغسطس تاريخاً لآخر تحديث، وما زال النوع 7 يسمى Stub Link NLRI ويشير إلى المراجعة 17، بينما تسميه المراجعة 38 Inter-AS Link NLRI. وتحمل TLV من 270 إلى 272 أسماء رقم AS البعيد ومعرّفَي ASBR البعيد، لكنها ما زالت تشير إلى المراجعة 17.

توضح صفحة حالة الوثيقة موقع ذلك في العملية. يهدف المشروع إلى Proposed Standard، وقد أُرسل إلى IESG ووصل إلى AD Followup. حالة مراجعة IANA هي Version Changed - Review Needed، في حين أن مراجعات الخبراء Expert Reviews OK. ولا تعني هذه الحالات أن الوثيقة أصبحت RFC أو أن التوافق بين منتجات مستقلة قد ثبت.

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

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

المصادر