Subject: Re: Updated draft

From: [email-masked] (Matthew Squire)
Date: Sun, 01 Nov 1998 17:16:40 -0500

Hi Jonathan, Henning - 

Here are some comments on the proposed GLP draft.  

- Matt

Major:

1) I have a slight disagreement with the definition of user agent.  To me,
the user agent is a "client" or "requestor" for the information distributed
by the GLP.  The definitions in the draft seem to indicate the user is
always at the ingress of the IP network (ie the computer or peripheral
starting a call, the ingress gateway, ...).  The difference between our
definitions is apparent when you mention that a UA may be unaware that
there is a gateway location service running.  To me, the UA is always
aware, it is the requesting entity.  In your unaware scenario (Proxy mode,
Section 6.3.2), I'd say that the UA is the part of the proxy node
representing the user when accessing the gateway database, not part of the
call originating application.  

2) In the AD section (5.1), there is the sentence "An adminstrative domain
must have either gateways or user agents or both."  I disagree.  UAs are
transient entities, an AD cannot know how many UAs it will have at any one
time.  This number may be zero at any point in time.

3) I'm not clear on the scope of GLP with respect to intra-domain LS-to-LS
communications.  At one point, GLP was an inter-domain protocol (this is my
understanding of the consensus at the last IETF), but now its a LS-to-LS
protocol, regardless of domain boundries.  I'm still in favor of only
refering to GLP as inter-domain.  Although one could use it intra-domain,
just as one could use BGP within an AS, it may not be the right solution.
Of course, after the protocol is defined, I may think its a great protocol
to use intra-domain - I'm just not comfy stating that now.

4) At no point in the framework is it mentioned that a LS may forward or
redirect a query to another LS.  Are we permitting this behaviour, or are
we assuming that any LS has all of the GW information it needs to make a
forwarding decision?  A redirect probably falls under the front-end
protocol and doesn't need to be specified, but an LS query of another LS
seems to fall under GLP.  Are we assuming a complete database is at every
LS, or can there be partial DB's and forwarded queries?    

5) I'm being nitpicky here, but the use of the term "gateway object" as to
what is distributed by the GLP (6.2.1) doesn't agree with the definition of
gateway given earlier.  "Gateway objects" are really just range(s) of PSTN
numbers with associated attributes.  There does not have to be an actual
gateway representing this collection of numbers and attributes due to
aggregation and/or proxy signaling agents.  Unfortunately, I don't have a
better term, but maybe someone else does. 

6) To weigh in on the open issues, 
 - although I'd love to have actual pricing structures in the protocol, it
just seems too damn complicated - if someone can figure out the right way
to do it, great, but if not, go with a simple metric
 - don't think we need to specify aggregation rules as such
 - please don't get into QoS routing

Misc:

1) The framework document describes a framework for a gateway location
service, which is much more than an inter-domain protocol for
distributing/aggregating gateway information.  And I'm in agreement that
the framework document should do this, if we don't have a common
understanding of the complete problem, its hard to define which pieces we
are and are not attempting to solve with any particular protocol.  This
document additionally defines a framework for the GLP front-end and
intra-domain GLP.  Would you consider changing the title to "A Framework
for Gateway Location Services"?  If so, then snappier names than
"front-end" and "intra-domain" might be in order (maybe GL Access Protocols
and GW Registration Protocols?).  

Minor: 

1) Section 2, "end user must select a gateway to terminate a call towards
the PSTN" seems too restrictive - Maybe "end user must select a server to
which it should forward signaling messages destined for a particular PSTN
destination"

2) Section 3, Location Server def: "gatekeeper of SIP server" ->
"gatekeeper or SIP server"

3) Section 5.4 (and other places): "gwloc protocol" -> GLP (let's pick an
acronym and stick with it)

4) Section 6.2: Seems like we should (and do) permit a GW to have > 1
originating LS, so the sentence "the LS is the one responsible for
determining when an update about the gateway should be sent" is too
restrictive (ie, get rid of 'the one').  

5) Section 6.2.1: "it it" -> "when it"

---------
This message came from the IETF IPTEL Working Group Mailing List.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 03 Nov 1998 00:09:32 -0500

