Subject: [IPTEL] resend of minutes

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 29 Dec 2000 11:22:13 -0500

IPTel WG Meeting, IETF 49, Mon, 11 Dec 2000 09:00:00 PST

Chair: Jonathan Rosenberg <[email-masked]>
Notetakers: Jonathan Lennox <[email-masked]>
            Steven Donovan <[email-masked]>

Jonathan Rosenberg: Agenda
---------------------------

Agenda bashing [Rosenberg] 5 min
Working group update [Rosenberg] 5 mins
Service codes [Peterson] 15 mins
TRIP MIB [Walker] 15 mins
Intra-domain architecture [Rosenberg] 15 minutes
CPL Authorization [Kuthan] 15 mins
Working group future directions [rosenberg] 30 mins

Jonathan Rosenberg: WG update
-----------------------------

* CPL specification
  - draft -03 iesg last call made nov 17
  - under AD review now
  - interop testing done at last SIP bakeoff!
  - CPLs created by indigo tool sent and processed by dynamicsoft
interpreter
  - Round of applause for Jonathan Lennox's hard work on this one

* TRIP Specification
  - WG last call issued on draft -04 on Nov 29
  - Authentication stuff removed, since Hop-by-Hop using IPSec seems
    to work fine for us for now 
  - last call ends after IETF

Jon Peterson: The ServiceCode Attribute for TRIP
------------------------------------------------

Overview of ServiceCodes
* Add an attribute to propagated routes that characterizes the service
  offered by the originator
- Makes routes more specific
* Largely for intradomain use, but not exclusively

* Why use ServiceCodes?
- Feature interaction
- Differeniation of types of termination
- Operations & Management simplified
- Aggregation gains sophistication

Problem:

Two servers, one of which is an app server that provides some kind of
LNP service for the +17208883 prefix, and another which is a gateway
for +1720. Both use TRIP to propagate routes to these prefixes to the
proxy server. Now, when a call comes, which route is used by the
proxy? Its not necessarily longest prefix; it depends on the type of
service. For example, you want to apply LNP before routing, so you
would send to the app server first.

Jonathan R. then provided a clarification: implicit in TRIP model that
what's propagated is routes to one very specific service: gateway; but
we could route to lots of different things.  In picture: we have two
different things.  What happens when we add routes to more different
kinds of things?  That's the problem Jon's solving.

Jon commented that service codes were useful even for just gateways,
since there are lots of different types (ss7 gateways, analog, etc.).

Proposal: service codes -- in example, LNP for App Server, SS7
Termination for GW.  LS propagates both, doesn't aggregate them -- two
routes propagated

Operation problem: administrator can snoop TRIP packets and figure out
what's going on

ServiceCode assumptions:
* LS provisions call routing agents (PS) based on received routes
* Policy matrix in the LS could use SCs to determine precedence of
  received routes
* TRIP environemnt in which applications register dynamically (and
  sometimes compete with one another)

Examples of ServiceCodes
* PRI Termination
* Freephone Translation
* Conferencing

IANA Registration of ServiceCodes
* Maybe families of ServiceCodes
* Default -- Unspecified Termination
  - For backwads compatibility

James Kempf indicated that we should be sure to look at rfc2609, which
defines a syntax for services that we could use here, rather than
reinventing our own.

Jon then continued his presentation. He gave an example where an App
server has many applications, and has propogated routes associated
with all these apps to proxy server.  Today, proxy server has to make
decision as to what application to run on call. If it forwards the
request to the app server, how does it tell that app server which
application to run? Should we extend SIP to include ServiceCode in
INVITE?

Jonathan indicated that he didn't think this requires an extension to
SIP.  The App-components draft discusses these kinds of issues.
Request-URI in SIP points to a resource, resource can be anything.
URI is user@host; define conventions as to how you structure 'user'
part for services.

Jonathan also discussed SLP. He wants to make sure we're not
reinventing SLP.  He thinks we're solving a different problem, but the
group has to make sure we understand how it's different -- we should
write an I-D on this.  Even if they are different, they can work
together.

Jon discussed inter-domain usage. Service codes can be used between
ITADs to defined policies. For example,   ITAD2 wants to
block services related to unified messaging.

There were no further comments from the group. Jonathan indicated that
we will talk about what to do with this work towards the end of the
meeting. 

