Subject: Re: OSPF MIB support for multiple OSPF processes

From: Tom Petch <[email-masked]>
Date: Thu, 23 Jan 2003 18:39:09 -0000

Roy

While I defer to Acee's expertise in OSPF, I may not necessarily do so
with SNMP; I think that the SNMPv3 idea of context was created for
just
the situation you describe.  A context, as discussed in RFC 3411 with
its place in the PDU defined in RFC 3412, is an integral
part of an SNMPv3 PDU.  A simple 'agent' will just have the one,
more sophisticated ones can have as many as they like, each
identified by a name,  so if you have multiple processes or objects of
any kind where the MIB branch only allows one instance, then contexts
is the technology that supports this.  And there is no need to
replicate any more of the MIB and associated structures than you need
to, no need to have complete, multiple virtual routers.

Also in SNMP, once a name has been registered, it cannot be
substantially
changed so if you want a table to replace a scalar, then you must
create new names, new objects, for everything in the table; the old
names may continue to be used for the existing scalar objects or
may be deprecated but they cannot change meaning.

Views, which you mention, are also a defined concept of SNMPv3
associated with access control, who can see which subset of the
available objects; I do not see that as being appopriate here.

I f you want an opinion on SNMP issues from a greater level of
expertise, then there
is a mailing list for just this purpose, namely
[email-masked]

Tom Petch
[email-masked]

-----Original Message-----
From: Roy Jose <[email-masked]>
To: [email-masked] <[email-masked]>
Date: 21 January 2003 17:08
Subject: Re: OSPF MIB support for multiple OSPF processes

>Hi Acee,
>
>> Roy, Tom,
>>
>> Using a separate community per instance works quite naturally if
>> you have a virtual router model where each virtual router has
>> its own SNMP configuration, RIB, and routing protocol instances.
Our
>> product uses this technique. However, within a virtual router (we
call
>> them contexts) one still has the problem when multiple routing
protocol
>> instances and RIBs are supported. The problem isn't unique to OSPF
so
>> I don't think an OSPFv2 specific solution is appropriate. I don't
think
>> making everything a table and adding instance ID as a table index
is
>> desirable.
>
>I am not able to think any other solution than going for this table
option.
>I think adding an extra index to an existing table won't be a big
issue.
>Only major change I can fprsee is the conversion of ospfGeneralGroup
to a
>table.
>
>Thanks,
>Roy
>
>>
>> Roy Jose wrote:
>> > Hi Tom,
>> >
>> > Thanks.
>> >
>> >
>> >>Yes.
>> >>In SNMPv1, this can be done by having multiple 'agents'
identified by
>> >>different community names or different IP addresses, each
accessing a
>> >>distinct incarnation of MIB II and its subordinate branches.
>> >
>> >
>> > Say OSPF process 2 is mapped to a MIB view V1. How does the NMS
know the
>> > details it collects through SNMP GET/GETNEXT are meant for
process 2?
>> >
>> > I doubt if this MIB view concept is based on MIB object id's,
meaning we
>may
>> > not be able to have separate MIB views for each OSPF processes
since we
>> > can't map them to any object id's.
>> >
>> > Thanks,
>> > Roy
>> >
>> >
>> >>In SNMPv3, there is a more sophisticated mechanism of contexts
which
>> >>formalises the techniques given above.
>> >>I do not think you should ever return more than one instance of a
>> >>given object in GET or GETNEXT.
>> >>
>> >>Tom Petch
>> >>[email-masked]
>> >>
>> >>-----Original Message-----
>> >>From: Roy Jose <[email-masked]>
>> >>To: [email-masked] <[email-masked]>
>> >>Date: 20 January 2003 16:04
>> >>Subject: OSPF MIB support for multiple OSPF processes
>> >>
>> >>
>> >>
>> >>>Hi,
>> >>>
>> >>>Rfc1850 doesn't talk about what to be done regarding the
>> >>
>> >>retrieval(GET) of
>> >>
>> >>>MIB values when multiple OSPF processes exist on a router. Out
first
>> >>>impression is to return details about all the processes. The
problem
>> >>
>> >>is
>> >>
>> >>>while selecting values for MIB objects like
>> >>>ospfRouterId,ospfAreaBdrRtrStatus, ospfASBdrRtrStatus etc. They
may
>> >>
>> >>differ
>> >>
>> >>>in separate processes. The Qn is, can we really support multiple
>> >>
>> >>processes
>> >>
>> >>>with rfc1850?
>> >>>
>> >>>Thanks,
>> >>>Roy
>> >>
>> >
>>
>>
>> --
>> Acee
>>

---

From: Roy Jose <[email-masked]>
Date: Tue, 28 Jan 2003 04:42:27 +0530

Hi Tom,

Thanks very much for your suggestion. Let me do more investigations on this
and get back to you.

Roy