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

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 1 Oct 2001 13:48:14 -0400

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.

-Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

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

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Mon, 01 Oct 2001 14:38:55 -0400

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.

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

---

From: Jean-Francois Mule <[email-masked]>
Date: Mon, 1 Oct 2001 21:49:53 -0700

I will bark ;)

without having reviewed the proposals in great details, here are some
quick practical comments in no particular order:
 - in draft-rs-trip-gw-02.txt, REQ 6, I definitely agree that the proxy
or RS will be centrally programmed with the route/cost(s) information
and that it is a bad idea to configure the gateways with this.  For
e.g., applications where route/cost params depend on time of day

 - in draft-rs-trip-gw-02.txt, REQ 8, why is it stated that (may be)
!REQ6 => !REQ8 !! I believe that extensible attributes are necessary and
they can indeed be characteristics of either the gateway (a gateway
identifier or some info about gateway groupings used to span virtual
gateways across multiple physical gateways or trunks), the gateway
trunks (1 physical gateway with several trunks going to multiple service
providers for redundancy or cost routing), or the routes themselves.

 - in draft-rs-trip-gw-02.txt, i believe it would be useful to have a
means for the proxy to specify the thresholds the gateway should use to
report on "out of capacity", "capacity available".  In some conservative
networks, you may not want to load your gateways more than 80% of its
capacity to share the load but in traffic peaks, you may want to change
it to 98% for example so having the proxy centrally dictate this
parameter could be very useful.  Not sure how to express that in
trip-gw.

 - in draft-zhao-iptel-gwloc-slp-01.txt, it is proposed that "the
location server needs to know the capacity of each gateway." in
draft-rs-trip-gw-02.txt, i see a slightly different requirement in REQ4.
While some vendors would probably like to know the total gateway
capacity or how many ds0s are being managed in a network (for licensing
for e.g.), I do not believe this is a mandatory requirement.  Worse,
there is a potential implied requirements for some proxies to count the
number of calls ingressed from/egressed to each gateway which is not
ALWAYS practical. I would rather prefer a model where the gateway
announces that it is in service (and optionally, its capacity) and then
reports when it is out-of-resources or reaching its max capacity based
on 2 thresholds dictated by the proxy.

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

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

Jean-Francois.

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Jonathan
> Rosenberg
> Sent: Monday, October 01, 2001 10:48 AM
> To: [email-masked]'
> Subject: [IPTEL] the silence is deafening...
>
>
> Folks,
>

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Tue, 02 Oct 2001 10:20:14 -0400

> I will bark ;)

I changed the subject to more closely reflect the topic at hand.

I think part of the issue is that we seem to have somewhat divergent
pictures of how deployment in a network might look like, and what kind
of boxes provides what kind of information to whom. I suspect, once you
strip away the labels, that each proposal can fit a variety of models,
but that each proposal has a particular model in mind.

I'm trying to paint a somewhat more differentiated picture than Fig. 1
in draft-rs-trip-gw-02.

At the most fine-grained decomposition, we seem to have:

===

(UA) a SIP server that handles all calls for a set of (G)

(G) a physical PSTN gateway, with DS-0s and kin coming out the back

(L) announces gateway properties to other entities, not necessarily just
Ls, but also other Ps, both within the same LAN, say, and further
afield. (In my Internet2 example, it would announce nationwide, to maybe
a hundred other sites.) Depending on the protocol and the architecture
chosen ("push" or "pull", for example), (L) can be different entities;
for example, in SLP, a SA or DA.

====

(P) a SIP proxy server that serves a whole domain, and presumably
multiple G/UA combinations. It might also listen to (L) announcements.

(P) is, in my view, optional, i.e., I should be able to run a system
where I only have a UA+G.

I believe that this architecture or decomposition is not arbitrary since
it reflects the possible SIP (and, roughly, H.323) boxes that exist
today.

As usual, (UA) and its set of (G) can either be in the same box (no
protocol between them) or they can be separated by an
MGCP/Megaco/proprietary wire. As far as I can tell, each (G) in this
model must "belong" to one UA, but I'm not sure on this point. (Clearly
true for G+UA in one box, but MGCP/Megaco/proprietary cases are less
clear to me.)

More interestingly, (L) could be located on (P), (UA) or (G), depending
on who knows what. With aggregation, you could even have combinations in
the same IAD, as in "L on G announces to local L*, which has policy
information and forwards to other L*'s further afield."

In simple cases, it makes sense to have the UA+G+L all in one box, with
all policy configuration and complete state knowledge. Imagine some sort
of distributed gateway in DSL-equipped homes, with one phone line each,
for example.

I don't think there is a right or wrong architecture at this level, but
each protocol should state which of these models it sees itself fitting
into.

Also, as Jean-Francois states, we need some clarity as to naming model:

- prefixes ("I can dial 212, 908, 201 and have a total of N circuits")
- trunks ("I have a trunk with 24 circuits")

or whatever. I suspect that all protocols can be adjusted to fit these
naming models, but it would be nice if we could agree on the model.

Henning

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Tue, 02 Oct 2001 10:29:28 -0400

Jean-Francois Mule wrote:

> on 2 thresholds dictated by the proxy.

Yes, any parameter should be optional; we'll clarify. I also agree that
both total capacity and current remaining capacity (or, inversely,
circuits already tied up) are needed.
 
As I said in my other message, I don't see the need for a SIP proxy in
all cases, so I'm a little confused by your statement in the second half
of the paragraph.

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

VoIP has a tendency, I think, to only look at their narrow niche,
without considering whether a particular problem is shared across
domains. If we have new problems that can't be solved by existing
protocols, we should check whether our solution is generalizable at
modest cost and thus serve a broader audience. This avoids having to
implement hundreds of protocols, given that most VoIP implementations
will need to support all the existing Internet protocols for other
services. This also ensures that other people look at this and say "we
looked at this when we designed <similar protocol X> and found it didn't
work", just like Jean-Francois inference above.