[Iptel] Review of TGREP -01

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

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.

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

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

    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.

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

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


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