Subject: [IPTEL] draft-ietf-iptel-trip-gw-00.txt has been posted

From: Dhaval Shah <[email-masked]>
Date: Fri, 07 Jun 2002 07:51:22 -0700

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-masked]
http://lists.bell-labs.com/mailman/listinfo/iptel

---

From: "Bob Penfield" <[email-masked]>
Date: Tue, 11 Jun 2002 13:48:04 -0400

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-masked]

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

---

From: Manjunath S Bangalore <[email-masked]>
Date: Wed, 12 Jun 2002 15:16:29 -0700

Hi Bob,

  Thank you for the comments. Some responses inlined...

> nice to use TLS, the RFC does not even mention it as a possibility.

This is correct, security should be based on IPSec. We will change it in the
next version

> as the "time window" that gateways should use for reporting CallSuccess.

The gateway reporting the Call Success attribute can discard old values
replacing them
with newer values after certain periods of time. The duration that it chooses to
retain call
success information for, can be a local matter based on vendor preferences,
possibly
based on the volume and nature of traffic handled by this network.

We will give further thought on including a measurement period in conjunction
with the
Call Success information that is reported.

> the length of trunkgroups? Certainly 1-octet is enough for a prefix length.

It is true that 1-octet suffices, but we chose 2-octets to be in line with the
format used
in the TRIP RFC in the generic TRIP route representation that includes
Prefix-based
destinations (Sec 5.1.1.1)

> an indication of country for the carrier.

The question here is, can the LSs participating acrossing national boundaries be
explicitly
programmed to carry the right Carrier information, or do we still need to
associate a "country"
component with the encoding of CIC ? Need to do further investigation on this.

> routes would be multiply advertised with different address families?

The stance that we have taken with the current version of the draft  is to
address
gateway management based, purely on Carriers or Trunkgroups, not as a
combination. The policy in the provider network in combination with the
choice of managing gateway resources at the granularity of either trunkgroups or

carrierswould help determine which address family is used to advertise routes
from the gateway. Some additional comments in this regard follow later

The current plan is to address management of gateways on the basis of
"Carrier and Trunkgroup" as a combined unit in the next version of the draft.

> carrier-based routes into prefix-based routes for the I/E-TRIP LS.

Yes, this is one of the purposes of consolidation - Converting routes from one
address family to
another using the relevant attributes to build the routes in the recipient
address family. The
address family to which the gateway routes are transformed is dictated by the
provider policy;
it is possible that the routing policy in the network is based on Trunkgroups,
and routes
received on the Trunkgroup address family from the gateway may be propogated to
I-TRIP
on the same address family, after possibly modifying the nexthop server to the
managing LS/Proxy.
For E-TRIP, routes may be transformed to the Prefix address family as you
mentioned above.

The draft can mention "converting" routes from one address family to another as
part of the
consolidation process but should not place a restriction on what address
families are chosen
to propogate the routes further on I/E TRIP, which is policy-driven.

> an internal peering relationship? Section 4.10 says it is external.

The relationship between a TRIP GW and the first hop Proxy/LS does not have an
exact match to
either an internal peer, or an external peer as defined in the TRIP RFC. A
TRIP-Lite peering relationship
with a GW however bears a greater semblance to an external peer in terms of the
processing that GW routes are subject to. When routes are received from an
internal peer on an LS, they are just flooded to other internal peers without
any change; On E-TRIP, on the other hand, the LS does aggregation and possibly
other attribute manipulation subject to policy, before propogating routes to an
external peer. Similarly when GW routes are received on an LS/proxy undergo
processing, wherein routes are possibly transformed to a different Address
family with attribute changes through consolidation. This is the reason it is
compared to an external peering
relationship. Yes, it is true that administratively the GWs and the first hop LS
are more likely to be managed
by the same administrative authority, which makes this classification as
"external" confusing from the TRIP perspective.

> about all gateways and could deliver a given call to any gateway even if it

One issue you should handle where a gateway is managed by two different
proxy/LSs based on its
capacity, is there should be some way of synchronizing information between the
two proxy/LSs
for effective GW management

> trunkgroup or carrier based routes bets express the routes in a gateway.

The understanding is, that at any given time, it suffices for the gateway to
advertise
routes on any one address family, the choice of which is driven by the
management
model in a provider network. If the choice is to manage gateways at the
granularity of
trunkgroup resources, then Trunkgroup address family can be used; Similarly,
Carrier address family can be used if gateways are managed in terms of Carriers.
If there
is no notion of trunkgroups or Carriers in the network, then Prefix address
family should
be used to advertise only the reachability to PSTN prefixes.

In summary, the address family that lends itself to manage gateways and its
resources most
effectively based on a provider's requirements should be chosen as the vehicle
to advertise routes.

Also, as said earlier, transformation of TRIP-Lite routes to a different address
family before
propogating them on I/E TRIP makes sense, and the choice of address family is
driven by
Provider policy.

Thanks,
-Manjax