[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Iptel] Review of TGREP -01
Hi Vijay,
Thanks for taking the time to do a detailed review.
Some comments inline...
"Vijay K. Gurbani" wrote:
> Folks:
>
> I volunteered to 'expert' review TGREP at the San Francisco IETF.
> Enclosed are my comments. Hope they are helpful.
>
> 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
> ------------------------------------------------------------------------------
> Comments on
> <http://www.ietf.org/internet-drafts/draft-ietf-iptel-tgrep-01.txt>
>
> A philosphical comment first: after reading the I-D, it appears that
> registration is but a pre-requsite for the selection of the appropriate
> gateway, so the thrust is on gateway selection more than gateway
> registration. Is TGREP a misonomer? I realize it is too late to change the
> name now, and I am not advocating doing so.
>
> On to some real comments.
>
> * First paragraph of Page 4: too many "etc." in the paragraph. Suggest
> re-wording to take some of them out.
>
> * Section 3.5.5: The strength (MUST) in the following statement:
>
> Routes MUST not be disseminated external to the ITAD, with
> TrunkGroup attribute.
>
> should be replaced to a SHOULD (there is also a gratuitous comma in the
> sentence above).
>
> Someone correct me if I am mistaken, but there may be arrangements
> between
> ITADs to carry emergency (SOS) calls identified by a trunk group
> name. I
> know that trunk group names are not standardized, but there is an I-D
> tackling that particular problem
> (http://www.ietf.org/internet-drafts/draft-
> ietf-iptel-trunk-group-00.txt>). In certain cases, it may be
> beneficial
> for two autonomous ITADs to have peering arrangements for SOS trunk
> groups.
> I would thus like to leave open the possibility of the
> disseminating routes
> with TrunkGroup attributes in the future.
>
> * There isn't any Security section. Even if we assume the same security
> considerations as TRIP, we should simply point this out.
>
> * There isn't any section on IANA considerations. The type codes and
> address families being discussed in the I-D have presumably been
> send to IANA and are in the processing queue.
> Suggest that you take off the following two sentences from the
> first paragraph of Page 4:
>
> The type codes for the new attributes and address families
> are yet to be obtained from IANA. An attempt will be made
> to assign the codes...
>
> and simply include an IANA section with the pertinent template
> and information.
>
> * Section 3, second paragraph ends with:
>
> However, there are certain attributes that are not
> relevant in TGREP. TGREP also defines certain new attributes
> that find a use in a TGREP update.
>
> Suggest you change it to something as follows which provides more
> directions to implementors:
>
> However, certain TRIP attributes are not relevant in TGREP; a
> TGREP speaker MAY ignore them if they are present in a TGREP
> message. In addition, TGREP defines the new attributes
> described in this document to be transported in a TGREP
> update (UPDATE message?).
>
> Please feel free to paraphrase what I wrote above
>
> * Section 3.1; I would suggest flipping the order of the first and second
> paragraph. The second paragraph actually defines the
> TotalCircuitCapacity
> attribute.
>
> * Section 3.2: I think this section makes a strong case for NOT
> disseminating
> the AvailableCircuits attribute (due to its dynamic nature).
> Furthermore,
> in section 3.2.5 you do indicate that "Routes MUST NOT be disseminated
> with the AvailableCircuits attribute." However, the first paragraph of
> section 3.2 provides an escape clause to the implementor:
>
> "...it MUST NOT be propagated unless the LS is sure that it
> is relatively static."
>
> Section 3.2.5 and the openeing paragraph of section 3.2 are in direct
> conflict with each other.
>
> Suggest that you take out the "...it MUST NOT be propagated unless the
> LS is sure..." sentence and simply state that this attribute MUST NOT
> be propagated.
>
> * Section 3.3.1, in the sentence: "The first component field represents
> the total number of calls terminated normally ...", I would suggest
> you replace 'successfully' with 'normally'. More so since we just
> defined (in the previous section) what we consider are the criteria
> for a successfull call.
>
> * Section 3.3.5: There is ambiguity in the sentence:
>
> Routes MUST NOT be disseminated with the CallSuccess
> attribute. Its potential to change dynamically does not
> make it suitable to disseminate in most cases.
>
> What is the final consensus: routes MUST not be dissemniated with this
> attribute? or am I allowed an escape clause since the sentence also
> says "...in most cases."
>
> 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.
Would like to get a consensus on whether we go with SHOULD or MUST.
>
> * Section 3.5.1: "The presence of TrunkGroup attribute with the length
> field of the attribute as 0 signifies that the TGREP GW can
> terminate ALL
> trunkgroup for the given Reachable route(s)."
>
> Does not the *absence* of TrunkGroup attribute signify the same? I
> would
> suggest that if a TGREP GW can terminate ALL trunkgroups, don't use a
> wildcard attribute of 0. This simply requires more processing and
> special-
> casing. My suggestion would be that the absence of a TrunkGroup
> attribute
> amply signifies the GW's capability of handling all trunk groups.
>
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.
>
> * I would suggest taking Section 3.8 out completely; it does not add any
> extra essence to TGREP. Furthermore, since it has only one sub-section
> which represents that cost/pricing was not considered as an attribute
> for a variety of reasons. If you had considered other attributes as
> well and rejected them, it may have been a good idea to have an entire
> section devoted to such attributes. But since you have only one such
> attribute, I would just as soon leave it out.
>
> * Section 3.9 talks about a "lightweight" version of TRIP; does such a
> beast
> exist? Does what you describe next constitute a "lightweight"
> version of
> TRIP? Please clarify.
Yes, the reference to "lightweight" refers to the description that follows in the
subsections in 3.9
To avoid any confusion, I think it is best remove the statements that refers to a
"light weight" version of TRIP
>
>
> * In Section 3.10, I am not sure I understand the difference between
> 'aggregation' and 'consolidation' as you use it. Is not what you
> describe
> at the top of page 22 aggregation?
>
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
To take an example, if there are multiple gateways offering routes to an E.164
destination "408" but with possibly different attributes (Eg: Carrier), the
LS/Proxy can combine these to form one route for "408" but representing the
attribute information collectively. This process is Consolidation
If, for example, the LS/Proxy receives routes for 4080, 4081, 4082, ... 4089 from
amongst a set of gateways, it could aggregate these different candidate routes to
have a summarized route destination "408" with each of the attributes computed
using the Aggregation procedures defined in the TRIP RFC.
>
> Furthermore, you state in the same paragraph that there is a
> possibility
> of loosing routes if consolidation was not done. Why would that be the
> case? I am not sure I understand why the routes would be lost if
> consolidation was not done.
Let us take an example of how can you could lose routing information if you don't
consolidate
If there are multiple routes for an E.164 destination, "408", and if they are
presented separately to the TRIP system on the LS/Proxy, the route selection
procedures is going to select only one of these (in a contest with E-TRIP routes,
if any) as a winner and advertise it to the other LSs in the ITAD. So, if, for
instance, the proxy receives routes through different carriers for "408", then
only one of these is going to be propogated further. On the other hand, if you
were to consolidate the routing information from the different routes, then you
maximize the information propogated downstream.
So, before the LS/Proxy presents routes to the TRIP system, it should first
consolidate routes, and then aggregate them. These are two distinct operations
>
>
> * Section 3.10, I do not understand what the last paragraph is trying to
> say. There is a lot of gratuitous commas and I am not sure I
> understand
> the implications of the last statement. If, as you state in the para-
> graph above, consolidation is so important that routes may be lost
> if not
> done, why leave it upto individual implementations. I don't see any
> guidelines which will help implementors code consolidation in a
> consistent
> manner (again, I am unclear as to where 'aggregation' stops and
> 'consolidation' begins; maybe that is the root of all my problems
> with this
> section. Needs some work to clarify things...)
>
Hopefully, my response above should clarify things. If there are any other
questions, please do bring it to our attention
>
> Nits and Grammatical/structural comments: please incorporate these if they
> make sense to you.
>
> * Page 3:
>
> The decision about which gateway to use depends on many
> factors, including their availability, remaining call
> capacity and call success statistics particular POTS
> destination.
>
> I am not sure what you mean by the last clause, "...and call success
> statistics particular POTS destinatios". Maybe you meant "...and
> call success statistics TO particular POTS destinations."?
>
> * First paragraph of Page 4: Suggest replacing the sentence:
>
> The document aims at specifying all the attributes that
> can go in on the TGREP session.
>
> with:
>
> This document specifies all the attributes that are useful
> for inclusion in a TGREP session.
>
> * Section 3.3, suggest replacing the following two sentences:
>
> For example, a call that reaches the Alerting stage but
> does not get connected because of called party being unavailable
> is conventionally considered a successful call. Similar is the
> case when the called party is busy.
>
> with:
>
> For example, a call that reaches the Alerting stage but
> does not get connected due to the unavailability of the called
> party, or the called party being busy, is conventionally
> considered a successful call.
>
> * Section 3.6.1, second paragraph:
> s/It is the same as the E.164/The CountryCode is the same as the E.164/
>
> * Section 3.7: s/for a GW cam advertise/for a GW to advertise/
>
> * Section 3.10: s/into the Location Server for propogation/into the
> Location
> Server./
>
Will take care of the rest of the comments as you suggested.
Thanks again,
-Manjax
>
> _______________________________________________
> Iptel mailing list
> Iptel@ietf.org
> https://www.ietf.org/mailman/listinfo/iptel
_______________________________________________
Iptel mailing list
Iptel@ietf.org
https://www.ietf.org/mailman/listinfo/iptel