Subject: RE: [IPTEL] RE: TRIP MIB Question

From: "David Zinman" <[email-masked]>
Date: Fri, 27 Apr 2001 13:31:10 -0400

Bob,

Yes "tripPeerRtTypeProtocolId" is the same as
"tripPeerRtTypeSupportedProtocol"
and "tripPeerRtTypeAddrFamilyId" is the same as
"tripPeerRtTypeAddrFamily". The problem is that SNMPv2 describes
indexes in a table as having a MAX-ACCESS of not-accessible.
This creates a problem of a table where the only important attributes
are the indexes. Instead of using a rowStatus attribute (which would
be silly since we can neither write to or create any elements in
the table), I wanted to use something more useful. Since the only
things important here are the protocol and address family, I used
those, even though I know they are redundant. If this is too awkward,
I can use the rowStatus, or just one of the existing objects.

Cheers,
DZ

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Bob Penfield
Sent: Thursday, April 26, 2001 11:11 AM
To: David Zinman; IPTEL List
Cc: [email-masked]
Subject: Re: [IPTEL] RE: TRIP MIB Question

David,

I think that is an excellent solution. I'm a bit confused though. Why are
there 4 fields in the
tripPeerRouteTypeEntry sub-table? What is the difference between
"tripPeerRtTypeProtocolId" and
"tripPeerRtTypeSupportedProtocol" ? What is the difference between
"tripPeerRtTypeAddrFamilyId" and "tripPeerRtTypeAddrFamily" ? Please forgive
my MIB ignorance.

Bob
d:-)

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
[email-masked]

