Subject: RE: [IPTEL] the silence is deafening...

From: "Anderson, Darby" <[email-masked]>
Date: Mon, 1 Oct 2001 15:12:21 -0700

First of all, my appologies to thoose of whom that receive plural copies of
this...

I dont know if this is the place to stand at the fence with the boys
comparing toys, and features of Johhny's,Joe's, and Suzy's cars, BUT...

hypothetically IF I were a internet telephony service provider, I think I'd
have to side with Roy's twist on the scenario, due to the updating
mechanisms (Multicast UDP), in addition to the flexability of Voice G/W ~~>
LocServ ~~> RouteServ (Softswitch?), as some carriers may wish to have
selective avilability of their resources internally on their network, vs.
externally to other networks (Thus easing the burden on security, and/or
accounting aspects of their networks)

really the only items I see that are currently unnessary are thoose having
to due with URL's, but maybe Im missing part of the big picture somewhere?

I suppose my only concerns as of present are:
1. Would this twist still be TRIP?
2. If so, would this add much more developement time for the devlopement of
this protocol?
3. In reguards to Section A, Subsection 5, does this make provisions for
redundancy/diversity of all network elements? (I.E.
G/W's,LocServ,RouteServ,Etc.)
"A server will also be able to aggregate the address information for
scalability and efficiency and may be able to send the same to all other
servers."

-----Original Message-----
From: Roy, Radhika R, ALCTA [mailto:[email-masked]]
Sent: Monday, October 01, 2001 3:36 PM
To: Henning G. Schulzrinne; Jonathan Rosenberg
Cc: [email-masked]'
Subject: RE: [IPTEL] the silence is deafening...

Per Henning's suggestions, I am adding the following . . .

The common properties that all intra-ITAD (intra-domain) proposals need to
have:

1. A single protocol

2. Gateways can be Telephony (e.g., E.164) GWs and/or SIP-H.323 GWs (E.164,
Email IDs, URL IDs)

3. Communication environments for address resolutions: a. GWs <->
(Location/Route) Server and b. (Location/Route) Server <-> (Location/Route)
Server

4. Functionalities of the protocol needed: Discovery, Registration,
Confirmation (and Selective Updates of addresses, and Keep-Alive messages,
and Error-Notifications for efficiency reason).

5. Scalability of the protocol (e.g., Multicasting using connectionless
transport [e.g., UDP])

6. Possible Extensions for Value-added features (e.g., capability
negotiations, alternate peers for back-up, capacity, policy, QOS)

In short, the alternate proposals that we have can be described as follows:

A. ITRP (R. Roy)

1. The proposed ITRP protocol satisfies the above properties. ITRP has also
the properties what TRIP-GW or GW-SLP proposal also does. Briefly, it
appears that both TRIP-GW and GW-SLP proposal may require more than one
protocol to satisfy the needs  while a single ITRP protocol will be able to
do the same.

2. It has the capability for Discovery, Registration, Confirmation,
Selective Updates of addresses, Keep-Alive messages, and
Error-Notifications. The communication can be: a. GWs <-> (Location/Route)
Server and b. (Location/Route) Server <-> (Location/Route) Server.

3. It has the ability to restrict the communications among the gateways and
servers as needed: a. Many-to-One, b. One-to-Many, (and c. Many-to-Many).

4. Both UDP and TCP transport can be used as needed. Unlike TRIP-GW, it can
use multicasting using for updates among the servers.

5. A server will also be able to aggregate the address information for
scalability and efficiency and may be able to send the same to all other
servers.

6. Value-added features like capability negotiations, alternate peers for
back-up, capacity, etc. can be used.

7. The address resolutions can be provided for Telephony (e.g., E.164) GWs
and/or SIP-H.323 GWs (E.164, Email IDs, URL IDs).

8. The proposed message formats of ITRP are similar to those of TRIP.

B. TRIP-GW (J. Rosenberg, et al)

1. The TRIP-GW proposal needs another protocol for discovery of the
gateways. Moreover, connectionless transport (e.g., UDP) is efficient for
discovery protocols between the gateways and the servers (but it uses
connection-oriented TCP protocol).

2. For servers to server communications, this protocol uses
connection-oriented TCP transport protocol. When selective updates are made
by the gateways to the any server, the said server uses flooding (or limited
broadcast) to update that information among all other servers, instead of
using more efficient multicasting (over the UDP transport for example). 

3. TRIP-GW message sets are inherently complex because it has been designed
to solve more complex problems like route aggregation and route propagation,
which are not needed for the intra-ITAD communications.

4. In addition to Telephony numbers, we need to provide address resolutions
for Email Ids, URL Ids, etc. as well. These items are yet to address by the
TRIP-GW.

C. GW-SLP (W. Zhao, et al)

1. The GW-SLP proposal extends the SLP protocol for discovery and
registration, but there exists a many-to-many relationship between the
gateways and servers. This may pose problems in managing the large networks.
In ITRP proposal, it can be restricted such that a set of GWs can be
communicating only with a single server.

2. The GW-SLP proposal does not specify communications among the servers
and, GWs are required to communicate with all servers using multicasting if
multiple servers are deployed. That is, a new protocol may be needed if the
server-to-server communications are required. (Both ITRP and GW-TRIP provide
mechanisms for server to server communications.)

3. No mechanism is defined in the GW-SLP proposal if selective updates are
needed because it is not efficient to send the register message again and
again for simple updates.

4. A server may also need to aggregate the address information and may
require to send the same to all other servers and, there is a need for
communication among the servers (as suggested in ITRP and TRIP-GW). In
GW-SLP proposal, no protocol has been suggested for the server-to-server
communications.

The above note provides a brief summary of all proposals. 

Comments will be appreciated.

Best regards,

Radhika R. Roy
[email-masked]

-----Original Message-----
From: Henning G. Schulzrinne [mailto:[email-masked]]
Sent: Monday, October 01, 2001 2:39 PM
To: Jonathan Rosenberg
Cc: [email-masked]'
Subject: Re: [IPTEL] the silence is deafening...

I'll bite :-)

One question is whether we need one solution or whether different
solutions have different applications and trade-offs. After all, we have
RIPv2, OSPF, IS-IS and some vendor-proprietary protocols (as well as
simpler router discovery and advertisement via ICMP, IGMP and DHCP) as
interior/intra-domain routing protocols and BGPv4 as
exterior/inter-domain.

Also, as with routing protocols, availability of broadcast/multicast
plays a role here. I would like to be able to optimize efficiency (or
reduce complexity) if multicast is available. As one real-life example I
happen to be familiar with, Internet2 is multicast-enabled and is
looking at how to distribute gateway information in the future.

Also, the complexity of standardizing these things differ. In some
cases, it's a new protocol, in others a profile, in the third mainly a
new data structure (template).

It might be helpful if the proponents/authors of each proposal could
abstract their proposal into a common set of properties, of which I
suggested a few above. (I'm sure there are many others I missed.) This
will tell us if the proposals are different mainly because they make
different assumptions on infrastructure and usage, and thus likely will
be complementary, or whether they are solving the same problem in the
same space.

From what I can tell, the number of parameters for each gateway appears
to be fairly small, so that translation between the schemes or to an
exterior scheme is reasonably simple. It is also not clear to me that
just blindly "exporting" the information wholesale to an inter-domain
scheme is desirable. If you consider the Internet2 example above, while
universities might make their facilities available in a
"peering"/mutual-aid fashion (no pay) to other universities, they may
have much more restrictive policies as to who gets to see what once it
leaves Internet2.

Jonathan Rosenberg wrote:
> 
> Folks,
> 
> Its been about 3 weeks since our call for proposals for "gateway
> registration" drafts ended. We actually have THREE proposals on the table:
> 
>
http://search.ietf.org/internet-drafts/draft-roy-iptel-gw-server-discovery-0
> 0.txt
> http://search.ietf.org/internet-drafts/draft-roy-iptel-itrp-00.txt
> 
> http://search.ietf.org/internet-drafts/draft-rs-trip-gw-02.txt
> 
> http://search.ietf.org/internet-drafts/draft-zhao-iptel-gwloc-slp-01.txt
> 
> However, there has not been a single email post on this list with comments
> or questions. I'm not sure how to interpret that. Perhaps people are just
> busy (always true), or perhaps this is not important enough for anyone to
> take the time to focus on. However, if it is something that people do not
> feel is important enough to focus on, to the extent that they are willing
to
> post comments or push their proposals, then I could only conclude that it
is
> not something interesting enough to keep on the charter. I would be
> perfectly happy to finish the MIB and close down the group; I certainly
have
> plenty of other things to do. So, please do comment on these, and make
your
> opinions known. If there is no discussion within another two weeks, I will
> consider this consensus to remove the item from the charter and begin the
> process to make that happen.
> 

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

_______________________________________________
IPTEL mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/iptel

_______________________________________________
IPTEL mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/iptel

_______________________________________________
IPTEL mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/iptel

---

From: "Roy, Radhika R, ALCTA" <[email-masked]>
Date: Tue, 2 Oct 2001 10:27:25 -0400

My response provided below [RRR]:

-----Original Message-----
From: Jean-Francois Mule [mailto:[email-masked]]

I will bark ;)

 - in draft-roy-iptel-gw-server-discovery-00.txt, it is proposed to
advertize the Entity Type.  There was a very similar proposal some
vendors to extend OSPv2+ with similar information and the consensus was
that unless this information is very detailed (including registered
protocol name(s), versions, profiles, ...), it is useless.  There is
also an implied requirement that by knowing this, some proxies may do
some sort of capability negotiation.

[RRR] GWs and servers are different entities. So, the entity type is coming
from this perspective. If people want to differentiate among the GWs like
telephony GWs, SIP-H.323 GWs, it is also possible. We can see why version,
protocol name, etc. are not needed. These have NOT been proposed for
capability negotiations. Definitely, we can discuss these items, if there
are some concerns. The capability negotiation has been proposed whether
send-only, receive-only, or send-receive-mode (like TRIP-GW), not for others
that you have indicated.

- draft-roy-iptel-itrp-00.txt: and why not TRIP or TRIP-gw? to me, this
proposal does not stand as it could well be based on an existing
protocol.

[RRR] TRIP-GW does not have the discovery mechanisms. Another protocol is
needed to do this. In addition, the base TRIP-GW protocol uses TCP as the
transport and flooding (or limited broadcast) for sending information among
the servers. Both UDP and TCP can be used in ITRP. Efficient multicasting
can be used in ITRP. TRIP-GW's message structure are relatively complex and
has not been proposed to deal with email IDs, URL IDs, etc, other than
telephony GWs.

Jean-Francois.

---

From: "Roy, Radhika R, ALCTA" <[email-masked]>
Date: Tue, 2 Oct 2001 10:48:56 -0400

My responses provided below [RRR]:

-----Original Message-----
From: Henning G. Schulzrinne [mailto:[email-masked]]
Sent: Tuesday, October 02, 2001 10:29 AM
> some sort of capability negotiation.

Plus, you're now re-inventing SLP one step at a time. If you want to
advertise properties for general servers, I would like to know why this
shouldn't be used for, say, printers or other network services. (This is
not meant as a rhetorical question.) What makes a SIP-H.323 translator
different from other complex network services?

