الخلاصة

  • يحدد RFC 10005 مجتمعاً موسعاً في BGP يحمل قيمة عائمة من أربعة أوكتت بوحدة البايت في الثانية، لكنه لا يحدد طريقة اشتقاقها ولا خوارزمية توزيع الحركة بالأوزان.
  • تخضع القيمة الصفرية والغياب والنسخ المتعددة والانتقالية وتغيير next hop لافتراضات التنفيذ والسياسة المحلية؛ لذلك لا يثبت الحقل الصحيح سعة متاحة أو أوزاناً مثبّتة أو إنتاجية فعلية.
  • يرد Pradosh Mohapatra واحداً من ستة مؤلفين. يضبط العمل الجماعي حاملاً محدود الوظيفة، بينما يحتاج التشغيل إلى وصل المنشأ والتحويل وسياسة المستقبل وحالة FIB بنتيجة الحركة.

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

ينبّه RFC 10005 إلى أن معلومات Link Bandwidth قد تكون حساسة، ويوصي بالترشيح حين تغادر المسارات مجالاً إدارياً أو تتجه إلى شبكة غير موثوقة. لا يكفي وجود قاعدة في ملف إعداد. المطلوب إثبات أنها طبقت على المسار والقيمة والحد المعني، مع تسجيل الاستثناءات.

صدر RFC 10005 في مسار معايير IETF في يونيو 2026. يوقعه Pradosh Mohapatra وReshma Das وSatya Mohanty وSerge Krier وRafal Jan Szarecki وAkshay Gattani. يوحّد المستند صيغة BGP Link Bandwidth Extended Community وقواعد معالجتها، لكنه يرفض منح أربعة أوكتت معنى لم يضعه المرسل فيها.

الوحدة معلومة، أما ماهية الرقم فليست كذلك

للمجتمع شكل انتقالي من النوع 0x00 وآخر غير انتقالي من النوع 0x40، وكلاهما يستخدم النوع الفرعي 0x04. يأتي Global Administrator في أوكتتين، ثم Local Administrator في أربعة أوكتت بقيمة IEEE 754 أحادية الدقة، مقيسة بالبايت في الثانية.

هذه ليست بتات في الثانية. حين تعرض واجهة Gbit/s تكون قد ضربت في ثمانية وغيرت المقياس وربما قربت الرقم. يجب أن يحتفظ السجل بالأوكتت الأصلية والقيمة المفكوكة والوحدة والتحويل، وإلا تعذر وصل ما في الشاشة بما وصل عبر BGP.

لكن الدقة الشكلية لا تجيب: ما هذا الرقم؟ قد يكون معدل واجهة، أو مجموع مسارات بعيدة، أو قيمة مضبوطة يدوياً، أو قياساً، أو وزناً مشتقاً من عدد الخوادم، أو إشارة صيانة. يترك RFC 10005 حساب القيمة أو تحديدها خارج النطاق.

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

يعرض draft-ietf-bess-ebgp-dmz-10 الصادر في أبريل 2026 أمثلة على هذه الفروق، لكنه Internet-Draft قيد العمل وليس RFC نهائياً. إذا استقبل الموجه 70 Gbit/s بينما لا يصل إلى next hop إلا عبر 50 Gbit/s محلية، يمكن لدالة محلية أن تحد المساهمة عند 50. المثال مفيد للمراقبة ولا يضيف ضماناً معيارياً إلى RFC 10005.

حقل Global Administrator ليس توقيعاً

ينبغي أن يضع الموجه الذي يرفق المجتمع رقم ASN في حقل Global Administrator، إلا أن الحقل يقبل أي قيمة من أوكتتين. وإذا كان ASN من أربعة أوكتت، يستخدم AS_TRANS. ولا يؤثر الحقل في استعمال المجتمع أو دلالته.

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

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

تغيير next hop ينقل المسؤولية

عندما يعيد متحدث BGP إعلان مسار ويغير next hop، يسمح RFC 10005 بإزالة المجتمع أو إبقائه أو إعادة توليده. ينبغي للتنفيذ إظهار السلوك الافتراضي والسماح بتجاوزه لكل جلسة. وإذا لم يتغير next hop، فلا ينبغي تعديل المجتمع.

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

لا تسجل الأوكتت النهائية أي فعل من هذه الأفعال. لذا يجب حفظ next hop قبل وبعد، وقيمة الدخل، والفعل، ومدخلات الدالة المحلية، وإصدار السياسة، والخرج، والوقت، وصاحب القرار.

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

