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

inline.

Manjunath S Bangalore wrote:
> Hi Bob,
> 
>   Thank you for the comments. Some responses inlined...
> 
> Bob Penfield wrote:
> 

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

I don't think we need to standardize a window, but the spec should 
suggest that sufficiently large windows be used to provide a useful 
aggregated statistic.




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

Two comments.

First, I agree with Bob that we should allow the carrier attribute to be 
present in the trunk group address family. There was another comment to 
the list regarding that.

Secondly, I do not think we should restrict a gw from advertising, to a 
particular peer LS, routes for EITHER the trunk group OR carrier OR 
regular e.164/dec/pent address families. It should be permitted to mix 
these. There are implications, however. This implies that there could be 
overlap in routes. What does this mean for things like TotalCapacity?



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

I agree it should mention this converstion. Indeed, the section on 
consolidation needs to talk a LOT more about the kinds of things that 
can be done.


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

I think we can allow a mix, so long as the meaning of this is well 
defined. One possible model is that there is no overlap. So, if a 
gateway has 5 trunk groups, it can advertise three of them using trunk 
group address family, and the other two using prefix address families. 
This would allow for an LS to convert the three trunk group family 
routes to prefix routes, and then even aggregate them with the other two 
prefix routes, without anything incorrect happening in terms of 
information represtation.

If the routes overlap, its more complex. An example of this case is a 
gateway with 5 trunk groups. It advertises 5 routes using trunk group 
families, and 5 with prefix families. In this case, an LS would need to 
know how these are correlated in order to properly manipulate them. I 
think this is a recipe for disaster, and I would prefer to mandate the 
non-overlapping case above.


-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email protected]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com