الخلاصة

  • النص الحالي draft-xu-idr-fare-in-mpson-01 مؤرخ في 16 أغسطس 2026، ويوسع فكرة ECMP الموزون بعرض النطاق في FARE-BGP لتشمل واجهات RoCE NIC ‏(RNIC) في شبكات scale-out متعددة المستويات.
  • يجمع التحدي التشغيلي بين اختيار RNIC لمستوى CLOS معزول وبين استحالة الاحتفاظ بحالة مسارات المضيف بلا حد في جميع المواضع.

تسمي بطاقة IETF Datatracker الوثيقة Fully Adaptive Routing Ethernet in Multi-Plane Scale-Out Networks. وهي Internet-Draft ذات نية Standards Track. هذه الصفة تقيد الاستنتاج: تصف IETF مسودات الإنترنت بأنها وثائق عمل يمكن تعديلها أو استبدالها أو انتهاء صلاحيتها، وليست قراراً معيارياً نهائياً.

يصف نص الإصدار -01 RNIC متصلة بشبكة CLOS مستقلة لكل مستوى. لا توجد وصلات بين المستويات، ولذلك تختار RNIC المستوى الذي يحمل كل تدفق أو حزمة. وتمتد FARE-BGP — أي ECMP الموزون الذي يعتمد Path Bandwidth Extended Community — من المحولات إلى هذه الواجهة. وتطلب المسودة جلسة BGP منفصلة بين RNIC وleaf switches في كل مستوى، تتعلم عبرها الواجهة قابلية الوصول البعيدة ومعلومة عرض النطاق اللازمة للاختيار الموزون.

هنا تنتقل سطحية التحكم. لم يعد السؤال مقتصراً على كيفية توزيع محولات الشبكة لحركة المرور بين المسارات المتساوية الكلفة. بل يصبح السؤال: هل القيم الواصلة إلى واجهة المضيف كاملة وقابلة للمقارنة، وهل تُسحب سريعاً حين يفقد مستوى ما قابلية الوصول؟ لا يثبت النص تحسناً في أداء عنقود ذكاء اصطناعي؛ بل يقترح آلية لتوضيح قرار تفرضه بنية المستويات المعزولة على الواجهة أصلاً.

والحجم هو القيد الثاني. يستخدم النص مثالاً توضيحياً فيه 100 ألف GPU وأربعة مستويات، ويمكن أن ينشر كل مستوى ما يصل إلى 100 ألف مسار مضيف. ويرى أن حفظ 400 ألف مسار في كل RNIC غير عملي، وأن الاحتفاظ بها كاملة في المحولات غير مناسب، فيقترح كبت جداول التوجيه. لكن التجميع قد يبقى بعد أن تصبح RNIC البعيدة غير قابلة للوصول عبر مستوى ما. ولتفادي الثقب الأسود، يقترن التجميع بإعلان صريح عن مضيف غير قابل للوصول؛ ومن الخيارات جعل قيمة Path Bandwidth صفراً. هذا تصميم مقترح، لا دليل تشغيل أو توافق بين منتجات.