Subject: [IPTEL] Review of draft-ietf-iptel-trip-mib-00.txt

From: "Bob Penfield" <[email-masked]>
Date: Fri, 7 Sep 2001 14:44:06 -0400

We have completed our review of the TRIP MIB and have a number of comments
enumerated below. Special thanks to Ping Zhou, Ephraim Dobbins, and Peter
Commerford for their assistance in this review.

The most significant issue is that of the tripRouteTable. It is not clear
which specific TRIBs it represents. Also, based on some of the information
in the table, it seems to combine data from received and derived routes
(e.g. tripRouteBest) which may prove problematic for implementers. If
implementers follow the TRIB structure defined in the base spec, they may
need to instantiate another derived/combined TRIB for SNMP reporting.
Otherwise significant processing/combing of the TRIBs might be required to
respond to a GET. I don't know whether the right thing to do is have a
separate table for each TRIB or to only report specific sets of TRIBs. The
closest thing to what the table defined represents is the Adj-TRIB-Ins of
internal peers plus the Ext-TRIB derived from local routes and Adj-TRIB-Ins
of external peers. Or am I missing something?

1) Section 4. change "with other TRIP gateways" to "between TRIP Location
Servers".

2) Section 4. change "<draft-ietf-iptel-trip-07-txt>" to "[2]".

3) Section 5 & 5.1. suggest "TRIP LS" instead of "TRIP entity", or add
"(a.k.a. TRIP LS)".

4) Several places use TripItad for community-id. Community ID is not an ITAD
ID and should be its own type. Suggest adding CommunityId to Textual
Conventions on page 6.

5) TripCfgEntry: Hussein said that the other timers (ConnectRetry, HoldTime,
KeepAlive) belong here. The spec does not explicitly say whether these are
configured for the LS (like SendReceiveMode) or on a per-peer basis. The MIB
defines them as per-peer parameters (in TripPeerEntry). However, a given
implementation might implement them as LS-wide parameters. Should they be
defined in both places to support both kinds implementations? Or should the
spec be interpreted as defining these as LS-wide parameters?

6) tripLocalAddr: The description should say this is the IP address of the
local LS that peers connect to.

7) tripLocalPort: The description should say this is the port on the local
LS that peers connect to.

8) tripSupportedCommunityId: A community ID is not an ITAD. suggest
CommunityID (see issue 4 above).

9) tripPeerEntry: The key consists of only the peer's network type and
address. The spec supports the idea of multiple TRIP instances on a single
host. The tripPeerRemotePort needs to be included. However, this is defined
as read-only, which indicates this port is learned when the connection is
established. If the peer initiated the connection, this may not be the same
port that the local LS would attempt to connect to. If the
TripPeerIdentifier and TripPeerRemoteItad were configured parameters, they
could be used as a unique key. However, the TripPeerIdentifier is read-only
(indicating is learned during the connection), but the TripPeerRemoteItad is
read-create (indicating it is configured). From reading the spec, these
could be either configured or learned.

I think what is needed is tripRemotePeerPortConfigured (the port this LS
will try to connect to) to be added to the key. There is not currently a
field for this.

10) tripPeerRemoteItad: Should this be "read-only" ? or should
tripPeerIdentifier be "read-create". I think they should be the same.

11) tripPeerKeepAlive: The description should indicate that this is the
negotiated value when a connection is established.

12) tripPeerRouteTypeTable: This table is the expansion table of
tripPeerTable  (base table). The DESCRIPTION clause should specify the
relationship of the instances in the base table and expansion table, when
elements in the expansion table should be added or removed due to the change
of the base table. This kind of description will be very helpful in
implementing this table, otherwise it will cause confusion and may be
inconsistent with different implementations.

Same issue for tripRouteCommunityEntry & tripRouteEntry, and
tripItadTopogyIdTable & tripItadTopologyTable.

13) tripRouteTable: It is not totally clear which TRIBs this table contains.
It says "received routes" which implies it is the Adj-TRIB-Ins of all peers
(internal & external). However, the presence of tripRouteAddressOriginatorId
without an originating ITAD would indicate that routes derived from external
sources inserted into the Ext-TRIB should be included as opposed to the
received Adj-TRIB-In of the external peer (as they would have the local LSs
TripID as the OriginatorID).

Hussein brought up the issue of whether we need a table with the routes that
the LS will advertise.

14) tripRouteAddress: a size of 32 is certainly reasonable for just a
telephone number, but I have heard talk of a number of different address
families that might involve concatenating things like CIC-code,
carrier-domain or any other kind of so called "routable element". Would it
hurt to have this be 255 instead?

15) tripRouteEntry: tripRouteAddressOriginatorId should be in the key
instead of tripRoutePeer. A given LS may "learn" several routes from a peer
where the only distinguishing characteristic of the route is the Trip ID of
the originating LS.

same issue for tripRouteCommunityEntry

16) tripRouteEntry: you have tripRoutePeer which is the Trip ID of the LS
that sent the route, but there is not tripRoutePeerITAD to identify the ITAD
that the peer is in.

17) tripRouteAddressOriginatorId should be a TripId instead of a TripItad.

18) tripBestRoute: I'm not sure what this means. Maybe you need to identify
the decision process phase in which this is determined.

19) tripRouteCommunityId: A community ID is not an ITAD. suggest CommunityID
(see issue 4 above).

20) tripITADTopologyOrigId should be a TripId instead of a TripItad.

(-:bob

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