Re: [Iptel] Review of TGREP -01

["Vijay K. Gurbani" <vkg@lucent.com>]

Manjunath Bangalore wrote:
[...]

> Hi Vijay,
>
>   Thanks for taking the time to do a detailed review.
>   Some comments inline...
Manjunath:

No problem; comments inline.

Regarding the CallSuccess attribute, I wrote:

> > I would suggest that due to the dynamic nature of this attribute,
> > it NOT be included.  To a certain extent, CallSuccess and
> > AvailableCircuitCapacity work against each other: the better the 
> > call success rate at a gateway, the less the available circuit capacity 
> > may be in the near future at that gateway.  Since we are not 
> > dissemniating AvailableCircuitCapacity, let's do the same for 
> > CallSuccess.
> Agree that the wording for the two attributes you mention above needs 
> to be changed to eliminate any ambiguity.  However, before we change 
> to this, I would like solicit some feedback if there are any scenarios 
> which can benefit from propogating Available Circuits and Call Success. 
> This is akin to the earlier point you mentioned about wanting to
> advertise Trunk groups. For instance, there may be value a provider 
> sees in advertising Available Circuits within the ITAD when call 
> routing may be handled at more than LS.
The salient diffrenciator to me between the TrunkGroup attribute and
the CallSuccess attribute is that the former is somewhat static.
The latter is not, and prone to change.  Hence, it should probably
not be propogated.

Furthermore, Dhaval Shah wrote in a followup email:

> The reason some of us thought it was'nt a good idea to disseminate 
> these attributes in ITRIP is that the number of ITRIP "hops" could be 
> greater than one, and then the same issue of convergence persists, that 
> made us conclude not to include "dynamic" attributes in ETRIP in
> the first place.
So, that appears to lean on the direction of NOT propagating it.

> Would like to get a consensus on whether we go with SHOULD or MUST.
I think we should go with MUST not propogate...

Regarding my feedback on omitting TrunkGroup attribute you wrote:

> I think, treating the absence of the Trunkgroup attribute to mean 
> "able to terminate calls on all trunkgroups" is probably not be a 
> good thing. This is because Trunkgroup is an optional attribute. If 
> a vendor does not wish to implement (or advertise) this attribute, 
> the E.164 updates could be mis-interpreted as being able to be 
> terminated on all trunkgroups.
OK; sounds reasonable.  An explicit setting to 0 carries the desired
implication.

Regarding 'consolidation' and 'aggregation', you wrote the following:

> The matter at top of page 22 describes "Consolidation"
> To clarify, "Consolidation" combines multiple routes for the same route
> destination, whereas "Aggregation" combines routes for different route
> destinations that qualify as candidates to be summarized resulting in 
> route information reduction
[...Two examples deleted...]

I think you should put these deleted examples in the TGREP I-D
(including your explanation of the difference above), since
they contribute to understanding the difference between 'consolidation'
and 'aggregation'.

Thanks,

- vijay
--
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Wireless Networks Group/Internet Software and Services
Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440
Naperville, Illinois 60566     Voice: +1 630 224 0216

_______________________________________________
Iptel mailing list
Iptel@ietf.org
https://www.ietf.org/mailman/listinfo/iptel