الخلاصة

  • يفصل RFC 9736 بين مساحتي TLV لـPeer Up وInitiation، ويلزم بالحفاظ على ترتيب String TLV المتكرر. إنه يحسم ملكية الأكواد ولا يشهد لسلوك التنفيذ المنشور.
  • يحتاج الحكم التشغيلي إلى سلسلة إيصالات تبدأ بإصدار السجل والمرسل، ثم البايتات والمحلل والتخزين، وتنتهي بإثبات الجلسة والمسار والتمرير والأثر بعد الإجراء.

سياقان لا ينبغي أن يملكا دفتر أرقام واحداً

تصف Initiation النظام الخاضع للمراقبة، بينما تصف Peer Up جلسة BGP. ومع ذلك جعل RFC 7854 الرسالتين تتشاركان namespace واحداً لـInformation TLV. ومع توسع BMP صار رقم النوع بلا مالك واضح ما لم يُقرأ سياق الرسالة المحيطة.

يقسم RFC 9736 الدفتر. أصبح اسم السجل القديم BMP Initiation Information TLVs، وأُنشئ BMP Peer Up Message TLVs. في Initiation بقي String من Type 0 وsysDescr من Type 1 وsysName من Type 2. وفي Peer Up يوجد String من Type 0 وVRF/Table Name من Type 3 وAdmin Label من Type 4. وتُحجز الأرقام غير المناسبة في كل جانب.

ويحدد النص صيغة دقيقة: String سلسلة UTF-8 ينهيها عدد البايتات في Length، لا محرف null. حقل Information في Peer Up اختياري، ويظهر وجوده من Message Length في الترويسة العامة. ويمكن تكرار String، وعلى المستلم حفظ ترتيب القيم عند الإبلاغ عنها. قاعدة بيانات تحتفظ بآخر قيمة فقط تكون قد غيّرت الدليل حتى لو بدت الشاشة سليمة.

التوافق المعياري ليس شهادة إصدار

يقول RFC 9736 إن التطبيقات المتوافقة مع RFC 7854 و8671 و9069 متوافقة معه أيضاً. المقصود هو نقل التخصيصات القائمة إلى السجل الجديد بلا تغيير في معناها على السلك. لا يحدد النص منتجاً أو إصداراً أو pipeline بعينه.

قد يتعرف جامع على Type 0 ثم يسقط كل القيم عدا الأخيرة. وقد يعرض Type 3 باسم جدول صحيح لكنه يربطه بـLoc-RIB peer افتراضي خاطئ. وقد يتجاهل نوعاً مستقبلياً مجهولاً بصمت. يبقى سجل IANA صحيحاً بينما تصبح الذاكرة التشغيلية ناقصة.

لذلك يبدأ الإيصال قبل فك الترميز. ينبغي حفظ بايتات Peer Up، وهوية جلسة BMP، وإصدار المرسل وإعداده، وMessage Length، وتسلسل TLV. ثم تُربط اللقطة بإصدار الجامع وparser schema وسياسة الأنواع المجهولة. وبعد ذلك تُقارن raw ingest بالعنصر المفكوك والسجل الدائم. من دون الأصل لا يمكن معرفة هل غاب الحقل عن السلك أم ضاع داخل المنصة.

ما لا تغلقه Peer Up

يعرّف RFC 7854 Peer Up كتقرير عن انتقال جلسة BGP مراقبة إلى Established، ويحمل رسالتي OPEN ومعلومات TCP. لكنه يُرسل أيضاً للـpeers الموجودين أصلاً في Established عند بدء جلسة BMP. لذلك لا يساوي وقت وصوله بالضرورة وقت قيام جلسة BGP.

ويفصل RFC 8671 حالة Peer Up/Down عن إرسال Route Monitoring أو Route Mirroring لـAdj-RIB-In أو Adj-RIB-Out. فـInitiation وPeer Up والـRIB dump الأولي وEnd-of-RIB والتحديثات اللاحقة إيصالات مختلفة. لا تثبت رسالة واحدة اكتمال feed.

وفي RFC 9069 تمثل Loc-RIB بواسطة peers افتراضيين، وقد يوجد أكثر من peer للجدول بحسب address family. يساعد VRF/Table Name لكنه لا يمنح هوية عالمية؛ يجب مطابقة peer distinguisher وBGP ID وOPEN capabilities أيضاً.

سلسلة الإثبات المطلوبة للقرار

ينبغي أن يسجل الملف التشغيلي: snapshot السجل، وإصدار المرسل، وجلسة BMP وpeer epoch، والبايتات، وإصدار المحلل، وسياسة المجهول، وإيصال raw وdecoded، وتأكيد الجلسة، وتغطية المسارات، ومشاهدة RIB/FIB أو probe، والإجراء المصرح به، والنتيجة المستقلة.

يجوز أن تنتهي السلسلة بعبارة «غير معلوم». تثبت Peer Up تقرير جلسة ولا تثبت قبول route. وقد يثبت feed كامل الرؤية ولا يثبت hardware forwarding. وقد يثبت التمرير ولا يثبت الأثر التجاري. يقوي RFC 9736 بداية السلسلة؛ ولا يصح تحويل ذلك إلى حكم على نهايتها.