غياب سمة OTC لا يثبت خلو المسار من التسريب

الخلاصة

• تجمع RFC 9234 بين BGP Role ومعالجة OTC؛ فالسمة ليست حكماً مستقلاً عن السياق.
• يضيف المستقبِل المتوافق OTC إلى مسار غير موسوم يأتي من Provider أو Peer أو Route Server.
• أثناء النشر التدريجي قد يبقى Role إعداداً محلياً فقط، ولا تنطبق الإجراءات المعتادة على العلاقات المعقدة.
• يجب فصل حالات مرصود، ودور مؤكد، وOTC مضاف، ومؤهل محلياً، وخالٍ من التسريب عبر المسار.

لنتخيل لوحة مراقبة تتحول إلى اللون الأخضر كلما خلا تحديث من OTC. يصل مسار من مزود عبور بلا السمة، فتصفه اللوحة بأنه خالٍ من التسريب. لكن الالتقاط تم قبل معالجة الدخول. وفي هذه النقطة تحديداً تلزم RFC 9234 الراوتر المستقبِل بإضافة OTC برقم AS للطرف البعيد عندما يصل المسار غير الموسوم من Provider أو Peer أو Route Server.

لم يفشل البروتوكول. الذي فشل هو نموذج الدليل، إذ حوّل لقطة قبل المعالجة إلى حكم على المسار كله.

تعرف RFC 7908 تسريب المسار بأنه انتشار الإعلان خارج نطاقه المقصود. ويتحدد هذا النطاق عادة بسياسات تصدير وترشيح موزعة، غالباً وفق علاقات Provider وCustomer وPeer. وتصنيفها إطار عمل عملي لا قائمة شاملة بكل أشكال التسريب الممكنة. تحمل OTC دليلاً مهماً عن المصدر، لكن غيابها في موضع واحد لا يعيد بناء النطاق المقصود أو كل المعالجات السابقة أو الجيران الذين استلموا المسار فعلاً.

OTC سمة مسار اختيارية عابرة، رمز نوعها 35 وقيمتها أربعة بايتات. وغرضها محدد: بعد إرسال مسار إلى Customer أو Peer أو Route Server Client لا ينبغي أن يذهب لاحقاً إلا إلى Customers. وعلى المرسل أن يضيف OTC إذا أعلن مساراً غير موسوم إلى أي واحد من هذه الأنواع الثلاثة من الجيران. والمسار الذي يحمل OTC ويصل من Customer أو Route Server Client هو تسريب، وتنص RFC 9234 على وجوب استبعاده من عملية اختيار المسار. وإذا جاء من Peer فهو تسريب أيضاً عندما لا يساوي رقم AS في السمة رقم AS لذلك النظير. ولا يجوز نشر مسار يحمل OTC إلى Providers أو Peers أو Route Servers، ويجب الحفاظ على قيمته من دون تغيير بعد ضبطه.

تكون هذه القواعد حاسمة لأن Role والاتجاه ومرحلة المعالجة معروفة، لا لأن غياب أربعة بايتات يعني الأمان.