الخلاصة

  • يعرّف RFC 9902 وحدة YANG ‏ietf-isis-sr-mpls لإدارة امتدادات IS-IS لـSR فوق مستوى بيانات MPLS، ويُبقي RFC 9902 ضمن مسار معايير IETF.
  • يوسّع نموذج IS-IS في RFC 9130، ويعتمد على نموذج SR الأساسي المستقل عن البروتوكول في RFC 9020؛ أما RFC 8667 وRFC 9855 فيقدمان سياق الامتدادات وآلية TI-LFA ذات الصلة.
  • لا يكفي ضبط enable إلى true: فهو يفعّل SR-MPLS في IS-IS ويبدأ الإعلان باستخدام المعلمات الموجودة في نموذج SR الأساسي، ولذلك يجب فحص تلك الموارد أولاً.

الفكرة التشغيلية هي فصل طبقات العقد. موارد SR العامة، ومنها نطاق SRGB وSRLB، ليست هي قرار إعلان امتدادات IS-IS. عند التفعيل تتصل هذه الطبقات، ويصبح من المهم مطابقة القدرات والخوارزميات ونطاقات الملصقات مع ما ستعلنه الجلسات وما سيظهر في حالة LSDB.

يقدم RFC 9902 إعدادات وحالة تشغيل لعلامات قدرة SR والخوارزميات، ومعلومات SRGB وSRLB، وتفضيل خادم SR Mapping Server، وPrefix-SID وAdj-SID، وTLV لربط SID/Label. هذه الرؤية لا تعني أن نموذج YANG ينفذ التحويل، أو يحسب المسارات، أو يخصص الملصقات؛ إنه يصف سطح الإدارة والحالة التي ينبغي قراءتها والتحقق منها.

الإعلان والاستقبال ليسا مفتاحاً واحداً

لا يعلن IS-IS إدخالات Mapping Server ولا يعالجها افتراضياً. يحدد bindings/advertise/policies السياسات التي سيعلنها الجهاز، بينما يتحكم bindings/receive في استقبال الإدخالات ومعالجتها. لذلك فسياسة الإرسال قرار ثقة مختلف عن سياسة الاستقبال، ولا يصح اختزالهما في حالة «مفعّل». السلوك الافتراضي لكليهما هو عدم الإعلان وعدم المعالجة، ما لم يضبط المشغل خلاف ذلك.

يمكن للنموذج أن يوسّع Fast Reroute على الواجهة لتمكين TI-LFA، كما يمكن لـRemote LFA استخدام مسار SR بدلاً من مسار LDP. لكن ti-lfa وremote-lfa-sr ميزتا اختياريتان، ولا يفرض RFC 9902 تفعيلهَما. ولا يعمل التحكم المرتبط بـSR-based Remote LFA إلا عند دعم الميزة وتمكين Remote LFA. وتشمل مفاضلات اختيار TI-LFA حماية العقد وعدم انفصال SRLG، ولكل منهما أولوية قابلة للضبط يكون فيها الرقم الأصغر أكثر تفضيلاً.

فحص المطابقة ومسار المشغل

قبل الكتابة عبر NETCONF أو RESTCONF، تحقّق من أن الجهاز يعلن القدرة المطلوبة، ومن خوارزميات SR، ونطاقي SRGB وSRLB، وPrefix-SID وAdj-SID، وربط SID/Label، وحالة LSDB. قارن هذه القراءة مع سياسة النشر المقصودة، وتأكد من أن كل تحكم خاص بميزة لا يُرسل إلا إذا كانت الميزة مدعومة. افحص كذلك سياسات Mapping Server بصورة منفصلة: ما الذي سيُعلن؟ وما الذي سيُقبل ويُعالج؟

نفّذ التغيير على مراحل: اقرأ الحالة، سجّلها، طبّق موارد SR الأساسية والسياسات، ثم فعّل enable بعد مراجعة جماعية. راقب القدرات، الإعلانات، LSDB، وSRGB/SRLB وSID بعد الكتابة. إذا اختلفت الحالة عن النتيجة المقبولة، فأعد السياسات والموارد إلى اللقطة الموثقة، وأوقف الإعلان أو الاستقبال وفقاً لخطة التراجع، ثم عطّل التفعيل. عتبات التراجع الصحيحة تخص المشغل ولا يحددها RFC 9902.

هذا تحليل Theo March، وليس حكماً معيارياً: التحقق من المتحكم، واكتشاف الانحراف، والنشر المرحلي، وفصل أدوار التفويض، واختبار التراجع تجعل العقد التشغيلي قابلاً للمراجعة، لكنها لا تجعل الإعداد غير الآمن آمناً ولا تضمن التوافق أو السلامة أو التشغيل بلا توقف. كما أن تغطية المنتجات والمتحكمات الحالية، والأداء، والتبني، وحجم جهد الانتقال، وأي حوادث، أمور غير معلومة هنا.

الأمن ليس هامشاً

يجب أن يستخدم الوصول إلى الوحدة عبر NETCONF أو RESTCONF نقلاً آمناً ومصادقة متبادلة، مع استخدام NACM لتقييد المستخدمين بالعمليات والمحتوى المسموحين. تغيير غير مصرح به في SR أو روابط Mapping Server أو TI-LFA قد يسقط المرور أو يوجهه خطأ أو ينشئ حجب خدمة. وفي الاتجاه الآخر، قد يكشف وصول القراءة القدرات والخوارزميات وSRGB وSRLB وتفضيل Mapping Server وحالة LSDB؛ لذلك لا ينبغي اعتبار الحالة المقروءة غير حساسة.

المصادر