Re: [sip] I-D ACTION:draft-ietf-sip-mib-08, changes since draft07

["Bob Penfield" <bpenfield at acmepacket.com>]

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.

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