Re: [Idr] draft-haas-idr-bfd-subcode-00.txt

[Jeffrey Haas <[e-mail]>]

Dale,


> On Jan 7, 2022, at 1:57 PM, Dale W. Carder <[e-mail]> wrote:
> If a speaker is using this codepoint, it should use it consistently.
> Ideally, I think the notification to the peer and what it reports to 
> the management systems should match?  That would help with the head 
> scratching.  Should that paragraph be edited such as
> 
>   Even so, BGP implementations SHOULD provide this reason as part
>   of their operational state; e.g. bgpPeerLastError in the BGP MIB

I think that's a good change, and I've incorporated it.

I'm hesitant to make this a MUST because of a level of ambiguity about when such state is set in implementations.  One valid interpretation is that this data is only set for received notifications rather than sent for RFC 4273.  Elsewhere, direction is specified.

The BGP MIBv2 work that was never completed in IDR, but which served as the basis for a number of vendor enterprise MIBs, distinguishes between the sent and received errors - along with providing access to the DATA.

https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp4-mibv2-15 <https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp4-mibv2-15>

See Bgp4V2PeerErrorsEntry

For comparison, see https://www.juniper.net/documentation/software/topics/concept/mib-jnx-bgpmib2.txt <https://www.juniper.net/documentation/software/topics/concept/mib-jnx-bgpmib2.txt>, jnxBgpM2PeerLastErrorSent.

And similar for openconfig:
https://github.com/openconfig/public/blob/master/release/models/bgp/openconfig-bgp-neighbor.yang <https://github.com/openconfig/public/blob/master/release/models/bgp/openconfig-bgp-neighbor.yang> - last-notification-error-code/subcode.


-- Jeff