Dave Walker: TRIP MIB
---------------------

Dave Walker couldn't make it, so the MIB draft was presented by David
Zinman. 

Why a MIB?
* Not required in the charter...essential for management
* Completes the system view of a device

Based on RFC 1657, the BGP4 MIB, since TRIP is like BGP4.

What's in it?
* Configuration and statistics for local entity and peer table
* Default peer configuration
* A routing table containing adj-TRIB-ins from all peers
* A couple of Notifications

What it counts
* Peer updates
* Peer messages
* Peer FSM transitions

TRIP Peer Table Entry
Some object in the peer table
(List of attributes: see slide)

Routing Table Entry
Some objects in the routing entry are:
(List of objects: see slide)
Last is boolean: is this route the best chosen route?

ITAD Toplogy
ITAD Topology Table objects, Topology ID

To Do:
syncrhonize with TRIP -04 draft
compliance statements
notifications
trip for gateways
new attributes 
new address families
new protocol families
use rfc 2851 reference for internet addresses
etc.

David asked if we need a mailing list. Jonathan R. advised to keep on
the main list for now.

Jonathan indicated that a MIB not necessary for proposed standard, but
is necessary for draft; encourage the group to charter the group for a
MIB.  Doubt there'll be much controversy over this.

Jonathan R.: Intra-domain architecure
--------------------------------------

Jonathan discussed the meaning of "intra-domain architectures", which
has generated a fair amount of debate on the list.

He said we did inter-domain first; effectively solving the problems in
the reverse order of importance. Arguably intra-domain is more
important.  He proposed that we've already solved this problem too;
VoIP routing is different from Layer 3 routing in the intra-domain. In
IP, decision point is to find shortest path, only.  That's what Layer
3 routing is good at.  In VoIP, routes amongst proxies within a domain
are still dependent on policy.  This is the primary reason why we care
where packets go to.  If we just want shortest path routing, just use
layer 3 -- number of proxies is 0.  Use proxies for management &
policy of resources.  Not about least-cost routing.

Example Network: 1 ITAD -- Termination provider.  Terminates phone
numbers.  NY Pop, CA Pop. Each pop has gateways, some load balancing
proxies in front of them. The NY POP has another layer of proxies to
manage the many terminations in NY. THere are also customer facing
proxies. Calls from customers arrive there first, and are
authenticated. 

The ITAD policy is +1212 to NY, +1415 to CA, each backs up the other
in case of failure. If NY goes down, route through California.  But
shortest proxy-POP path to NY is through CA, since there is one less
layer of proxies there. This is wrong.  Could just set weights on the
routes, but this is horrendous to manage.  If I add a single proxy
server, could change entire weight structure.

Policy should be that customer-facing proxies determine how calls
should be routed to the POPs. Proxies in POPS determine which gateway
farms to forward calls to. Load balancing proxies in each farm figure
out which gateway to use. Effectively, each proxy determines routing
using data about its peers coupled with its local policy objectives.

Architectural model: Group of proxies within a domain look like their
own mini-domain! Makes sense to use trip for intra-mini-domains.

what needs to change in TRIP to support this?
- additional params and attributes
- gateway capacity, codecs, local preferences, etc.  These things were
eliminated from the inter-domain protocol; but they may make sense
within a domain. 

James Kempf commented -  maybe also SLP?  He argued that we need pull
technology to have more control over proxies?  Need input from Service
Providers as to how they want to build their networks. Jonathan argued
that here, a push model was more appropriate. This is because, unlike
normal SLP, the number of "clients" asking for resources from a
gateway or proxy is small and enumerable. This means you can establish
trust relationships ahead of time, and just exchange data over those
connections. Thus, its more like a push oriented routing protocol
than a pull oriented client-server query protocol.

Rohan Mahy wanted to clarify that when we leave the domain, we filter out
all
these intra-domain attributes. Jonathan said yes.

Open issue:
Is last hop from gateway to proxies that front it a push or pull
protocol?
* push:
 - faster
 - better for policy
 - security model makes more sense
 - ideal for point to point case
* Pull
 - good for large fan outs
 - allows gateways to be used by any type of client

Argument is "sort-of" SLP vs. TRIP. In this case, pre-arranged uses of
service, small number of clients, pre-arranged, long-lived
relationships.  More like TRIP than SLP - push rather than pull.  A
draft needs to be prepared on this subject.