----- Original Message -----
From: "David Zinman" <[email-masked]>
To: "Bob Penfield" <[email-masked]>; "IPTEL List"
<[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, April 25, 2001 3:15 PM
Subject: [IPTEL] RE: TRIP MIB Question

> Bob,
>
> I am going to try to tackle two problems here.
>
> The first is the issue of adding new protocols and address families.
> ====================================================================
>
> I propose to remove the TC for TripAppProtocol and assign object
> identifiers (OIDs) to the protocols. We would have an entry in the
> TRIP MIB for TRIP Supported Protocols:
>
>    tripSupportedProtocols  OBJECT IDENTIFIER ::= { trip 100 }
>
> Then each protocol would be defined under this MIB tree branch:
>
>   tripSupProtSIP          OBJECT IDENTIFIER ::= { tripSupportedProtocols
1 }
>   tripSupProtH323Q931     OBJECT IDENTIFIER ::= { tripSupportedProtocols
2 }
>   tripSupProtH323RAS      OBJECT IDENTIFIER ::= { tripSupportedProtocols
3 }
>   tripSupProtH323ANNEXG   OBJECT IDENTIFIER ::= { tripSupportedProtocols
4 }
>
> If a new protocol is used it can be defined by the private enterprise
> MIB implementers. Eg:
>
>   myPrivateEntProtocol OBJECT IDENTIFIER ::= { privEntProts 1 }
>
> As protocols are developed it would be easy to add them using this method.
>
>
> Similarly for address families we would remove the TC for address families
> and define another OID:
>
>   tripAddressFamilies    OBJECT IDENTIFIER ::= { trip 101 }
>
> Then each address family would be defined under this MIB tree branch:
>
>   tripAddrFamilyDecimal   OBJECT IDENTIFIER ::= { tripAddressFamilies 1 }
>   tripAddrFamilyHex       OBJECT IDENTIFIER ::= { tripAddressFamilies 2 }
>
> New address families could be added into the private enterprise
> MIB. Eg:
>
>   myPrivateEntAddrFamily OBJECT IDENTIFIER ::= { privEntAddrFamilies 1 }
>
> Again it would be easy to add more address families.
>
>
> TripAppProtocol+TripAddressFamily Pairs
> =======================================
> I propose this solution to the problem of multiple
> TripAppProtocol+TripAddressFamily pairs outlined by Bob Penfield:
>
> - Remove tripPeerSupportedProtocol and tripPeerAddressFamily
>   from the Peer Table.
>
> - Add a new 'sub' table to the Peer Table called
>   tripPeerRouteTypeTable which will have the following
>   structure:
>
> tripPeerRouteTypeTable OBJECT-TYPE
>   SYNTAX      SEQUENCE OF TripPeerRouteTypeEntry
>   MAX-ACCESS  not-accessible
>   STATUS      current
>   DESCRIPTION
>       "The TRIP peer Route Type table. This table contains one
>       entry per supported protocol - address family pair."
>   ::= { trip x }
>
> tripPeerRouteTypeEntry OBJECT-TYPE
>   SYNTAX      TripPeerRouteTypeEntry
>   MAX-ACCESS  not-accessible
>   STATUS      current
>   DESCRIPTION
>       "Entry containing information about the route type that
>       the TRIP peer supports."
>   INDEX { applIndex,
>           tripPeerRemoteAddrInetType,
>           tripPeerRemoteAddr,
>           tripPeerRtTypeProtocolId,
>           tripPeerRtTypeAddrFamilyId }
>     ::= { tripPeerRouteTypeTable 1 }
>
> TripPeerRouteTypeEntry ::= SEQUENCE {
>     tripPeerRtTypeProtocolId         OBJECT IDENTIFIER,
>     tripPeerRtTypeAddrFamilyId       OBJECT IDENTIFIER,
>     tripPeerRtTypeSupportedProtocol  OBJECT IDENTIFIER,
>     tripPeerRtTypeAddrFamily         OBJECT IDENTIFIER
> }
>
> tripPeerRtTypeProtocolId OBJECT-TYPE
>   SYNTAX      OBJECT IDENTIFIER
>   MAX-ACCESS  not-accessible
>   STATUS      current
>   DESCRIPTION
>       "The identifier of a protocol that this peer is using."
>   ::= { tripPeerRouteTypeEntry 1 }
>
> tripPeerRtTypeAddrFamilyId OBJECT-TYPE
>   SYNTAX      OBJECT IDENTIFIER
>   MAX-ACCESS  not-accessible
>   STATUS      current
>   DESCRIPTION
>       "The identifier of an address family that this peer belongs to."
>   ::= { tripPeerRouteTypeEntry 2 }
>
> tripPeerRtTypeSupportedProtocol OBJECT-TYPE
>   SYNTAX      OBJECT IDENTIFIER
>   MAX-ACCESS  read-only
>   STATUS      current
>   DESCRIPTION
>       "A protocol that this peer is using."
>   ::= { tripPeerRouteTypeEntry 3 }
>
> tripPeerRtTypeAddrFamily OBJECT-TYPE
>   SYNTAX      OBJECT IDENTIFIER
>   MAX-ACCESS  read-only
>   STATUS      current
>   DESCRIPTION
>       "An address family that this peer belongs to."
>   ::= { tripPeerRouteTypeEntry 4 }
>
>
> Or instead, alternatively the table could be indexed by arbitrary
> integers and each Protocol/AddressFamily pair would be displayed
> as raw integers, NOT as OIDs as described above. Eg:
>
> +--------------+--------------+-------+----------+----------------+
> | PeerInetType | PeerInetAddr | index | Protocol | Address Family |
> +--------------+--------------+-------+----------+----------------+
> |      1       | 192.1.34.55  |   1   |     1    |       1        |
> +--------------+--------------+-------+----------+----------------+
> |      1       | 192.1.34.55  |   2   |     1    |       2        |
> +--------------+--------------+-------+----------+----------------+
> |      2       |4e:14:00:72...|   3   |     3    |       2        |
> +--------------+--------------+-------+----------+----------------+
> |     16       | myDnsName@so |   4   |     2    |       1        |
> +--------------+--------------+-------+----------+----------------+
>     ...
>
> This way is easier but much less descriptive because the integers
> would have to be looked up in all cases to map the protocol and
> address families to expressive names.
>
> Cheers,
> DZ
>
> ---
> David Zinman       Software Designer
> SS8 Networks Inc.
> Phone: (613)592-2100    Fax: (613)592-9634
> mailto:[email-masked] http://www.ss8.com
>
>
>
> -----Original Message-----
> From: Bob Penfield [mailto:[email-masked]]
> Sent: Monday, April 23, 2001 1:26 PM
> To: IPTEL List; [email-masked]; [email-masked]
> Subject: TRIP MIB Question
>
>
>
> The tripPeerEntry object (page 11-12 of draft-zinman-trib-mib-01.txt) only
> allows a single tripPeerSupportedProtocol and tripPeerAddressFamily, yet
the
> TRIP spec provides for multiple Route Types Supported in the OPEN message.
> Also, the address family and protocol are joined together in the Route
Types
> Supported capability info of the OPEN message. Shouldn't there be a list
of
> TripAppProtocol+TripAddressFamily pairs in the tripPeerEntry object?
>
> Thanks,
>
> Bob
> d:-)
>
>
> Robert F. Penfield
> Chief Software Architect
> Acme Packet, Inc.
> 130 New Boston Street
> Woburn, MA 01801
> [email-masked]
>
>
> _______________________________________________
> IPTEL mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/iptel
>

_______________________________________________
IPTEL mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/iptel

_______________________________________________
IPTEL mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/iptel