[RRR] Yes, SLP is  an excellent protocol for discovery and registration. The
above proposal is similar to SLP from discovery point of view, but has
additional features. The mechanisms like discovery, registration, selective
updates, keep-alive, confirmation, and error notifications have created a
complete protocol (termed as ITRP) to meet the requirements (e.g.,
many-to-one, one-to-many, reliability, etc.). You are right that it is
better if we could use the existing one to meet our purpose. We are just in
the middle of this important discussion. You have already has sent another
mail outlining the communications model. We will start from there.

What makes a SIP-H.323 translator different from other complex network
services?

[RRR] For SLP, it does not matter. (For, TRIP-GW proposal, it needs to
accommodate SIP-H.323 GW addresses.) ITRP also accommodates SIP-H.323 GW
addresses.
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: "Roy, Radhika R, ALCTA" <[email-masked]>
Date: Tue, 2 Oct 2001 12:31:21 -0400

-----Original Message-----

"Roy, Radhika R, ALCTA" wrote:

> 
> [RRR] For example, there are GWs and servers. The communications scenarios
> are GW <-> Server and Server <-> Server. In all scenarios, it is better to
> use the same protocol.

Since you don't say what you mean by "server", I can't understand this
requirement. See my last note on architecture. Also, just stating "it is
better" is not particularly helpful.

[RRR] I will relate this in your earlier architectural note in a separate
mail. [Servers can be LSs or PRs (or UAs). From your architectural point of
view, for GW <-> server, L is located to GWs. In Server <-> Server,
aggregation is done and L can be located to the Server. So, my point has
been that the same protocol (may be the same L or L*) needs to be used.]

> [RRR] A large network will consist of many GWs and servers. Therefore, it
is
> reasonable to have this kind of scenarios. Otherwise, it may be difficult
to
> manage the large network. For example, if there are many-to-many
> communications relationship with every GW is communicating with every
> server, it will complicate the process in managing the network. More over,
> the needs for communications among the servers are not the same as of
> communications among the GWs and server.

Again, you state your assumptions as facts. This is not very helpful.

[RRR] The above clarifications may answer this.

> [RRR] These are value-added features and will definitely increase the
> complexity. However, the protocol may need to be flexible enough to
> accommodate these if needed. For example, reliability is an important one
to
> have the back-up functional element. Therefore, a flexible protocol is
> always useful.
> 

We all agree, in the abstract, that reliability and flexibility are
good, but I don't understand how this applies here. Just as a "for
instance", SLP supports redundancy for SAs, DAs and UAs, in various
meanings of the word redundancy. I'd be surprised if TRIPlite couldn't
do something similar.

[RRR] Good. 

> 
> [RRR] The efficient communication scenarios are, as stated above, GW <->
> Sever, and Sever <-> Server. So, the many-to-one and one-to-many seem to
be
> better as opposed to many-to-many scenarios. It may be noted that
discovery
> and registration are not the only requirements. The selective updates,
> keep-alive, etc. are also needed.

Again, you state your assumptions as facts. Selective updates (by which
I assume you mean partial updates of some properties of a gateway) is
only useful if the volume of per-entity information is so high that a
complete update is not feasible. Absent of that, partial updates are not
desirable.

[RRR] Yes, you are right in describing the definition of selective updates.
The telephone numbers, email IDs, URL IDs, etc. are also considered
together. So, there may be a good number of entries (and updates).

I have no idea why you believe that SLP doesn't support many-to-one or
one-to-many scenarios.

[RRR] Good. The GW-SLP extension proposal assumes many-to-many scenarios. As
I explained before, if we consider SA <-> DA and DA <-> DA model together
where aggregation and selective updates are also considered.

As I said before, SLP supports partial updates, if you really want them.
(I don't see the need in this case, but maybe you can show why each
update has tens of kilobytes of information.)

[RRR] We cannot exclude this need right away because telephone numbers,
email IDs, URL IDs, etc. will be considered together.

> 
> [RRR] Are you suggesting DAs will be using to perform selective updates,
> keep-alive and others extending the SLP protocol?

