[j-nsp] BGP4-MIB-v2

[Jeff Haas]

> On Mar 27, 2017, at 12:43 PM, Vincent Bernat <bernat at luffy.cx> wrote:
>>> So, 192.0.2.47 should be encoded to 4.192.0.2.47.
>> 
>> Probably no.
>> 
>> The headache here is that the underlying type is RFC 4001's
>> InetAddress.  As you can see in the documentation in that RFC the
>> expectation is that the InetAddressType is used to 'cast' the
>> InetAddress to one of the underlying types; e.g. InetAddressIPv4.
>> Let's pick on that example:
>> 
>> InetAddressIPv4 ::= TEXTUAL-CONVENTION
>>    DISPLAY-HINT "1d.1d.1d.1d"
>>    STATUS       current
>>    DESCRIPTION
>>        "Represents an IPv4 network address:
>> 
>>           Octets   Contents         Encoding
>>            1-4     IPv4 address     network-byte order
>> 
>>         The corresponding InetAddressType value is ipv4(1).
>> 
>>         This textual convention SHOULD NOT be used directly in object
>>         definitions, as it restricts addresses to a specific format.
>>         However, if it is used, it MAY be used either on its own or in
>>         conjunction with InetAddressType, as a pair."
>>    SYNTAX       OCTET STRING (SIZE (4))
> 
>> So, while you're correct with regard to variable types, the
>> expectation is that this is "cast" into a fixed sized octet string,
>> which has implied length.
> 
> I didn't know about RFC 4001 so I may be mistaken, but it doesn't say
> anything about the size requirement. Other than the comments in the MIB,
> there is also no way to link InetAddress and InetAddressIPv4. This is
> not just a matter of being able to pretty-print the IPv4, it's that we
> cannot know how to split the index into its components.

I generally agree with your analysis.  We've fundamentally reached a "what did the authors of rfc 4001 have in mind".  The whole idea of using this union was sort of gross and while things were still in MIB-land as IETF's main way of doing management stuff, confused a lot of people.  So the question is whether it's variably sized, and if so, how to reconcile against the casting.  However...

> 
>> Given that net-snmp seems to recognize how to render the output from
>> the MIB, I suspect others came to a similar conclusion.
> 
> Net-SNMP is not able to render the output of the MIB correctly if the
> size is not specified. See, without the size:
> 
> $ snmptranslate -m BGP4-V2-MIB-JUNIPER iso.3.6.1.4.1.2636.5.1.1.2.2.1.1.5.8.1.10.64.0.3.1.10.64.0.1
> BGP4-V2-MIB-JUNIPER::jnxBgpM2PeerLastErrorReceivedText.8.ipv4.10.64.0.3.1.10.64.0.1
> 
> If I add the size:
> 
> $ snmptranslate -m BGP4-V2-MIB-JUNIPER iso.3.6.1.4.1.2636.5.1.1.2.2.1.1.5.8.1.4.10.64.0.3.1.4.10.64.0.1
> BGP4-V2-MIB-JUNIPER::jnxBgpM2PeerLastErrorReceivedText.8.ipv4."10.64.0.3".ipv4."10.64.0.1"

I know I've seen the bottom form of the output at some point. This makes me wonder if my memory is simply playing a trick on me, or it's what we do in one of our internal tool chains.

Again, get the answer of what you really expect vs. what's in the code.

To your relevant next point: If the junos mib is in error, what to do about it?

Very likely fixing the issue will cause mass amounts of unhappiness as people's existing scripts and mib walking code fails due to the new sub-indices.

do the right thing, create misery? Leave it as is, document that it's wrong?

Again, I hate SNMP. :-)

As mentioned, I'm conveniently at IETF.  At least one of the authors of 4001 attends, so I should see if he's here.

> 
> Other MIB implementations also using AddrType/Addr includes the size,
> for example (on JunOS 14.1):
> 
> $ snmpgetnext net-tor-0114-1 IP-MIB::ipAddressTable
> IP-MIB::ipAddressIfIndex.ipv4."10.64.0.3" = INTEGER: 567
> $ snmpgetnext -On net-tor-0114-1 IP-MIB::ipAddressTable
> .1.3.6.1.2.1.4.34.1.3.1.4.10.64.0.3 = INTEGER: 567

And this does support the idea that the code is wrong.

-- Jeff