[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
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