Re: draft-ietf-iptel-trip-gw-00.txt has been posted

Hi Dhaval,

Here are some comments on the draft:

1) Section 3 states that TRIP can be run over TLS, however, RFC 3219 clearly
states that IPSEC is the security mechanism for TRIP. Although it would be
nice to use TLS, the RFC does not even mention it as a possibility.

2) For the CallSuccess attribute (sec 4.3), there is no guidance or
indication given as to the time period for which the total and successful
calls apply. Providing information which is measured over a several days may
not be as useful as information about the last few minutes. I suggest the
addition of the measurement period in seconds, and/or some guidance be given
as the "time window" that gateways should use for reporting CallSuccess.

3) Why did you choose 2-octets for the length of the Prefix and 1-octet for
the length of trunkgroups? Certainly 1-octet is enough for a prefix length.

4) What is the motivation for using the ITU's ICC? In the Scope section of
M.1400, it states "This Recommendation defines designations and additional
information intended primarily for human-to-human communication between
various Operators", and further "this Recommendation defines the
presentation formats of data at human-to-computer interfaces, but does not
define the data communication formats for interfaces between computer
systems". Their primary purpose for identifying connections between network
operators.

The primary purpose of including a carrier in TRIP is to be able to
associate caller/provider preference of a carrier with the routes that reach
that carrier. At the risk of exposing my ignorance, as far as I can tell,
the ITU ICC is not used to express carrier preference in telcom protocols.
Please educate me if I am wrong. An appropriate carrier indicator would be
one that would be present in the call signaling protocol, and could
potentially be specified by the user (caller). For example, the 'cic' tel
URL parameter defined in draft-yu-tel-url-04.txt, which is based on CICs
dialed by users (NANPA CICs for North America).

The format does not even follow that defined in M.1400, which states in
section 5.1 "Operator ID is the ICC that identifies the operator originating
a route termination identification (one to six characters, each character
being either alphabetic (i.e. A-Z) or numeric (i.e. 0-9) characters)."

The carrier code still does not address non-US carriers. There needs to be
an indication of country for the carrier.

5) I don't understand why the Carrier attribute would be prohibited when the
TrunkGroup address family is used and why the TrunkGroupAttribute cannot be
used with the Carrier address family. It seems to me that a gateway divided
into trunkgroups, each of which reach one or more carriers, would advertise
its routes using the trunkgroup address family, listing the carriers and
prefixes reachable thru that trunkgroup. The updates would include the
available & total circuits, and call success attributes. When these routes
were consolidated, the trunkgroup would be stripped, and a set of
prefix-based routes (with carrier attributes) would be injected to the
I-TRIP/E-TRIP LS. If the carrier attribute cannot be included, how are the
trunkgroups and carriers to be associated? Are you suggesting the same
routes would be multiply advertised with different address families?

BTW, I think the draft should explicitly mention "converting" routes from
one address family to another using the associated attributes. For example,
the Prefix attribute allows for converting trunkgroup-based and
carrier-based routes into prefix-based routes for the I/E-TRIP LS.

6) Isn't the relationship between the TRIP-GW LS instance and the gateways
an internal peering relationship? Section 4.10 says it is external.

I can envision a model where the TRIP-GW LS and all the gateways are a
mini-ITAD or GW-ITAD. For scalability and redundancy, there might be
multiple TRIP-GW LSs present (which sec 4.9.6 allows). To minimize the
direct peering relationships when there are more than 2 proxy/LSs, each
gateway would talk to two LSs, and the LSs would peer in order to propagate
the gateway routes within the GW-ITAD. Each proxy/LS would have information
about all gateways and could deliver a given call to any gateway even if it
was not a TRIP peer.

7) There is no restrictions or guidance given on the address families that
gateways use to advertise their routes. There is almost an implication that
gateways will advertise the same routes in different forms (with different
address families). If a gateways advertises all its prefixes as
reachable-routes an also advertises its trunk-groups as reachable routes
with prefix attributes, Is the LS suppose to use the Prefix attribute in the
trunkgroup reachable routes to determine that they are the same sets of
routes? If so, it should be explicitly stated. As I indicated before, I
think being able to take trunkgroup-based or carrier-based routes and
convert them into prefix-based routes to inject into the I/E-TRIP is very
useful because prefix-based routes are most suitable for I/E-TRIP and
trunkgroup or carrier based routes bets express the routes in a gateway.


cheers,
(-:bob

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

----- Original Message -----
From: "Dhaval Shah" <[email protected]>
To: <[email protected]>
Cc: <[email protected]>; <[email protected]>; <[email protected]>;
"Rajneesh Kumar" <[email protected]>
Sent: Friday, June 07, 2002 10:51 AM
Subject: [IPTEL] draft-ietf-iptel-trip-gw-00.txt has been posted


> Hi Folx,
>
> The draft is now available on the ftp server:
> ftp://ftp-eng.cisco.com/dhaval/draft-ietf-iptel-trip-gw-00.txt
>
> If someone has problems retrieving it, please email directly and we will
> email a copy to you.
>
> Please let us know if you have any questions.
>
> Thx,
> Dhaval (for the trip-gw team)
>
> _______________________________________________
> IPTEL mailing list
> [email protected]
> http://lists.bell-labs.com/mailman/listinfo/iptel
>