[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [sip] I-D ACTION:draft-ietf-sip-mib-08, changes since draft07
> The ifIndex is probably not the right index. In considering this more, I
> actually think that a more appropriate index would be an
> "application-instance" index (e.g. the n'th instance of the sip_proxy
> application). Each instance could represent a domain or interface. This
> would be a secondary index to the SipPort table and the various stats
> tables. It would be 1 when there was only a single instance of the
> application running. We might need an application instance table to give
> each one a name/description.
Without knowing the details, the above proposal seems reasonable apart
from one thing, and that is, my guess is that an "application-instance
index" would be better as the first object in an INDEX clause. By
analogy, here's a quote from draft-ietf-ips-fcmgmt-mib-05.txt:
This MIB contains the notion of a Fibre Channel management instance,
which is defined as a separable managed instance of Fibre Channel
functionality. Fibre Channel functionality may be grouped into Fibre
Channel management instances in whatever way is most convenient for the
implementation(s). For example, one such grouping accommodates a single
SNMP agent having multiple AgentX [RFC2741] sub-agents, with each sub-
agent implementing a different Fibre Channel management instance. In
order to represent such multiple Fibre Channel management instances
within the same SNMP context (see section 3.3.1 of [RFC3411]), all
tables in this MIB are INDEX-ed by fcmInstanceIndex which is defined as
an arbitrary integer to uniquely identify a particular Fibre Channel
management instance.
Note that for the AgentX scenario, the idea is for fcmInstanceIndex to
be the first object in INDEX clauses so that it can be used by an SNMP
agent to de-multiplex the varbinds and thereby know which AgentX
sub-agent to forward them to.
Keith.
> cheers,
> (-:bob
>
> Robert F. Penfield
> Chief Software Architect
> Acme Packet, Inc.
> 130 New Boston Street
> Woburn, MA 01801
> bpenfield at acmepacket.com
>
> ----- Original Message -----
> From: "Kevin Lingle" <klingle at cisco.com>
> To: "Bob Penfield" <bpenfield at acmepacket.com>
> Cc: <sip at ietf.org>; "Jean-Francois Mule" <jf.mule at cablelabs.com>; "Keith
> McCloghrie" <kzm at cisco.com>
> Sent: Thursday, August 05, 2004 5:52 PM
> Subject: Re: [sip] I-D ACTION:draft-ietf-sip-mib-08, changes since draft07
>
>
> > hi bob.
> >
> > thanks for the feedback. exchanged some messages with jean-francios
> > and we aren't able to sync up our schedules till late next week to
> > consider your comments.
> >
> > some initial thoughts/comments/considerations inline below...
> >
> > Bob Penfield wrote:
> > > Items #5 and #80 from your response (excerpted below) got me thinking
> about
> > > what an application is in SNMP terms and how it relates to multiple SIP
> > > application instances of the same type. If I want to have separate stats
> > > tables for each interface (SipPort), then each one would need to have a
> > > different applIndex, and thus would have a separate entry in the
> applTable.
> > > However, given the restrictions on the applName string, these would all
> have
> > > the same applName. Is that legal? RFC 2788 seems to imply that it is
> not. If
> > > so, should there be some text indicating that it is? or does there need
> to
> > > be a suffix in the applName to disambiguate them?
> > >
> > > Our customers are asking for SIP Statistics on a per interface (or per
> > > domain) basis and we would like to use the SIP MIB.
> >
> > <klingle>
> > is the notion of SipPort truely synonymous to ifIndex? or are we
> > talking more of a conceptual "interface" to a sip entity that
> > may not necessarily tied to a ifIndex?
> >
> > when initially looking at the use of applIndex vs. ifIndex
> > (per the reference to H.341 below) i consulted with
> > Keith McCloghrie about the use of ifIndex by ITU for H.341.
> > his responses resulted in a change in those mibs and, ultimately,
> > the use of applIndex for SIP MIB modules as well.
> >
> > i'm not certain, but i suspect that the introduction of ifIndex
> > again, even as a secondary index to some tables in the SIP MIB modules
> > may still conflict with the assertions that keith made why
> > it was inappropriate as the primary index.
> >
> > i've cc'd keith to any comments he might have. below are some
> > excerpts of keith's orginal arguements way back when...
> > (note some references to things of H.323... SIP entities should
> > be interchangable for those terms for this discussion)
> >
> > ---- From kzm at cisco.com, 12/7/1999 --------------
> > The ifTable is defined as for use by interface sub-layers beneath
> > the internetwork-layer. For example, it would not be appropriate
> > to represent the interface between TCP and IP by a row in the
> > ifTable, nor the interface between any application and the
> > transport protocol (TCP/UDP) it uses. Doesn't a Gatekeeper sit
> > in the protocol stack above a transport protocol ?
> > Another way to think of this is to ask the question: how would
> > you represent this ifEntry in the ifStackTable ?
> >
> > Keith.
> > ---------------------------------------------------
> >
> > subsequently, in the same thread....
> >
> > ----- From kzm at cisco.com, 4/30/2000 ---------------
> > In case it is not plain enough from my email that is quoted, RFC 2233
> says:
> >
> > This memo discusses the 'interfaces' group of MIB-II, especially the
> > experience gained from the definition of numerous media- specific MIB
> > modules for use in conjunction with the 'interfaces' group for
> > managing various sub-layers beneath the internetwork- layer.
> >
> > and
> >
> > One of the strengths of internetwork-layer protocols such as IP
> > [6] is that they are designed to run over any network interface.
> > In achieving this, IP considers any and all protocols it runs over
> > as a single "network interface" layer. A similar view is taken by
> > other internetwork-layer protocols. This concept is represented
> > in MIB-II by the 'interfaces' group which defines a generic set of
> > managed objects such that any network interface can be managed in
> > an interface-independent manner through these managed objects.
> >
> > Thus, ifIndex values are for network interfaces (and their sub-layers)
> > beneath the internetworking layer. It is wrong to assign an ifIndex
> > value to any application which runs on top of TCP or UCP. I believe
> > H323 is in this category.
> >
> > Regarding IANA's assignment of ifType values for h323Gatekeeper and
> > h323Proxy, IANA's tendency has been to assign values whenever asked
> > without questioning the validity. I'll see if there's something I
> > can do about that.
> >
> > Keith.
> > --------------------------------------------------
> >
> > those exchanges are the basis for our use of applIndex.
> > the question now seems to be whether it would be
> > inappropriate to consider using ifIndex in addition
> > to applIndex to uniquely identify instances of objects
> > in certain tables. in other words, in the context of
> > an application, is it ok to maintain per IfIndex
> > objects like stats.
> >
> > keith, do you have any thoughts on that?
> >
> > more comments below...
> > </klingle>
> >
> >
> > >
> > >
> > > cheers,
> > > (-:bob
> > >
> > > Robert F. Penfield
> > > Chief Software Architect
> > > Acme Packet, Inc.
> > > 130 New Boston Street
> > > Woburn, MA 01801
> > > bpenfield at acmepacket.com
> > >
> > > ----- Original Message -----
> > > From: "Jean-Francois Mule" <jf.mule at cablelabs.com>
> > > <snip>
> > > ------------------------------------------------------
> > > 5) Many proxies can control more than one domain at the same time.
> > > Need to support this.
> > >
> > > AI: none
> > > # Kevin and Cullen exchanged some emails on this topic:
> > > # klingle: how might this manifiest itself in the mib? additional
> > > # indexing of the tables for domain? what info about each domain
> > > # might need to be cast into objects (ie, contents for a "domain
> > > # table"). What about non-server entities?
> > > #
> > > # after more discussions, Cullen stated:
> > > # "we won't try to solve this one at this point."
> > >
> > > <snip>
> > > ------------------------------------------------------
> > > 80) 1. Lack of "Interface" concept.
> > >
> > > SIP MIB doesn't use a concept of a physical or logical
> > > "interface" - ifIndex (see RFC 2863 and draft-ietf-entmib-v3).
> > > I think it is a big conceptual flaw because a typical network
> > > application (which a normal SIP device is) has a concept of multiple
> > > network interfaces either directly mapped to physical interfaces or
> > > being logically defined for numerous application reasons.
> > >
> > > AI: none
> > > # The authors exchanged a series of emails with Orit at the end of
> > > # March 2004. Below is a summary of our responses.
> > > # In ITU-T, H.341 MIB for H.323 took the route of ifIndex first in the
> > > # early days and they changed to applIndex. This was the motivation
> > > # for the SIP mib to go with ifIndex. Since then, the TRIP mib was
> > > # also drafted with applIndex
> > > # http://www.ietf.org/internet-drafts/draft-ietf-iptel-trip-mib-10.txt
> > > # TRIP MIB draft 10 has passed IETF Last Call and is in the RFC ed
> > > # queue. We think we are consistent with the use of the RFC2788 mib.
> > >
> > > # Orit is ok with our explanation and trust the mib doctor would raise
> > > # this as an issue. Comment closed
> > >
> >
> > <klingle>
> > bob, i presume these are your comments again...
> >
> > > Usually most of the information for configuration, management and
> > > monitoring needs to be defined per "interface". The most obvious
> > > examples include: timers, retry counters and security parameters.
> >
> > <klingle>
> > i'm not sure i agree with that when, in the case of a sip entity,
> > you are dealing with an application layer entity. the real
> > "interface" from sip to the internetworking layers is at an
> > IP port level more than the traditional ifIndex networking sublayers
> > below that.
> >
> > i'm not sure exactly of the perspective you are coming from when you
> > say "Usually most of the information for configuration, management and
> > monitoring needs to be defined per 'interface'."
> > i would agree with the statement if we were discussing mgmt of
> > routers or switches. i'm not convinced though when we are talking
> > about SIP protocol entities.
> >
> >
> > >
> > > If a certain implementation doesn't have a concept of interface
> > > - a single "dummy" interface can be used across all MIB
> > > definitions for this simple device.
> >
> > sure. if we determine that ifIndex is appropriate to use.
> > that's the larger question at this point.
> >
> > if ifIndex is not the right answer, but we still need to
> > contend with the requirement of having mulitple instance
> > of objects per applIndex, then we might consider introducing
> > additional index objects... just not w/ the direct semantics
> > of being ifIndex.
> > </klingle>
> >
> >
> > >
> > > Note that the concept of "application" and the concept of
> > > "interface" are orthogonal - in many network devices
> > > both are used.sipProxyAuthMethod
> > >
> > > I suggest adding "ifIndex" as the second index
> > > after "applIndex" at least to the following tables:
> > > sipPortTable
> > > sipExtMethodSupportedTable
> >
> > we removed this table from rev -08.
> >
> > kevin
> >
> > > sipCommonCfgTimerTable
> > > sipCommonCfgTimerExtMethodTable
> > > sipCommonCfgRetryTable
> > > sipCommonCfgExpiresMethodTable
> > > sipCommonCfgExpiresStatusCodeTable
> > > sipUACfgSipServerTable
> > >
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
> > > This list is for NEW development of the core SIP Protocol
> > > Use sip-implementors at cs.columbia.edu for questions on current sip
> > > Use sipping at ietf.org for new developments on the application of sip
> > >
> >
> >
> >
> > _______________________________________________
> > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol
> > Use sip-implementors at cs.columbia.edu for questions on current sip
> > Use sipping at ietf.org for new developments on the application of sip
> >
>
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip