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

From: "Roy, Radhika R, ALCTA" <[email-masked]>
Date: Mon, 1 Oct 2001 17:36:14 -0400

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

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Mon, 01 Oct 2001 18:26:40 -0400

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

I don't understand this requirement.

> (Location/Route) Server and b. (Location/Route) Server <-> (Location/Route)

This depends on a particular model of the world; I don't think that's a
given.

> negotiations, alternate peers for back-up, capacity, policy, QOS)

Just like for routing, depending on the complexity trade-offs, that may
not be the right one. There is a reason, after all, that not everyone is
running OSPF when router discovery is all you need.

> gateways and servers. This may pose problems in managing the large networks.

I don't see the problem. SLP commonly deals with many clients that need
resource information and with many services.

> mechanisms for server to server communications.)

That is bogus. DAs can communicate with each other, if that's the
architecture selected.

> again for simple updates.

I don't know what you mean by selective updates. You mean for individual
prefixes? SLP has partial updates, if really needed. (Based on
experience, it seems to be deprecated and little used in practice.)
Supported or not, my suspicion is that the complexity is not worth it,
given the issues of synchronization of new "listeners". In general, at
least in SIP (and RSVP, for another example), we have made the choice of
providing complete state information, rather than incremental state. How
large do you anticipate advertisements to be? Inside a network, is the
bandwidth efficiency an issue?

> GW-SLP proposal, no protocol has been suggested for the server-to-server

Bogus. See above. You can do whatever aggregation you want, if that's
necessary. Clearly, the aggregated version has to be distinguished (it's
a different "service"), but I don't see the protocol problem.