الخلاصة

  • يستبدل RFC 9573 مساحات وسم مرتبطة بكل PE داخل بكتلة مشتركة على مستوى النطاق أو بعدد قليل من المساحات السياقية المشتركة.
  • لا يتحقق الوفر إلا إذا دعمت جميع أجهزة PE ونقاط التقسيم الإجراء وعرفت التخصيص نفسه؛ أما ضمان ذلك فيبقى خارج نطاق الوثيقة.
  • يحتاج النشر إلى إيصالات منفصلة لسلطة التخصيص والنسخة والحجز واختيار الجدول وتركيب FIB واتساق المسارات وتسليم حركة المستأجر.

الرقم وصل إلى الجميع، لكن سجل التخصيص لم يصل

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

يبدأ RFC 9573 من عبء حقيقي. في النموذج الذي يخصص فيه كل PE داخل وسومه، يفسر المستقبل الوسم ضمن سياق المرسل. ومع 1001 جهاز و1000 VPN أو BD في كل جهاز، قد يحتاج كل مستقبل إلى مليون تفسير موزع على ألف مساحة.

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

الشرط الإلزامي خارج مجال الرؤية

تشترط الوثيقة أن تدعم جميع أجهزة PE ونقاط التقسيم الإجراءات عند استخدامها، ثم تنص على أن طريقة ضمان هذا السلوك خارج نطاقها. كما يجري تعيين وسم كل VPN أو BD أو ES وإبلاغ أعضائه بطرق خارج النطاق.

لذلك لا يمثل DCB flag إثباتاً على اكتمال النشر. إنه يحدد أن الوسم المعلن أُخذ من Domain-wide Common Block. لا يثبت أن كل جهاز حجز الكتلة نفسها، أو قبل النسخة نفسها، أو كتب الإدخال الصحيح في عتاد التحويل.

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

اختيار الجدول ليس مصادقة على محتواه

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

تجعل Context-Specific Label Space ID Extended Community هذا السياق صريحاً. ويركب المستقبل إدخال المحدد في جدول MPLS الافتراضي، ثم يركب وسم الخدمة في الجدول السياقي. هذان رابطان منفصلان؛ صحة الأول لا تصلح خطأ الثاني.

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

التقسيم يعيد الحاجة إلى تخصيص محلي مضبوط

قد يحمل نفق انتقائي واحد تدفقين في المنطقة A، ثم ينقسم التدفقان إلى نفقين مختلفين في المنطقة B. تحتاج نقطة التقسيم إلى التمييز بينهما كي تبدّل وسم كل تدفق إلى المسار الصحيح.

يخصص RFC 9573 كتل وسوم غير متداخلة لكل PE داخل مساحات سياقية قليلة. يختار كل PE وسوم PMSI المقسمة من كتلته. لا تعود الجهة المركزية مسؤولة عن كل قيمة، لكنها تبقى مسؤولة عن حدود الكتل وملكية كل حقبة ومنع إعادة الاستخدام المبكر.

أما البديل فيجري بحث (C-S,C-G) داخل VRF عند نقطة التقسيم. يقل عدد الوسوم ويزداد عدد مسارات التدفق. إنها نقلة في موضع الحالة، لا إلغاء لها.

التناقض ينسحب ولا يُفسَّر بالتخمين

لا يجوز أن يحمل المسار DCB flag ومعرّف المساحة السياقية معاً. إذا اجتمعا، يُعامل المسار كمسحوب. وإذا غابا معاً، يعود التفسير السابق المرتبط بمساحة PE المصدر.

ويجب على مسارات x-PMSI أو IMET التي تشترك في النفق أن تستخدم نظام تفسير متجانساً. مزج الأنظمة يجعل المستقبل عاجزاً عن تحديد الجدول الذي يقرأ منه الوسم التالي، فيعاملها كمسحوبة.

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

التسجيل يثبت الشفرة لا الحالة التشغيلية

خصصت IANA بت DCB والنوع الفرعي للـ Extended Community وسجل أنواع المعرّف. يضمن ذلك لغة سلكية مشتركة. ولا يثبت وجود تنفيذ أو تفعيل الميزة أو سلامة تخصيص بعينه.

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

Sources

المصادر