Re: [Lsr] [Idr] [GROW] IGP Monitoring Protocol

[Jeffrey Haas <[e-mail]>]

Tianran,

On Jul 11, 2022, at 10:42 PM, Tianran Zhou <zhoutianran=[e-mail]> wrote:
> 
> Hi Jeff,
>  
> Our work is not to propose a new protocol.
> https://datatracker.ietf.org/doc/html/draft-gu-opsawg-network-monitoring-igp-01 <https://datatracker.ietf.org/doc/html/draft-gu-opsawg-network-monitoring-igp-01>
> Our idea is to use BMP for IGP monitoring. We just choose BMP as the vehicle.

Thanks for the pointer to this document.  I had not previously read it.

The use case portion of the document is clear and well-written.

I don't pretend to be an expert in any of the IGPs, but here are a few observations from my read-through of the document:

- Should the per-adjacency header include something like ifIndex as part of its information?  This might help with troubleshooting misconfigured interfaces.
- In places where fields are Reserved, please use text in the form of "MUST be set to zero on transmission and SHOULD be ignored on reception".
- Your reason type and statistics type fields should get IANA sections and IANA allocation policy for allocating future code points.
- Your statistics TLV could probably be patterned more like that of the main BMP RFC.  That would permit more than one statistic to be attached at a time.
   + Statistic Value says that it is always 4 bytes of length.  If it's a fixed length, you may not require a length.  But I think you'll want this to be variably sized.  Some fields should be a 64-bit gauge; see BMP RFC for examples.
- The document should procedurally describe what happens when a session is first established.  For BGP BMP, the full RIB set is exchanged.  For this proposal, very likely the intent is that the LSDB is transmitted.  Given the incremental nature of IS-IS messages, it may be necessary to describe similar "end of rib" procedures that are in the BGP BMP specification in the context of your draft.  Afterwards, propagating the raw IS-IS PDUs in your messages will likely make sense.

-- Jeff