Subject: IPTEL meeting time

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 25 Nov 1998 11:49:32 -0500

Folks,

I have just received word about the time of our slot at IETF:

> This is to confirm one session for IPTEL as follows:
> 
>         Thursday, December 10 at 1530-1730
>                 other groups scheduled at that time: conneg, ipngwg, newsnmp, manet
>                         sigtran

I had asked not to conflict with sigtran, but scheduling is tight as
always and it couldn't be avoided.

I'll need to submit an agenda soon. The current outlook is:

Agenda for Iptel meeting in Orlando:

1. Agenda Bashing [5 mins, J. Rosenberg]
2. Open Issues in GLP framework [J. Rosenberg]
3. Location of Local Gateways [5 mins,L. Slutsman]
4. PGRP and GLP [R. Davis]
5. CPL Framework Issues [J. Lennox]
6. IN call models and the CPL [J. Voelker]

If you're not here, and would like to speak, please contact me asap.

Some of the above presentations are based on some drafts that have been
submitted recently, in particular the PGRP and IN call models are both
associated with drafts:

http://www.ietf.org/internet-drafts/draft-ietf-iptel-pgrp-framework-00.txt
http://www.cs.columbia.edu/~jdrosen/papers/draft-ietf-iptel-in-00.txt

I'd really like to see some discussion on these before the meeting. The
purpose of the meeting is *not* to present drafts in a tutorial fashion,
but rather to discuss issues raised by the draft.

So, I have the following questions, to start things off:

1. For the IN call models document, is it a requirement for the CPL to
operate that there be an underlying call model, visible to the CPL? If
so, need it or should it be the BCSM standardized in the IN
specifications?

2. For PGRP; PGRP is positioned as an intra-domain protocol, which is
not within the scope of our efforts at the moment. However, portions of
it are applicable to inter-domain location, in particular parts of the
initialization and keepalives. What parts are relevant to GLP? Should
PGRP be the starting point for specification of our protocol?

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: [email-masked]
URL: http://www.cs.columbia.edu/~jdrosen
---------
This message came from the IETF IPTEL Working Group Mailing List.

---

From: "ronald h. davis" <[email-masked]>
Date: Mon, 30 Nov 1998 12:42:27 -0600

> PGRP be the starting point for specification of our protocol?

i think that keepalives should *definitely* be a part of the glp.

here are some of my ideas as to how the two might fit together.  as
i see it, a given location server gets information from 3 sources:
	i)  information advertised from other location
	    servers about gateways in other domains.
	    this is equivalent to the rib-in information
	    described in bgp-4.
	ii) information about the local domain received
	    from an interior gateway protocol (such as
	    rip, or ospf).  this is equivalent to rib-local.
	    this local information is to also include a
	    transformation (by the local location server)
	    of information received from other location
	    servers.  in this way the local location server
	    decides how it wants represent external
	    information within the domain.
	iii)information advertised to other location servers.
	    this is equivalent to rib-out.  this information
	    is a transformation of information received in
	    i) and ii) in which the location server decides
	    which information is to be (and how information
	    is to be) presented to other location servers.

i don't see the glp as specifically defining the polices and 
transformations which produce i), ii), and iii) which are specific
to individual domains and peering/bilateral agreements between
domain operators.

i see pgrp as providing information for item ii) above.

without doubt, i think that location servers must have a keepalive
(as well as a channel open/channel close) mechanism to ensure that
status of the channel at any given time.  i would also suggest that
glp *not* use aging of location information across domains but
rather send information only when there is state change information
to be propagated.

-- 
  __  ______  __  / __/ |       lucent technologies, naperville il, usa
_/ (_(_) / (_(_/_/_(_/  .       [email-masked]
"if you ain't the lead dog, the scenery never changes"  -- edmund wilson
---------
This message came from the IETF IPTEL Working Group Mailing List.