Subject: [IPTEL] minutes and slides from IETF 51

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 20 Aug 2001 16:52:37 -0400

Folks,

You can find a copy of the slides I presented at IETF 51 at:

http://www.jdrosen.net/papers/iptel_slides_51.ppt

Minutes for the meeting are below. Thanks to Mary Barnes for taking notes.
If there are any corrections, please let me know by the end of this week.

Thanks,
Jonathan R.

-------------
Minutes of the IP Telephony (iptel) Working Group
IETF 51
Minutes taken by: Mary Barnes
Minutes prepared by: Jonathan Rosenberg

The IP telephony (iptel) group met for a single, one hour session at
IETF 51. The proposed agenda was:

Agenda Bashing				5m
CPL and TRIP Status			5m
Charter Review				10m
TRIP for GW				10m

The agenda was agreed upon.

First up was a status update on TRIP and CPL. CPL is still blocked on
calsch issues. Scott Bradner indicated that he is hoping to get this
resolved finally. TRIP has been going through the IESG, with minor
comments getting incorporated. Scott indicated that IESG has, in fact,
approved TRIP for RFC.

The new charter is presented. There are two items, a TRIP MIB, due in
September 01, and "TRIP for gateways", also known as "TRIP-lite", due
to IESG Jan 02.

Next, is a discussion on the changes to the gateway registration draft since
the last iteration. These changes are:

*  Explicit requirements defined
*  Comparison with existing protocols
*  Inclusion of open issues
*  Removed DSP Capacity

DSP capacity was removed because its not clear how to use it, and can
be factored into the circuit capacity attribute. Concerns are raised
about its removal. Dave Oran made some arguments that the meaning of
the parameter wasn't important, so long as its statistics had specific
value. The chair indicated that unless it was well documented and
described, it would result in vendor tie-in between gateway and
proxy. Dave agreed to provide some more detailed definitions.

Next up, we discuss the requirements for the trip for gateways
protocol, in general terms:

1.	Fast call setup 
2.	Conveys failures of gateways rapidly
3.	Conveys restarts of gateways rapidly
4.	Proxy has some way to know available capacity
5.	Security: mutual authentication and integrity.  Privacy less
critical.
6.	Convey routing preferences
7.	Timeliness of attribute information
8.	Extensible attributes
9.	Efficient
10.	Centralization of policy  (Proxy server in front of the
gateways ultimately makes the decision on how the call is routed) 
11.	Proxies in ITAD make independent policy decisions.

Henning objects to requirement 5, stating that mutual authentication
isn't needed. He claims its at odds with privacy. The reason is that
Henning has a somewhat different model in mind. He is interested in an
enterprise problem, where a proxy dynamically discovers the gateways
it can route calls to. As such, mutual auth is a pain since its more
of an advertisement protocol. As such, Henning wants to add
auto-configuration as a requirement. Jonathan argues that this complicates
policy, since its hard to define policy over managing gateways that
you only later discover. Henning argues that this is not true - since
the gateways may go up or crash, there is already a need for policy
which handles the case where the number of gateways varies.

Next, Jonathan asks whether auto-discovery a requirement or not?
Some argue that this is needed anyway for scalability and
reliability. Dave asks who is discovering who? Are gateways
discovering proxies, or the other way around? There is some debate
about this.  Jonathan proposes that we make autodiscovery
orthogonal to TRIP - i.e., discover it somehow, then use TRIP-lite
between them. Henning objects to that also, since he doesn't want
three protocols where one will do. He indicates that the question is
whether existing protocols meet all of the requirements or not. Jon
Peterson asks about whether we are talking about auto-configuration or
auto-discovery - ie., are RIBs generated automatically from the
combination of policy + TRIBs? Jonathan indicates that this is not what we
are
talking about, and that this is an interesting question but for later
work.

The consensus of the room is that auto-discovery is not a bad thing,
but still not clear its needed.

Next, Jonathan presents the analysis of existing solutions. The focus
is on SLP, and he argues that there are two cases. In case 1, the
gateway is an SLP SA, and the proxy is a DA. In case 2, the gateway is
an SLP SA, and the proxy is a UA (there is no DA). Jonathan argues
that case 2 is bad, since it introduces delay and makes centralization
of policy hard. Henning argues that the UA can cache the service
replies. The reply is that service announcements had lifetimes, not
the service replies. He said that no, the service replies can remain
active without requerying. Jonathan argued that this is basically
approach 1, which makes more sense.

Rohan Mahy expresses concern about a terminology problem. Is a proxy
the same as LS in these discussions? The answer is yes, and that
Jonathan has been lazy with terminology. The proxy = the LS that is
managing the gateways.

Henning argues that the intra-domain problem is much different than
inter-domain, and that something like SLP is more appropriate
intra-domain. SLP is done already, and does autodiscovery and
propagation of attributes. Its also simpler, since TRIP is a very
complex protocol. Jonathan asks what aspects of TRIP are more than you need,
and would not be present in an SLP protocol. Henning responds that you
don't need the transition of information into an inter-domain
protocol, since there may not be one running. Jonathan argues that this is
not
a technical objection per se, since there is no cost to that aspect of
TRIP. The question is: if you use TRIP instead of SLP, what features
do you need to implement that otherwise wouldn't be needed (i.e., are
there because of the "legacy" TRIP usage). It wasn't clear what those
things were. Jonathan argued with Henning that both TRIP and SLP "exist", so
arguing about using an "existing" protocol is moot in this case. 

In order to move forward, the chair imposes the following decision:

1. we will have an open call for concrete, written up proposals in
Internet Drafts form, which must be received by September 7 (one month
from the meeting date). If there are no concrete proposals for SLP or
anything else, we will move forward with the current proposal. We have
tight deadlines and they need to be met. The proposals must outline
concrete things in the current proposal which are not needed, but must
be implemented because of "legacy" usage. Only concrete technical
statements will be accepted. Things like "too complex" or "won't
scale" are not acceptable.

2. requirements are critical for evaluation of the proposals. Please
contribute requirements to the list for discussion.

With that, the meeting closes.

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