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

Hi Bob,

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

Bob Penfield wrote:

> 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.
>

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

>
> 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.

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.

>
> 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.

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)

>
> 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.

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.

>
> 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?

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.

>
> 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.

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.

> 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.

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.

> 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.

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

> 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.

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