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

From: David Zinman <[email-masked]>
Date: Tue, 9 Oct 2001 10:54:46 -0400

Comments inline.

> -----Original Message-----
> From: Bob Penfield [mailto:[email-masked]]
> Sent: Friday, September 07, 2001 2:44 PM
> To: IPTEL List
> Cc: Ping Zhou; Ephraim Dobbins; Peter Commerford
> Subject: [IPTEL] Review of draft-ietf-iptel-trip-mib-00.txt
> 
> 
> 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?
> 
[DZ] The TripRouteTable contains information about ALL TRIBS. 
However, to get a specific TRIB type, the information must be 
extrapolated from the objects within the entry. 

Three solutions to this issue: first, use different tables to 
represent different TRIBS. For example, we would have a 
TripAdjTRIBsInRouteTable, a tripExtTRIBRouteTable, a 
tripLocTRIBRouteTable, and a tripAdjTRIBsOutRouteTable. This is
 clumsy in my opinion and would have duplicate entries.

Second, we could use an octet as a mask to signify which TRIB(s) the
entry belongs to. For example 
 
tripRouteTRIBMask OBJECT-TYPE
   SYNTAX      OCTET STRING(SIZE(1..255))
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "Indicates which TRIB(s) this entry belongs to.
           If the least significant bit is set it would indicate 
           that this entry is of type adj-TRIBs-ins. The second
           bit set would indicate ext-TRIB, the third 
           loc-TRIB and the fourth adj-TRIB-out.

           0000 0011 would indicate that the entry belongs to
           adj-TRIB-ins and ext-TRIB."
       ::= { tripRouteEntry xx }

Third, we can leave the table as-is and explain better in the table
description what the table represents and how to determine 
what TRIB the route is.
 
>  
> 1) Section 4. change "with other TRIP gateways" to "between 
> TRIP Location
> Servers".
 
[DZ] Done.
 
> 2) Section 4. change "<draft-ietf-iptel-trip-07-txt>" to "[2]".
 
[DZ] Done.
 
> 3) Section 5 & 5.1. suggest "TRIP LS" instead of "TRIP entity", or add
> "(a.k.a. TRIP LS)".
 
[DZ] Done.
 
> 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.
 
[DZ] Done.
 
> 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?
 
[DZ] I think that keeping these parameters in the Peer table 
would be the best way to go. If the implementation is such that 
they are globally defined, then the peer entry can use these 
global values. For this case we should remove 
tripMinItadOriginationInterval and 
tripMinRouteAdvertisementInterval from the tripCfgTable because 
they exist in the Peer table also.

> 6) tripLocalAddr: The description should say this is the IP 
> address of the
> local LS that peers connect to.
 
[DZ] Done.
 
> 7) tripLocalPort: The description should say this is the port 
> on the local
> LS that peers connect to.
 
[DZ] Done.
 
> 8) tripSupportedCommunityId: A community ID is not an ITAD. suggest
> CommunityID (see issue 4 above).
 
[DZ] Done.
 
> 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.
 
[DZ] Both TripPeerIdentifier and TripPeerRemoteItad will be 
made read-only because either the local application will 
determine the values, or the values will be learned from the 
remote end. I agree that tripPeerRemotePort should be part 
of the index.
 
> 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.
 
[DZ] see 9.
 
> 11) tripPeerKeepAlive: The description should indicate that 
> this is the
> negotiated value when a connection is established.
 
[DZ] Done.
 
> 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.
 
[DZ] Done.
 
> 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.
 
[DZ] discussed as part of TripRouteTable.
 
> 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?
 
[DZ] Done.
 
> 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
 
[DZ] A peer will only give it's best route, therefore it will 
be unique. If the local LS receives the same route from 2 
different peers, the originatorId will be the same and the 
only unique field will be the peer.
 
> 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.
 
[DZ] It's in the PeerTable. Do we need to duplicate it in the 
routeTable, or move it from the PeerTable?
 
> 17) tripRouteAddressOriginatorId should be a TripId instead 
> of a TripItad.
 
[DZ] Done.
 
> 18) tripBestRoute: I'm not sure what this means. Maybe you 
> need to identify
> the decision process phase in which this is determined.
 
[DZ] This identifies a locTrib.
 
> 19) tripRouteCommunityId: A community ID is not an ITAD. 
> suggest CommunityID
> (see issue 4 above).
 
[DZ] Done.
 
> 20) tripITADTopologyOrigId should be a TripId instead of a TripItad.
 
[DZ] Done.
 
> (-:bob
> Robert F. Penfield
> Chief Software Architect
> Acme Packet, Inc.
> 130 New Boston Street
> Woburn, MA 01801
> [email-masked]

Cheers,
 DZ
 
---
David Zinman	Software Designer
SS8 Networks Inc. "One Better"
Phone: (613)592-2100 Ext. 3252
Fax: (613)592-9634
mailto:[email-masked]
http://www.ss8.com