Matthew,

Thanks for the detailed read and excellent comments. Replies are
interspersed with your points.

-Jonathan R.

Matthew Squire wrote:

> call originating application.

I guess the difference is that your UA is a more of a logical entity,
which can reside either on the end user's machine (when the selection of
gateway is explicit), or in the LS (when the end user is unaware). The
current definition is a more physical device - the end user's machine or
gateway. Terminology-wise, your definition is probably closer to what a
"user agent" would really be. I'm not really sure it matters all that
much which definition we go by. Any thoughts here?

> time.  This number may be zero at any point in time.

I have received some other comments about this too. My original thinking
was that if an AD has neither UA's nor gateways, its simply not doing
anything. But, as you point out, this may just be a transient situation.
It was also pointed out to me that an AD may sort of just be a listener
- and normally run without gateways or UA's. Both of these are good
reasons. I've removed this text for the -03 draft.

> to use intra-domain - I'm just not comfy stating that now.

GLP is an inter-domain protocol. If it came across as being purely LS to
LS, that was not intentional, and I'll change the text around to reflect
this. What I was also trying to say, as you point out, is that you MAY
use it for intra-domain operation, if you like, but thats not required.

> LS, or can there be partial DB's and forwarded queries?

I'm not sure that either querying or redirection fall under the GLP.
They both seem to be part of the front-end. All GLP does is propagate
and aggregate gateway information "in the background". We're not
assuming that there's a complete database at each LS, since aggregation
and policy will cause partial and differing information to exist
everywhere. 

I'll add text about queries and redirections to the front end
description.

> better term, but maybe someone else does.

True, after any aggregation point it won't be a real gateway at all. How
about call routing object?

> to do it, great, but if not, go with a simple metric

Its not an all or nothing thing. We can specify the most common means,
and then add hooks for extensions or out of band means to get at the
information if something more complex is needed.

>  - don't think we need to specify aggregation rules as such

No, but theres a fundamental tradeoff between aggregation and richness
of information to be propagated. I simply don't know where the right
point of operation is. I'm not sure if we should try to establish
guidelines along these lines (like whats proposed), or simply leave it
to implementors to decide. 

>  - please don't get into QoS routing

I agree here. My proposal is that when an LS has multiple routes to some
number, it can always choose to propagate one over the other based on
some out of band information it has learned from other means, such as a
QoS routing protocol, or some kind of measurement system. 

> for Gateway Location Services"?

Thats fine by me. Other opinions?

 If so, then snappier names than
> and GW Registration Protocols?).

Also fine, but keep in mind we're not currently chartered to do these
protocols.

> which it should forward signaling messages destined for a particular PSTN

Agreed. Text updated.

> "gatekeeper or SIP server"

Fixed.

> acronym and stick with it)

Changed all references to GLP.

> restrictive (ie, get rid of 'the one').

Fixed.

> 5) Section 6.2.1: "it it" -> "when it"

Fixed.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: [email-masked]
URL: http://www.cs.columbia.edu/~jdrosen
---------
This message came from the IETF IPTEL Working Group Mailing List.

---

From: "Hussein F. Salama" <[email-masked]>
Date: Tue, 03 Nov 1998 13:40:07 -0800

> interspersed with your points.
....

> QoS routing protocol, or some kind of measurement system.

How about including this statement in the framework draft? The current
draft doesn't mention anywhere that an LS can do route selection. The
route selection algorithm may use the attributes advertised by the GLP
and/or out of band information. 

Hussein

-- 
Hussein F. Salama
Cisco Systems
Mail Stop SJC6-4, 170 W. Tasman Drive, San Jose, CA 95134
Voice: +1 (408) 527-7147, Fax: +1 (408) 526-4952
---------
This message came from the IETF IPTEL Working Group Mailing List.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 03 Nov 1998 18:35:22 -0500

Hussein F. Salama wrote:

> and/or out of band information.

I had folded this in with what I termed "LS policy":

\item Location Server Policy: The set of rules which dictate how a
location server processes information it receives via GLP. This
includes rules for aggregating, propagating, generating, and accepting
information.

I've made this more explicit now. 

-Jonathan R.