Re: [Iptel] Review of TGREP -01

[Manjunath Bangalore <manjax@cisco.com>]

Vijay,

Sounds good.

We will add the examples and the additional explanation I had for
"Consolidation" v/s "Aggregation" in the next revision

About the propogation of Available Circuits, I am fine with not propogating it
on I-TRIP beyond the first hop LS. Since it is the most restricted form, my
intention was just to solicit feedback from the community in case there are
any special scenarios that warranted its use.

Thanks,
-Manjax

"Vijay K. Gurbani" wrote:

> 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