الخلاصة

  • تنص النسخة 07 المؤرخة في 29 سبتمبر من مسودة مجموعة LSR في IETF على أن المعرّف البعيد المعلَن لعضو في تجميع من الطبقة الثانية يجب أن يساوي تماماً المعرّف المحلي غير الصفري ذي 32 بت الذي يعلنه الجار للعضو نفسه. وكانت النسخة 06 توصي باستعمال معرّف المنفذ المكتشف عبر LLDP.
  • يستطيع LLDP أو LACP المساعدة في معرفة المنفذ المقابل، لكن قيمهما لا تساوي بالضرورة رقم العضو المطلوب في إعلان التوجيه. كما أن توثيق رسالة IGP يثبت مصدر الرسالة، لا سلامة بيانات الاكتشاف في الطبقة الثانية التي بُني عليها الربط.

يجمع رابط الطبقة الثانية عدة أعضاء في وصلة منطقية واحدة. ويمكن لطبقة التوجيه التعامل مع هذه الوصلة من دون رؤية كل كابل على حدة. لكن وحدة تحكم تحسب مساراً على مستوى عضو بعينه، أو تحاول تحديد نطاق عطل، تحتاج إلى معرفة أي عضو في الجهاز الأول يصل إلى أي عضو في الجهاز الثاني. مسودة Advertisement of Remote Interface Identifiers for Layer 2 Bundle Members تقترح إعلان هذه المعرّفات في OSPF وIS-IS وإتاحتها لمستهلك BGP-LS. والتغيير في نسخة سبتمبر لا يثبت وجود نشر تجاري، بل يضبط معنى الرقم الذي يجوز إعلانه.

في نسخة 22 أغسطس كانت التوصية الحصول على Port ID الخاص بالجار عبر LLDP ثم استخدامه بوصفه معرّفاً بعيداً في الإعلان. وذُكرت أرقام المنافذ في LACP طريقاً بديلاً. أما النسخة 07 فتزيل هذا الاختصار. يمنح كل طرف أعضاءه معرّفات محلية غير صفرية من 32 بت. وعندما يعلن طرف معرّفاً بعيداً لأحد أعضائه، يجب أن يكون الرقم هو عين المعرّف المحلي الذي يعلنه الطرف الآخر للعضو المقابل. بهذه المساواة يمكن فحص الزوج من الجهتين بدلاً من الاكتفاء باسم منفذ يبدو معقولاً.

السبب تقني ومهم. يتغير شكل LLDP Port ID بحسب نوعه الفرعي، وقد لا يكون رقماً من 32 بت أصلاً. وأرقام Actor وPartner في LACP ذات 16 بت ويعيّنها الطرفان بصورة مستقلة. قد تكشف هذه البيانات هوية المنفذ الفيزيائي، لكنها لا تعطينا تلقائياً قيمة معرّف العضو المحلي الذي يعلنه الجار في خصائص التجميع. يبقى وصل الاكتشاف بذلك الرقم مسؤولية طريقة التنفيذ. وتضع المسودة الآن الحصول على القيمة الدقيقة خارج نطاقها؛ ويمكن للتنفيذ أن يستخدم التهيئة أو إجراءات اكتشاف خاصة به. هذا ليس حظراً لـLLDP أو LACP، بل رفض لمساواة غير مفحوصة بين تسميتين مختلفتين.

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

وتحذر الصياغة الجديدة من قراءة الفراغ على أنه نفي. غياب المعرّف البعيد يعني أن الرقم لم يُعرف أو لم يُعلن، لا أن الجار بلا عضو مقابل؛ وقد يظهر ذلك عندما يدعم طرف واحد الامتداد. في قائمة IS-IS المرتبة، يمكن استعمال الصفر موضعاً لقيمة مجهولة، لكنه لا يتحول إلى معرّف بعيد صحيح عند التصدير عبر BGP-LS. ولا يتولى ناقل BGP-LS التحقق من معنى العلاقة؛ يفحصها النظام المستهلك ويقرر كيفية التعامل مع التعارض. الحفاظ على حالة «مجهول» ضروري أثناء النشر التدريجي.

يسجل Datatracker النسخة 07 مسودة Internet-Draft نشطة في مرحلة IESG Last Call حتى 13 أكتوبر، بهدف الوصول إلى Proposed Standard. وهي ليست RFC معتمدة بعد وقد تتغير. وكان اشتراط تفعيل الإعلان على روابط محددة، لا تفعيله افتراضياً، موجوداً في النسخة السابقة. الحدث الجديد هو تشديد الدليل اللازم وراء المعرّف الذي سيعتمد عليه المتحكم.

المصادر