Big picture: intra-domain looks like inter-domain.  Need to do
architectural model before designing protocol.

The question was asked about propagation of these new
attributes within a domain. Jonathan answered that we would have
recommendations, just as we do now for existing attributes.  But this
is a matter of local policy; let docments defining them give
recommendations, but leave it up to service providers.

The question was asked as to whether we should define intra-domain
aggregation?
Jonathan answered that TRIP already does this; define for each
attribute how it's aggregated.  TRIP is good at this.

If you have comments on TRIP, we're in WG last call.  Raise issues
now?  (None.)

Jiri Kuthan: CPL Extensions
---------------------------

* Authentication
* Access to external databases
* Next steps?

#1: Authentication support
* Need to make call processing dependent on authentication information
* Example: you may want to relay calls to your cell phone only if
  originated by those in possession of valid credentials
* Solution: add authentication switching to CPL

Example: <auth-switch>.  Don't insist on this syntax.

Current status:
* Consensus on:
  - Need for authentication switching
  - The need to abstract from speciic authentication mechanisms
* Unresolved issues:
  - On what information should be switched?
    o Resulting authentication satus
    o Authentication ID
    o Authentication mechanism class
  - Should we develop support for portable credential databases?
    o Useful to retain portability fo CPL scripts using authentcation
      switching.
    o If so, the consensus is to separate them from CPL scripts!

James Kempf suggested avoiding defining a portable credential
database.  Dependent on network you're using, different for different
protocols (IS-95, GSM).  Better to have abstract interface.

Jonathan indicated that it as not clear that carrying authentication
information and passwords is the domain of this group.  Security
people may already have solutions.  I think IS-95, GSM are lower
level, though.

Someone else commented that they didn't think there was any consensus
that this was required. 

Jonathan indicated that there's consensus not to carry credentials.
There's consensus that an authentication-switch is needed. However, he
commented that for end-users, switching on the authorization strength
(i.e., public vs. private key) are not useful, since end users won't
be able to make such determinations.  Whereas something like
authentication status is useful ("are they who they say they are?")
Perhaps realm?

Other issue: external, read-only, database access
* Want to check a header field against a potentially huge list of
  values maintaind by a third party
* Example: check From field against a list of well-known spam sources.

Alternatives
* Solution 1: Route the call through the site maintaining the
  anti-spam list
* Soltuion 2: Query the anti-spam list if a caller is on the list.
  - Better privacy -- the anti-spam site sees no signaling
  - Explicit support in CPL needed.

Difference is how much signalling you send to anti-spam site.

Status: no conclusion on the mailing list.

Next Steps:
* Authentication
 - Reach consensus on unresolved issues: (credentials, on what should
   be switched)
 - Generate syntax (switch, responses)
* ? External Database Access

Jonathan Rosenberg: Working Group future directions
---------------------------------------------------

All the drafts discussed today are not in the charter
Is there an A-D in the room?  (No.)

WG Future:
* Current chartered items are complete.  Not the fastest, but good --
  we finished.
* We need to shut down or re-charter
* What might we work on?
  - TRIP MIB (needed for draft)
  - Intra-domain architectures and protocol; gateway registration,
    service routing (taking TRIP beyond its current space)
  - CPL-NG -- extensions within its original problem space; extensions
    extending its scope (end systems, administrators).  Would first
    need requirements document.

Want to hear from people what problems we want to solve.  Want to hear
from people.  Vendors, service providers: what problems do you want
solved?

Proposal:
* do TRIP MIB.
* extend TRIP for intra-domain and service routing.  (Can't agree to
  do it now; need concrete charter and wording)

Hussein commented that he also wanted to charter a TRIP usage
guidelines document; how you'd use TRIP and configure policies. 

Jonathan clarified what such a document means (it had been discussed
amongst the TRIP authors). Today, using BGP is a black art.  Not
because of the protocol, but because of how you configure policies.
Not well documented in IP routing space (maybe on purpose?)  For TRIP,
how do I set up my policies?  E.g. there are prefixes that aren't in
use.  Concrete issue: we have a notion of multiple address families
(hexadecimal, pots).  INVITE comes: which table do you look at?
addresses overlap...adding more families too.  Have to be careful
about how you configure the proxy.  Well-understood, but not
documented in TRIP spec.  Proposal is to come up with guidelines for
this.  BCP or Informational.