الصفر والغياب حالتان مختلفتان

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

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

جمع zero وmissing وinvalid وstale تحت كلمة «مجهول» يلغي القدرة على العمل. الصفر قد يكون طلب drain، والغياب قد يعني عدم دعم، والقيمة السالبة قد تكشف خللاً، والقدم قد ينتج من آلية خفض churn.

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

الوزن المقصود لا يساوي ما نفذه العتاد

عندما تحمل كل المسارات المشاركة قيمة موجبة، يمكن استخدام القيم أو نسبها كأوزان. تبقى الخوارزمية خارج نطاق RFC، وينبغي ألا تدخل القيمة في BGP best-path selection. يأتي الوزن بعد تحديد مجموعة المسارات المؤهلة.

قد يحسب المستقبل نسبة 1:2، بينما يقربها FIB ضمن عدد محدود من buckets. وقد يحافظ العتاد على التدفقات القائمة بسبب resilient hashing. وتستطيع تدفقات قليلة كبيرة أن تجعل نسبة البايتات مختلفة عن نسبة الأعضاء رغم صحة البرمجة.

لهذا توجد أربعة إيصالات: المجتمعات المقبولة، الأوزان المحسوبة، الأوزان المثبتة في FIB، وحركة المرور المرصودة لكل مسار. لا يحل أمر show محل إقرار العتاد، ولا يحل إقرار العتاد محل العدادات.

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

ضبط churn يصنع ساعة ثانية

يمكن للتغير السريع في القيم أن يؤثر في استقرار البروتوكول والعمليات. لذلك يوصي RFC بآليات تحد churn. تفيد الحدود والمؤقتات، لكنها تفصل وقت الرصد عن وقت الإعلان.

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

عند انتهاء الصلاحية، يجب أن تكون القاعدة صريحة: تقسيم متساوٍ، أو عزل، أو استخدام آخر قيمة مع تحذير، أو سحب. لا يجوز أن تبقي آلية الاستقرار دليلاً قديماً متحكماً في FIB بلا مالك.

ما الذي تثبته مساهمة Pradosh Mohapatra

يسجل RFC 10005 انتماء Pradosh Mohapatra إلى Google LLC ويذكره مع خمسة مؤلفين آخرين. وفي حفظ 1 سبتمبر 2026، كان ملف Datatracker الرسمي المرتبط بالعمل يسرد إحدى عشرة RFC لكنه يعرض التهجئة القديمة «Prodosh Mohapatra». تستخدم RFC وصفحة ipSpace العامة «Pradosh Mohapatra»، وهي الهوية المعيارية هنا.

تصف سيرة ipSpace المؤرخة أدواراً سابقة في برمجيات التوجيه لدى Cumulus Networks وCisco. وهي سياق للهوية، لا دليل على دور حالي يتجاوز انتماء RFC، ولا على السيطرة على إجماع IETF أو على نتيجة تشغيلية مسماة.

لا ينبغي لمقال عن شخص أن يحول عملاً لستة مؤلفين إلى بطولة فردية. أهمية Mohapatra هنا أن مساهمته القابلة للتحقق تساعد على رؤية الحد: الحامل موحد، لكن معنى القيمة وقرار استعمالها ونتيجتها تبقى مسؤوليات منفصلة.

بناء إيصال يحفظ القيمة وقرارها ونتيجتها

ابدأ بالمسار وعائلة العنوان والجار والمجال والنوع وGlobal Administrator والأوكتت والقيمة بالبايت في الثانية والتحويل. صِل بذلك المعنى والمصدر والمنهج والوقت والصلاحية والمالك.

عند كل تغيير next hop، احفظ remove أوretain أوregenerate مع الدخل والخرج. وعند التجميع، احفظ المكونات والصيغة ومعالجة الصفر والغياب والقيم غير الصالحة. ثم صِل سياسة المستقبل والنسبة المحسوبة وFIB وإقرار العتاد.

اختم بالبايتات والفقد والتأخير والصفوف والإنذارات والقرار والرجوع والتنظيف. عندئذ يبقى المجتمع مدخلاً صغيراً ومفيداً للتوجيه، وتبقى «السعة المتاحة» استنتاجاً مستقلاً لا يُقبل إلا بعد اتفاق الأدلة.

المصادر