I realize that this is a different WG, but we have been working with the
SLP WG on DA replication for about (I'm guessing) a year. This requires
only very modest changes to SLP DAs, and none to SAs or UAs. See
http://www.ietf.org/internet-drafts/draft-zhao-slp-da-interaction-10.txt

[RRR] Certainly, I will look into it. (It would have been better if this
reference could be provided in the earlier GW-SLP draft.)

> [RRR] The selective updates are very efficient. For example, many GWs will
> be communicating to a single server. A GW may deal with 100s, 1000s of
> addresses. If all GWs send their only the updated addresses, a sever only
> needs to send only those updated addresses to all other servers. In this
> way, there is an efficiency in communications.

I'm sorry, I just don't see how a gateway advertises 1000s of addresses
one at a time. Are you going to advertise each area code in the world
separately? Just like in TRIP, I would imagine that you do
longest-prefix-matching if you need to carve out special cases.

Realistically, I see gateways advertising the list of (maybe 30?)
7-digit prefixes (1212854, etc.) that are within local calling range,
maybe some regional calls and then a few dozen different international
groups, based on price similarity. But this assumes that the
advertisement includes cost; otherwise, the number of prefixes is much,
much smaller as they all look the same.

We seem to have very different views of how gateways work. Can you
explain your view?

[RRR] As mentioned above, telephone numbers, email IDs, URL IDs, etc. may
also be considered together.

> 
> [RRR] Will we be able to accommodate all requirements extending the SLP
> protocol?

Once the architecture(s) and requirements are clear, we can make
progress towards answering this, not just for SLP.

[RRR] Agreed.

---

From: "Roy, Radhika R, ALCTA" <[email-masked]>
Date: Tue, 2 Oct 2001 13:47:25 -0400

Hi, Bob:

Thanks for comments. Please see my comments provided below [RRR]:

-----Original Message-----
From: Bob Penfield [mailto:[email-masked]]
Sent: Tuesday, October 02, 2001 1:04 PM
> From: Anderson, Darby [mailto:[email-masked]]
>
> [RRR] No, it is not TRIP although the message formats will be similar to
> TRIP.

You seem to be contradicting yourself. You want to use a single protocol,
yet you claim TRIP is not appropriate. It seems to me that all of the
routing information you are sharing with ITRP is nearly identical to that
shared with TRIP, it just has a few extra atributes. Why can't we extend
TRIP to support the additional attributes and the discovery mechanism
needed. Or maybe use a separate discovery mechanism (maybe SLP). The SIP
spec describes a way to find SIP servers that does not use SIP.

[RRR] You could (technically) if you would change the TRIP protocol
architecture. For example, all ITRP protocol properties can be used as a
subset of TRIP (or special case of TRIP). The properties of ITRP have been
mentioned in my earlier email (e.g., discovery, registration, use of UDP
transport, email IDs, URL IDs, etc. are needed in TRIP). The heavy-weight
part of TRIP will not be used for intra-domain communications. It is just a
name change. In this way, we are in full agreement. I guess that this would
be the best way to solve problem. If we all agree,  I would vote to work
along this line. (The another reason is that if we would modify SLP to
accommodate the requirements, why can we not modify TRIP to do the same?)

Once the routing information goes over the wall from the ITRP or SLP side to
the TRIP side, it (at least some of it) is going to flooded to all the TRIP
speakers in the ITAD. This seems to go against REQ 9.

[RRR] You are right as I said above. However, we want TRIP should use UDP
(not TCP-based flooding or limited broadcast - in inter-domain it makes
sense where pre-provisioning [not automatic discovery] of the location
servers is done in multi-carrier environment and, routes are propagated
among the Location Servers [no GW information is transferred, rather is
hidden behind the location server] - it is a different scenario - not
applicable in intra-domain case). Another observation is that you can be
almost sure that all discovery protocols need to UDP for multicasting. So,
the support of UDP (or connectionless transport) almost becomes a indirect
requirement.

I find SLP bit more appealing than ITRP, but I have trouble with the need
for every gateway to communicate with every routing server in the ITAD. This
may be OK if there are just a few.

[RRR] Like you, I also thought that SLP could be useful, but its
many-to-many communications environment scared me so much that I was worried
how we can build a usable large-scale network that can be managed
meaningfully. Moreover, we may also add more things in the future for intra-
and inter-domain protocol. In the end, we may face troubles to extend the
SLP to meet our requirements. So, I have proposed ITRP (but I am willing to
make it a subset of TRIP if we can extend TRIP as proposed). However, I am
also open to see how far we can extend SLP to meet all requirements. Like
you, I also like to have the best solution considering all alternatives.

> [RRR] Any protocol that will be used for intra-domain communications will
> have some new features.
>
I guess I have a problem with having to implement two different protocol to
communicate virtually the same information.

[RRR] I agree, but we need to meet the requirements of the intra-domain
communications. The above suggestion of mine shows that we can also use
"TRIP" if we could agree to accommodate those requirements as I explained
earlier.

> [RRR] If one likes to provision the GW or server to improve reliability,
the
> protocol will have the provision like this.
>
>
>