Hal Boltz mentioned the issue of emergency communications.  TRIP could
play a role in supporting these kind of activities -- disaster
recovery from hurricanes, earthquakes.  Working Group being chartered
for this. Jonathan responded that any new WG should toss requirements
or usage recommendations "over the wall" to iptel for
discussion. Jonathan invited people in iptel to participate in the
ieps discussion, and asked if there was a list. Hal responded that
there was: www.iepscheme.net; ml and documents.

Jonathan then asked the group about CPL. Do we want to continue to evolve
CPL?
If we move additional work forward, do we first revisit the model
(admin, end systems)?

(Various threats to get people to talk)

Jiri Kuthan expressed an interest to address end devices.  Want to
port services between phones. 

Someone else from the mike commented that there's not much interest in
H.323 in CPL; is it worth focusing on SIP? Jonathan said that there
was an ITU liaison statement; there seems to be interest. Jonathan
asked if any ITU people were in the room to comment. Joerg said that
they're looking at this, but they can't give current status. 
Jonathan commented that its not ours to work on.  If people want to
bring 323 things forward, do so.

Rohan Mahy commented that right now CPL is for handling calls as they
arrive.  Want to make division between that and media termination
(voiceXML space). 

Jonathan responded that CPL lives in device like a SIP proxy server;
most services can be stateless.  Some must be transaction-stateful,
but none call-stateful.  This is nice. Examples of newer services that
live in this speace are presence-based routing. There are other devices that
you don't want to call a proxy server.  Application
servers, for example. These are usually call-stateful, and can hang up
call, etc, but still no media. Then there are media services.

Jonathan Lennox commented that perhaps CPL can hand off to VoiceXML;
inter-work them (maybe one XML document, maybe not).

Jonathan commented that moving towards media level processing was
treading on dangerous ground, in relation to other groups. The issue,
however, of the play between call control (ala CPL), and media control
(ala VoiceXML) was an important one, and a very big one, but much more
thinking needs to happen. Lots of folks working on that
space. VoiceXML has a bit of call control.  Lots of people interested
in doing more.  CPL is other extreme.  Interest in this problem.
However, monstrous can of worms; more a research issue.

Someone asked if CPL is a general services architecture? Jonathan said
no.  Explicitly narrowly focused.  See framework RFC.

Scott Bradner (AD) enters room.  Jonathan asks "What do you think about
working
group re-chartering?"

Scott: sign of success in IETF is that WG ends; no a prioriori reason to
continue.  That doesn't mean there's a prejudice against good ideas.

Jonathan responded that people are already working on next things;
question is if it should be in this group.  Could charter for specific
little things that people are currently doing; but could we charter
for additional groups of extensions?

Scott: Related process question: are these of sufficient magnitude to
require discussion at multiple IETFs, or is the ML sufficient?  ML can
continue even if don't meet at IETF.  (Meeting space is tight.)

Jonathan responded that authentication-switch could just be ML;
intra-domain and service are bigger; MIB is in middle (doesn't get
much discussion at meeting regardless).

Jonathan says he's not proposing a charter here; don't have one, and
need to discuss with ADs.

Jonathan then asked for hums on interest on working on various topics,
to gauge how to (or if) to formulate a new charter for iptel.

Issue                Hum volume
TRIP MIB             Hum.  (Very half-hearted hum.)

Scott commented that this is not a choice, need a MIB.  Don't
necessarily need a WG charter. 

intra-domain         good hum
  Waste of time?     No hum.

Service routing? 
(This is fantastically important!, says the chair in an unbiased way
:) )                 medium hum

CPL for end systems?  (Lower-level hums.)

CPL in servers, broaden scope?  (similarly low)

CPL for administrators?  (similarly low)

CPL media interaction (almost none.)

CPL MIB?  What does this mean?  Maybe CPL interpreter MIB?
Scott: IESG likes MIBs but we're not compulsive.  No Fortran MIB.

Jonathan said his take was the following: the group is interested in
taking TRIP to next level.  CPL a bit less interest, maybe doesn't
need to be chartered item. 

Meeting adjourned.

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

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