From http-state-admin@lists.bell-labs.com  Thu Nov  1 06:27:32 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10305
	for <iptel-archive@odin.ietf.org>; Thu, 1 Nov 2001 06:27:32 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP id 07B7F449E6
	for <iptel-archive@lists.ietf.org>; Thu,  1 Nov 2001 05:12:08 -0500 (EST)
Subject: lists.bell-labs.com mailing list memberships reminder
From: mailman-owner@lists.bell-labs.com
To: iptel-archive@ietf.org
X-No-Archive: yes
X-Ack: no
Sender: http-state-admin@lists.bell-labs.com
Errors-To: http-state-admin@lists.bell-labs.com
X-BeenThere: http-state@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
Message-Id: <20011101101208.07B7F449E6@lists.bell-labs.com>
Date: Thu,  1 Nov 2001 05:12:08 -0500 (EST)

This is a reminder, sent out once a month, about your
lists.bell-labs.com mailing list memberships.  It includes your
subscription info and how to use it to change it or unsubscribe from a
list.

You can visit the URLs to change your membership status or
configuration, including unsubscribing, setting digest-style delivery
or disabling delivery altogether (e.g., for a vacation), and so on.

In addition to the URL interfaces, you can also use email to make such
changes.  For more info, send a message to the '-request' address of
the list (for example, iptel-request@lists.bell-labs.com) containing
just the word 'help' in the message body, and an email message will be
sent to you with instructions.

If you have questions, problems, comments, etc, send them to
mailman-owner@lists.bell-labs.com.  Thanks!

Passwords for iptel-archive@lists.ietf.org:

List                                     Password // URL
----                                     --------  
iptel@lists.bell-labs.com                Gfcn      
http://lists.bell-labs.com/mailman/options/iptel/iptel-archive%40lists.ietf.org


From iptel-admin@lists.bell-labs.com  Thu Nov  1 12:12:33 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23992
	for <iptel-archive@odin.ietf.org>; Thu, 1 Nov 2001 12:12:33 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 0DF6444340; Thu,  1 Nov 2001 11:05:03 -0500 (EST)
Delivered-To: iptel@lists.bell-labs.com
Received: from znsgs0ja.europe.nortel.com (znsgs0ja.nortelnetworks.com [47.165.25.40])
	by lists.bell-labs.com (Postfix) with ESMTP id 49E6D44337
	for <iptel@lists.bell-labs.com>; Thu,  1 Nov 2001 11:04:29 -0500 (EST)
Received: from qnsgs000.nortel.com (znsgs016 [47.255.64.31])
	by znsgs0ja.europe.nortel.com (8.11.0/8.11.0) with ESMTP id fA1HBxk00413
	for <iptel@lists.bell-labs.com>; Thu, 1 Nov 2001 17:12:00 GMT
Received: from zwcwc012.europe.nortel.com by znsgs016;
          Thu, 1 Nov 2001 17:11:52 +0000
Received: by zwcwc012.europe.nortel.com 
          with Internet Mail Service (5.5.2653.19) id <V389HLWM>;
          Thu, 1 Nov 2001 17:11:14 -0000
Message-ID: <588B15E2E2B1D41180B800508BF934F251ED91@bmdhd6.europe.nortel.com>
From: "William Parton" <parton@nortelnetworks.com>
To: "'iptel@lists.bell-labs.com'" <iptel@lists.bell-labs.com>
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C162F8.336764B0"
Subject: [IPTEL] Aggregation and Communities
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Thu, 1 Nov 2001 17:11:09 -0000

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C162F8.336764B0
Content-Type: text/plain;
	charset="iso-8859-1"

Section 5.9.4 of draft 9 of the TRIP spec states the following with regard
to aggregating Communities Routing Attributes:

If a set of routes is to be aggregated and the resultant aggregate does not
carry an Atomic_Aggregate attribute, then the resulting aggregate should
have a Communities attribute that contains the union of the Community
attributes of the aggregated routes. 

What is the aggregate for communities if the resultant aggregate does carry
an Atomic Aggregate attribute?

regards
Will

------_=_NextPart_001_01C162F8.336764B0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>Aggregation and Communities</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Section 5.9.4 of draft 9 of the TRIP spec states the =
following with regard to aggregating Communities Routing =
Attributes:</FONT></P>

<P><FONT SIZE=3D2>If a set of routes is to be aggregated and the =
resultant aggregate does not carry an Atomic_Aggregate attribute, then =
the resulting aggregate should have a Communities attribute that =
contains the union of the Community attributes of the aggregated =
routes. </FONT></P>

<P><FONT SIZE=3D2>What is the aggregate for communities if the =
resultant aggregate does carry an Atomic Aggregate attribute?</FONT>
</P>

<P><FONT SIZE=3D2>regards</FONT>
<BR><FONT SIZE=3D2>Will</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C162F8.336764B0--

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Sat Nov  3 21:09:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20215
	for <iptel-archive@odin.ietf.org>; Sat, 3 Nov 2001 21:09:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 8C60344348; Sat,  3 Nov 2001 20:02:02 -0500 (EST)
Delivered-To: iptel@lists.bell-labs.com
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by lists.bell-labs.com (Postfix) with ESMTP id 8E76A44341
	for <iptel@lists.bell-labs.com>; Sat,  3 Nov 2001 20:01:45 -0500 (EST)
Received: from mira-sjc5-8.cisco.com (mira-sjc5-8.cisco.com [171.71.163.31])
	by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id fA427NM23075;
	Sat, 3 Nov 2001 18:07:23 -0800 (PST)
Received: from cisco.com (sjc-vpn1-682.cisco.com [10.21.98.170])
	by mira-sjc5-8.cisco.com (Mirapoint)
	with ESMTP id ABY18541;
	Sat, 3 Nov 2001 18:09:28 -0800 (PST)
Message-ID: <3BE4A367.16D6F8E9@cisco.com>
From: Anirudh Sahoo <asahoo@cisco.com>
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: cipher_nitin@flashmail.com
Cc: iptel@lists.bell-labs.com
Subject: Re: [IPTEL] a doubt on TRIP
References: <3be0c45c.223.0@flashmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Sat, 03 Nov 2001 18:09:43 -0800
Content-Transfer-Encoding: 7bit

please see in line:

Nitin Kumar wrote:

> Hello,
>
> My name is Nitin Mahajan and the reason I am writting to you is because I had
> just read the draft on TRIP i.e draft-ietf-iptel-trip-09.txt.
>
> I had some doubts which if you could please clarify (jonathan rosenberg has
> referred me to you).
>
> For decision process architecture the draft says of rules to be followed for
> tie breaks. Now, I could see in Sec 10.2.2.1 the 3 rules to be used for tie
> break (for internal as well as external ) but, the draft  mentions the 2 rules
> to be used for tie breaks (for external peers) again in Sec 10.3.1.1.
>
> Though the rules in the later section boil down to be same, but why are they
> given again , am I missing something ?

This is my understanding:
The rule in 10.3.1.1 does not boil down to the same. 10.2.2 is used when
Ext-TRIB or Loc-TRIB is being updated and as a result a potential change
in Adj-TRIB-out and disseminating routes to external peers (external update).
10.3.1 is for internal updates.  Rule 1 in 10.2.2.1 is really different
from rule 1 of 10.3.1.1. 10.2.2.1 says if the routes are from
the _same_ neighboring ITADs then the route with
_larger_ MultiExitDisc is chosen.
Whereas 10.3.1.1 rule 1, I think, the peers are
from different ITADs. Also, in this case, it will choose the route
with _lowest_ MultiExitDisc.

>
>
> Also, isn't the 2nd point in the later Section 10.3.1.1 mentions the use of
> TRIP Identifier for tie break , shouldn't it be ITAD number ? As otherwise don't
> we leave an another chance of tie ?

I think it should be ITAD number instead of TRIP identifier, since the
routes are from peers of different ITAD.

>
>
> Please correct me if I am going wrong somwhere ( this is my first time reading
> such draft).
>
> Thanks in Advance,
>
> Nitin
> ______________________________________________________
> Get Your FREE FlashMail Address now at http://www.flashmail.com
> It's Free, Easy, & Fun !!!
>
> _______________________________________________
> IPTEL mailing list
> IPTEL@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/iptel


_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Sat Nov  3 21:39:58 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21321
	for <iptel-archive@odin.ietf.org>; Sat, 3 Nov 2001 21:39:58 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 3CDA94434F; Sat,  3 Nov 2001 20:32:04 -0500 (EST)
Delivered-To: iptel@lists.bell-labs.com
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by lists.bell-labs.com (Postfix) with ESMTP id 99BE144341
	for <iptel@lists.bell-labs.com>; Sat,  3 Nov 2001 20:31:40 -0500 (EST)
Received: from mira-sjc5-8.cisco.com (mira-sjc5-8.cisco.com [171.71.163.31])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id fA42dVa09838
	for <iptel@lists.bell-labs.com>; Sat, 3 Nov 2001 18:39:31 -0800 (PST)
Received: from cisco.com (sjc-vpn1-682.cisco.com [10.21.98.170])
	by mira-sjc5-8.cisco.com (Mirapoint)
	with ESMTP id ABY18603;
	Sat, 3 Nov 2001 18:39:23 -0800 (PST)
Message-ID: <3BE4AA6B.26F7E2EA@cisco.com>
From: Anirudh Sahoo <asahoo@cisco.com>
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: iptel@lists.bell-labs.com
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: [IPTEL] few questions on TRIP
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Sat, 03 Nov 2001 18:39:39 -0800
Content-Transfer-Encoding: 7bit

Hi all,
    I have a couple of questions on TRIP draft:

1. The minimum length of OPEN message should be
    17 (3 octets TRIP header + 14 octets of
    OPEN msg header), instead of 14? I think the draft
    does not take TRIP header into account while
    counting the minimum length.

2. In Section 5.4.2, should not the draft also mention
    that the originating LS should (or MUST?) set the type of the
    AdvertisementPath to AP_SEQUENCE?


_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Sun Nov  4 04:40:55 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10654
	for <iptel-archive@odin.ietf.org>; Sun, 4 Nov 2001 04:40:55 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 3356D44354; Sun,  4 Nov 2001 03:33:03 -0500 (EST)
Delivered-To: iptel@lists.bell-labs.com
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by lists.bell-labs.com (Postfix) with ESMTP id E7E6744351
	for <iptel@lists.bell-labs.com>; Sun,  4 Nov 2001 03:32:25 -0500 (EST)
Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.24.14])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id fA49eBT16007;
	Sun, 4 Nov 2001 01:40:11 -0800 (PST)
Received: from cisco.com (sjc-vpn1-812.cisco.com [10.21.99.44])
	by mira-sjcm-2.cisco.com (Mirapoint)
	with ESMTP id AAR11199;
	Sun, 4 Nov 2001 01:40:07 -0800 (PST)
Message-ID: <3BE50CA7.40673B5@cisco.com>
From: Manjunath Bangalore <manjax@cisco.com>
Organization: Cisco Systems
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Anirudh Sahoo <asahoo@cisco.com>
Cc: iptel@lists.bell-labs.com
Subject: Re: [IPTEL] few questions on TRIP
References: <3BE4AA6B.26F7E2EA@cisco.com>
Content-Type: multipart/alternative;
 boundary="------------D648F92599352D1913670CCC"
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Sun, 04 Nov 2001 01:38:47 -0800


--------------D648F92599352D1913670CCC
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Anirudh,

> Hi all,
>     I have a couple of questions on TRIP draft:
>
> 1. The minimum length of OPEN message should be
>     17 (3 octets TRIP header + 14 octets of
>     OPEN msg header), instead of 14? I think the draft
>     does not take TRIP header into account while
>     counting the minimum length.

You are right, including the header, the minimum length should be 17
octets
Looks like sec 4.2 was apparently supposed to read
"(not including message header)"

>
>
> 2. In Section 5.4.2, should not the draft also mention
>     that the originating LS should (or MUST?) set the type of the
>     AdvertisementPath to AP_SEQUENCE?
>

When a path segment in either path attribute (AdvertisementPath or
RoutedPath) contains only one ITAD member (in the case that you mention,
the Originating ITAD), AP_SEQUENCE is equivalent to AP_SET. The property
of being an "ordered" or "unordered" set defined through the 'path
segment type' comes into picture only when there are at least 2 ITAD
members in the path segment.

regards,
-Manjax


--------------D648F92599352D1913670CCC
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Anirudh,
<blockquote TYPE=CITE>Hi all,
<br>&nbsp;&nbsp;&nbsp; I have a couple of questions on TRIP draft:
<p>1. The minimum length of OPEN message should be
<br>&nbsp;&nbsp;&nbsp; 17 (3 octets TRIP header + 14 octets of
<br>&nbsp;&nbsp;&nbsp; OPEN msg header), instead of 14? I think the draft
<br>&nbsp;&nbsp;&nbsp; does not take TRIP header into account while
<br>&nbsp;&nbsp;&nbsp; counting the minimum length.</blockquote>
You are right, including the header, the minimum length should be 17 octets
<br>Looks like sec 4.2 was apparently supposed to read
<br>"(<b>not</b> including message header)"
<blockquote TYPE=CITE>&nbsp;
<p>2. In Section 5.4.2, should not the draft also mention
<br>&nbsp;&nbsp;&nbsp; that the originating LS should (or MUST?) set the
type of the
<br>&nbsp;&nbsp;&nbsp; AdvertisementPath to AP_SEQUENCE?
<br>&nbsp;</blockquote>
When a path segment in either path attribute (AdvertisementPath or RoutedPath)
contains only one ITAD member (in the case that you mention, the Originating
ITAD), AP_SEQUENCE is equivalent to AP_SET. The property of being an "ordered"
or "unordered" set defined through the 'path segment type' comes into picture
only when there are at least 2 ITAD members in the path segment.
<p>regards,
<br>-Manjax
<br>&nbsp;</html>

--------------D648F92599352D1913670CCC--


_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Mon Nov  5 04:26:04 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09589
	for <iptel-archive@odin.ietf.org>; Mon, 5 Nov 2001 04:26:04 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id E8FAB44363; Mon,  5 Nov 2001 03:18:02 -0500 (EST)
Delivered-To: iptel@lists.bell-labs.com
Received: from flashmail.com (flash2.flashmail.com [207.173.216.241])
	by lists.bell-labs.com (Postfix) with SMTP id BF46D4435C
	for <iptel@lists.bell-labs.com>; Mon,  5 Nov 2001 03:17:08 -0500 (EST)
Received: (qmail 2075 invoked from network); 5 Nov 2001 09:26:16 -0000
Received: from unknown (HELO flashmail.com) (207.173.216.240)
  by flash2.flashmail.com with SMTP; 5 Nov 2001 09:26:16 -0000
From: "Nitin Kumar" <cipher_nitin@flashmail.com>
Reply-To: cipher_nitin@flashmail.com
To: Anirudh Sahoo <asahoo@cisco.com>, cipher_nitin@flashmail.com,
        iptel@lists.bell-labs.com
Cc: iptel@lists.bell-labs.com
Subject: Re: [IPTEL] a doubt on TRIP
Message-id: <3be65b7b.c3.0@flashmail.com>
X-User-Info: 203.190.136.98
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Mon, 5 Nov 2001 01:27:23 -0800
Content-Transfer-Encoding: 7bit


Hello Anirudh,

First of all, thanks for your reply ..

on that only, I was wondering why would we need two ways to break the tie breaks
.. 

from the way I can see and understand, all internal updates are given birth
( or propagated ) by an LS for only 2 possible cases :

1) when either it gets a "new" route in an update from an LS in it's own ITAD

2) when an update recvd. from an external LS causes change in it's Ext-TRIB
/ Loc-TRIB.

Am I getting it right  ?

Now,  say a route comes from an external LS whose degree of preference is calculated
and found to be higher than rest in the databse. It is thus now incorporated
into the Ext-TRIB and the Loc-TRIB. Now, aren't we supposed to have this route
forwarded to Internal LS, no matter what ? As Loc-TRIB of all the LS needs to
be the same and this is route has been say an external route update / local
injection to this specific LS , so it is his duty to forward this news to everyone
?

So, where did we happen to use the Sec 10.3.1.1 conditions ? for calculation
of route into the Ext -TRIB, we should be using Sec. 10.2.2.1 rules itself,
isn't it ?

Theoretically, we could have used Sec. 10.2.2.1 for route selection into Ext-TRIB
and use 10.3.1.1 rule again on the Adj-TRIB-In data for selection of routes
to be sent to Internal LS, but the outcome of this second phase of tie breaks
is only for selection of routes to be propogated to Internal LS's .. 

(Again -:) ) am I right ? was this what the draft was pointing to ?

If yes, then doesn't it causes an obvious confusion as the route in Ext-TRIB
would be different for sure than the route sent to Internal LS. ?

If No, Please tell me where  am I going wrong ?

Also , is there any logical belief in selecting lowest Multi Exit Desc value
as in Sec 10.3.1.1 ? 

Lastly, Sec 10.3.1.1 doesn't has the word "same" ,  in it's 1st Rule for Multi
Exit Disc, so is it suggesting that we use the Multi Exit Disc even for the
case when the routes being compared are not from same ITAD ? 
My understanding says......... no  .. 

and if that is the case could we have the "same" word added to the rule description
in Sec 10.3.1.1, as it could be misleading.

Thanks in Advance,

Nitin


>please see in line:
>
>Nitin Kumar wrote:
>
>> Hello,
>>
>> My name is Nitin Mahajan and the reason I am writting to you is because I
had
>> just read the draft on TRIP i.e draft-ietf-iptel-trip-09.txt.
>>
>> I had some doubts which if you could please clarify (jonathan rosenberg has

>> referred me to you).
>>
>> For decision process architecture the draft says of rules to be followed
for
>> tie breaks. Now, I could see in Sec 10.2.2.1 the 3 rules to be used for tie

>> break (for internal as well as external ) but, the draft  mentions the 2
rules
>> to be used for tie breaks (for external peers) again in Sec 10.3.1.1.
>>
>> Though the rules in the later section boil down to be same, but why are they

>> given again , am I missing something ?
>
>This is my understanding:
>The rule in 10.3.1.1 does not boil down to the same. 10.2.2 is used when
>Ext-TRIB or Loc-TRIB is being updated and as a result a potential change
>in Adj-TRIB-out and disseminating routes to external peers (external update).

>10.3.1 is for internal updates.  Rule 1 in 10.2.2.1 is really different
>from rule 1 of 10.3.1.1. 10.2.2.1 says if the routes are from
>the _same_ neighboring ITADs then the route with
>_larger_ MultiExitDisc is chosen.
>Whereas 10.3.1.1 rule 1, I think, the peers are
>from different ITADs. Also, in this case, it will choose the route
>with _lowest_ MultiExitDisc.
>
>>
>>
>> Also, isn't the 2nd point in the later Section 10.3.1.1 mentions the use
of
>> TRIP Identifier for tie break , shouldn't it be ITAD number ? As otherwise
don't
>> we leave an another chance of tie ?
>
>I think it should be ITAD number instead of TRIP identifier, since the
>routes are from peers of different ITAD.
>
>>
>>
>> Please correct me if I am going wrong somwhere ( this is my first time reading

>> such draft).
>>
>> Thanks in Advance,
>>
>> Nitin
>> ______________________________________________________
>> Get Your FREE FlashMail Address now at http://www.flashmail.com
>> It's Free, Easy, & Fun !!!
>>
>> _______________________________________________
>> IPTEL mailing list
>> IPTEL@lists.bell-labs.com
>> http://lists.bell-labs.com/mailman/listinfo/iptel
>
>
>
______________________________________________________
Get Your FREE FlashMail Address now at http://www.flashmail.com
It's Free, Easy, & Fun !!!

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Mon Nov  5 04:28:00 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09606
	for <iptel-archive@odin.ietf.org>; Mon, 5 Nov 2001 04:28:00 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id E755744369; Mon,  5 Nov 2001 03:18:07 -0500 (EST)
Delivered-To: iptel@lists.bell-labs.com
Received: from flashmail.com (flash2.flashmail.com [207.173.216.241])
	by lists.bell-labs.com (Postfix) with SMTP id F1A764435C
	for <iptel@lists.bell-labs.com>; Mon,  5 Nov 2001 03:17:11 -0500 (EST)
Received: (qmail 2075 invoked from network); 5 Nov 2001 09:26:16 -0000
Received: from unknown (HELO flashmail.com) (207.173.216.240)
  by flash2.flashmail.com with SMTP; 5 Nov 2001 09:26:16 -0000
From: "Nitin Kumar" <cipher_nitin@flashmail.com>
Reply-To: cipher_nitin@flashmail.com
To: Anirudh Sahoo <asahoo@cisco.com>, cipher_nitin@flashmail.com,
        iptel@lists.bell-labs.com
Cc: iptel@lists.bell-labs.com
Subject: Re: [IPTEL] a doubt on TRIP
Message-id: <3be65b7b.c3.0@flashmail.com>
X-User-Info: 203.190.136.98
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Mon, 5 Nov 2001 01:27:23 -0800
Content-Transfer-Encoding: 7bit


Hello Anirudh,

First of all, thanks for your reply ..

on that only, I was wondering why would we need two ways to break the tie breaks
.. 

from the way I can see and understand, all internal updates are given birth
( or propagated ) by an LS for only 2 possible cases :

1) when either it gets a "new" route in an update from an LS in it's own ITAD

2) when an update recvd. from an external LS causes change in it's Ext-TRIB
/ Loc-TRIB.

Am I getting it right  ?

Now,  say a route comes from an external LS whose degree of preference is calculated
and found to be higher than rest in the databse. It is thus now incorporated
into the Ext-TRIB and the Loc-TRIB. Now, aren't we supposed to have this route
forwarded to Internal LS, no matter what ? As Loc-TRIB of all the LS needs to
be the same and this is route has been say an external route update / local
injection to this specific LS , so it is his duty to forward this news to everyone
?

So, where did we happen to use the Sec 10.3.1.1 conditions ? for calculation
of route into the Ext -TRIB, we should be using Sec. 10.2.2.1 rules itself,
isn't it ?

Theoretically, we could have used Sec. 10.2.2.1 for route selection into Ext-TRIB
and use 10.3.1.1 rule again on the Adj-TRIB-In data for selection of routes
to be sent to Internal LS, but the outcome of this second phase of tie breaks
is only for selection of routes to be propogated to Internal LS's .. 

(Again -:) ) am I right ? was this what the draft was pointing to ?

If yes, then doesn't it causes an obvious confusion as the route in Ext-TRIB
would be different for sure than the route sent to Internal LS. ?

If No, Please tell me where  am I going wrong ?

Also , is there any logical belief in selecting lowest Multi Exit Desc value
as in Sec 10.3.1.1 ? 

Lastly, Sec 10.3.1.1 doesn't has the word "same" ,  in it's 1st Rule for Multi
Exit Disc, so is it suggesting that we use the Multi Exit Disc even for the
case when the routes being compared are not from same ITAD ? 
My understanding says......... no  .. 

and if that is the case could we have the "same" word added to the rule description
in Sec 10.3.1.1, as it could be misleading.

Thanks in Advance,

Nitin


>please see in line:
>
>Nitin Kumar wrote:
>
>> Hello,
>>
>> My name is Nitin Mahajan and the reason I am writting to you is because I
had
>> just read the draft on TRIP i.e draft-ietf-iptel-trip-09.txt.
>>
>> I had some doubts which if you could please clarify (jonathan rosenberg has

>> referred me to you).
>>
>> For decision process architecture the draft says of rules to be followed
for
>> tie breaks. Now, I could see in Sec 10.2.2.1 the 3 rules to be used for tie

>> break (for internal as well as external ) but, the draft  mentions the 2
rules
>> to be used for tie breaks (for external peers) again in Sec 10.3.1.1.
>>
>> Though the rules in the later section boil down to be same, but why are they

>> given again , am I missing something ?
>
>This is my understanding:
>The rule in 10.3.1.1 does not boil down to the same. 10.2.2 is used when
>Ext-TRIB or Loc-TRIB is being updated and as a result a potential change
>in Adj-TRIB-out and disseminating routes to external peers (external update).

>10.3.1 is for internal updates.  Rule 1 in 10.2.2.1 is really different
>from rule 1 of 10.3.1.1. 10.2.2.1 says if the routes are from
>the _same_ neighboring ITADs then the route with
>_larger_ MultiExitDisc is chosen.
>Whereas 10.3.1.1 rule 1, I think, the peers are
>from different ITADs. Also, in this case, it will choose the route
>with _lowest_ MultiExitDisc.
>
>>
>>
>> Also, isn't the 2nd point in the later Section 10.3.1.1 mentions the use
of
>> TRIP Identifier for tie break , shouldn't it be ITAD number ? As otherwise
don't
>> we leave an another chance of tie ?
>
>I think it should be ITAD number instead of TRIP identifier, since the
>routes are from peers of different ITAD.
>
>>
>>
>> Please correct me if I am going wrong somwhere ( this is my first time reading

>> such draft).
>>
>> Thanks in Advance,
>>
>> Nitin
>> ______________________________________________________
>> Get Your FREE FlashMail Address now at http://www.flashmail.com
>> It's Free, Easy, & Fun !!!
>>
>> _______________________________________________
>> IPTEL mailing list
>> IPTEL@lists.bell-labs.com
>> http://lists.bell-labs.com/mailman/listinfo/iptel
>
>
>
______________________________________________________
Get Your FREE FlashMail Address now at http://www.flashmail.com
It's Free, Easy, & Fun !!!

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Tue Nov  6 20:55:20 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08069
	for <iptel-archive@odin.ietf.org>; Tue, 6 Nov 2001 20:55:19 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id C562C44339; Tue,  6 Nov 2001 19:47:03 -0500 (EST)
Delivered-To: iptel@lists.bell-labs.com
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by lists.bell-labs.com (Postfix) with ESMTP id 69F2544336
	for <iptel@lists.bell-labs.com>; Tue,  6 Nov 2001 19:46:23 -0500 (EST)
Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.24.14])
	by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id fA71qPx04002;
	Tue, 6 Nov 2001 17:52:25 -0800 (PST)
Received: from cisco.com (dhcp-128-107-139-114.cisco.com [128.107.139.114])
	by mira-sjcm-2.cisco.com (Mirapoint)
	with ESMTP id AAR78145;
	Tue, 6 Nov 2001 17:54:30 -0800 (PST)
Message-ID: <3BE8942E.129A3591@cisco.com>
From: Manjunath S Bangalore <manjax@cisco.com>
Organization: Cisco Systems
X-Mailer: Mozilla 4.5 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: William Parton <parton@nortelnetworks.com>
Cc: "'iptel@lists.bell-labs.com'" <iptel@lists.bell-labs.com>
Subject: Re: [IPTEL] Aggregation and Communities
References: <588B15E2E2B1D41180B800508BF934F251ED91@bmdhd6.europe.nortel.com>
Content-Type: multipart/alternative;
 boundary="------------12308AADC535180F07511B57"
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Tue, 06 Nov 2001 17:53:50 -0800


--------------12308AADC535180F07511B57
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Will,

 Let me take a shot at this -

 If the resultant aggregate has an AtomicAggregate attribute, then it
indicates that there is a loss of information. This is from the
definition of usage of the AtomicAggregate attribute. This attribute,
when included, indicates that a route may actually  include domains not
listed in the RoutedPath. So, including any set of communities along
with the resultant aggregate in such a case, will make the community
attribute incomplete at best.
  Let us now look into the general usage of communities. Communities are
typically used to group destinations that possibly comprise an alliance;
a subset of LSs in an ITAD that share a common role, for instance,can be
combined under a community, etc. From the paragraph preceding Sec 5.9.1,
an example use of the Communities attribute states that

"It is often useful to advertise advertise both the aggregate route and
the
component more-specific routes that were used to form the aggregate.
These component information are only useful to the neighboring TRIP
peer, and perhaps the ITAD of the neighboring TRIP peer, so it is
desirable to filter out the component routes."

Coming back to our original question, though the standard does not say
what value to use for the Community attribute in a resultant aggregate
that carries the AtomicAggregate attribute, we can use some of the
principles from the example above, and here is one approach: A resultant
aggregate route that carries the AtomicAggregate attribute can be
advertised *without* the Community attribute, and individual component
routes can additionally be advertised to specific neighbors or groups of
neighbors with the appropriate value of the Community attribute. This
way, the neighbors to whom the Community value matters get the
information, which can be used to filter routes.


Regards,
-Manjax

William Parton wrote:

>
>
> Section 5.9.4 of draft 9 of the TRIP spec states the following with
> regard to aggregating Communities Routing Attributes:
>
> If a set of routes is to be aggregated and the resultant aggregate
> does not carry an Atomic_Aggregate attribute, then the resulting
> aggregate should have a Communities attribute that contains the union
> of the Community attributes of the aggregated routes.
>
> What is the aggregate for communities if the resultant aggregate does
> carry an Atomic Aggregate attribute?
>
> regards
> Will

--------------12308AADC535180F07511B57
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Will,
<p>&nbsp;Let me take a shot at this -
<p>&nbsp;If the resultant aggregate has an AtomicAggregate attribute, then
it indicates that there is a loss of information. This is from the definition
of usage of the AtomicAggregate attribute. This attribute, when included,
indicates that a route may actually&nbsp; include domains not listed in
the RoutedPath. So, including any set of communities along with the resultant
aggregate in such a case, will make the community attribute incomplete
at best.
<br>&nbsp; Let us now look into the general usage of communities. Communities
are typically used to group destinations that possibly comprise an alliance;
a subset of LSs in an ITAD that share a common role, for instance,can be
combined under a community, etc. From the paragraph preceding Sec 5.9.1,
an example use of the Communities attribute states that
<p>"It is often useful to advertise advertise both the aggregate route
and the
<br>component more-specific routes that were used to form the aggregate.
<b>These
component information are only useful to the neighboring TRIP peer, and
perhaps the ITAD of the neighboring TRIP peer,</b> so it is desirable to
filter out the component routes."
<p>Coming back to our original question, though the standard does not say
what value to use for the Community attribute in a resultant aggregate
that carries the AtomicAggregate attribute, we can use some of the principles
from the example above, and here is one approach: A resultant aggregate
route that carries the AtomicAggregate attribute can be advertised *without*
the Community attribute, and individual component routes can additionally
be advertised to specific neighbors or groups of neighbors with the appropriate
value of the Community attribute. This way, the neighbors to whom the Community
value matters get the information, which can be used to filter routes.
<br>&nbsp;
<p>Regards,
<br>-Manjax
<p>William Parton wrote:
<blockquote TYPE=CITE>&nbsp;
<p><font size=-1>Section 5.9.4 of draft 9 of the TRIP spec states the following
with regard to aggregating Communities Routing Attributes:</font>
<p><font size=-1>If a set of routes is to be aggregated and the resultant
aggregate does not carry an Atomic_Aggregate attribute, then the resulting
aggregate should have a Communities attribute that contains the union of
the Community attributes of the aggregated routes.</font>
<p><font size=-1>What is the aggregate for communities if the resultant
aggregate does carry an Atomic Aggregate attribute?</font>
<p><font size=-1>regards</font>
<br><font size=-1>Will</font></blockquote>
</html>

--------------12308AADC535180F07511B57--


_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From consulem2000@yahoo.com.mx  Wed Nov  7 01:54:25 2001
Received: from mail51-axtel.net ([200.52.12.134])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19014
	for <iptel-archive@odin.ietf.org>; Wed, 7 Nov 2001 01:54:25 -0500 (EST)
From: consulem2000@yahoo.com.mx
Received: from laptop ([200.56.72.74]) by mail51-axtel.net  with Microsoft SMTPSVC(5.5.1877.447.44);
	 Wed, 7 Nov 2001 00:54:03 -0600
Subject: UNICO DIA 10 NOVIEMBRE SEMINARIO CERRADOR DE VENTAS
To: iptel-archive@ietf.org
Content-Type: 
 text/plain;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
Reply-To: consulem2000@yahoo.com.mx
Date: Wed, 7 Nov 2001 00:51:59 -0600
X-Priority: 3
X-Library: Indy 8.0.25
Message-ID: <0465202540607b1ASINMYSWNT51MS@mail51-axtel.net>

SEMINARIO EL CERRADOR PROFESIONAL DE VENTAS
                            Temario:
1. Los factores claves para lograr un buen control del proceso de ventas.
2. Como incrementar los ingresos de su empresa por medio de un excelente
control del
   cierre de ventas.
3. La importancia de la comunicacion efectiva en el cierre de ventas.
4. Como interesar al cliente en nuestro producto o servicio.
5. Como manejar en forma experta las objeciones del cliente.
6. Los pasos exactos para lograr el cierre de ventas.
7. Como incrementar su porcentaje de cierres de ventas.
8. Profesionalismo en ventas.
9. Los ingredientes claves para triunfar en ventas.
10. Ejercicios practicos en cada uno de los temas expuestos. Los ejercicios
estan dirigidos a la aplicacion de los conocimientos aprendidos para lograr
resultados de inmediato.

Fecha:   Sabado 10 de Noviembre del 2001
Lugar:  Hotel Bristol, Salon Bristol, Plaza Necaxa No. 17
    Rio Panuco esq. Rio Sena, Col. Cuauhtemoc, D.F.
Duracion:  8 horas, 50% del tiempo se dedica a la realizacion de ejercicios
practicos.
Horario:  Seminario de las 9:00 A.M. a las 18:30 P.M.
Dirigido a:  Ejecutivos de ventas, vendedores y propietarios de negocios.
Inversion:  $1,900.00 por participante (mas I.V.A.)
Incluye:  Material de apoyo Coffee Breaks y comida.

              Conferencista Internacional: Lic. Ricardo Colin Morales.
CON MAS DE 20 ANOS DE EXPERIENCIA CAPACITANDO A MILES DE VENDEDORES PARA
LA INDUSTRIA.

              RESERVE HOY MISMO TEL:5543 5961 y 5543 5781
              CON LA LIC. MERCEDES FLORES CASTANEDA
              DIRECTORA DE RELACIONES PUBLICAS,
              CONSULTORIA EMPRESARIAL


PD: Conforme a las leyes nacionales como internacionales este e-mail no
podrá ser considerado como SPAM si incluye un procedimiento para ser removido
de la lista. Si desea ser removido envienos un e-mail a ricolin2002@terra.com.mx,
indicandonos a que correo le hemos contactado y en el asunto indique "REMOVER
DE LA LISTA


From iptel-admin@lists.bell-labs.com  Thu Nov  8 10:34:31 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28550
	for <iptel-archive@lists.ietf.org>; Thu, 8 Nov 2001 10:34:31 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 81F4C44337; Thu,  8 Nov 2001 09:26:02 -0500 (EST)
Delivered-To: iptel@lists.bell-labs.com
Received: from flashmail.com (flash3.flashmail.com [207.173.216.243])
	by lists.bell-labs.com (Postfix) with SMTP id E9FC344336
	for <iptel@lists.bell-labs.com>; Thu,  8 Nov 2001 09:25:33 -0500 (EST)
Received: (qmail 27908 invoked from network); 8 Nov 2001 15:35:33 -0000
Received: from unknown (HELO flashmail.com) (207.173.216.240)
  by 0 with SMTP; 8 Nov 2001 15:35:33 -0000
From: "Nitin Kumar" <cipher_nitin@flashmail.com>
Reply-To: cipher_nitin@flashmail.com
To: iptel@lists.bell-labs.com
Cc: hsalama@cisco.com
Subject: Re: [IPTEL] a doubt on TRIP
Message-id: <3beaa678.1a8.0@flashmail.com>
X-User-Info: 203.190.136.98
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Thu, 8 Nov 2001 07:36:24 -0800
Content-Transfer-Encoding: 7bit



Hello Everyone,

Just looking into the state machine diagram at the back of the draft for iptel-trip-09.
A small doubt.

Don't we have this scenario, if I have got the picture correctly, that on getting
the start event we try and set up connection with the external LS acting as
a client ( trying an outbound connection in other words ), as well as start
looking for any inbound connection requests from the peer LS, in essence act
as a server also. 

Now, say if we first have a transport connection succes as a client, don't we
get the transport connection open event ? 

If yes, fine we do go ahead and send an open on this connection and say also
get an open back on this connection from peer. Making our state for this peer
LS as 'Open Confirm'.

Now, say if we get an inbound connection request on the server side of our's,
don't we still accept it and thus get an 'Transport Connection Open' event again
??

If yes, then why is it that on getting this event as per the FSM table in Appendix,
in the 'Open Confirm' State we move back to Idle. 

From, what I can think this is where we get to do connection collision detection
and select one of the transport connections now after getting an 'open message'
?

Also, I had written a mail some time back on the mailing list but didn't get
any response regarding the need for 2 different  tie break mechanisms, could
anyone please tell me where, I was so wrong.

(Attaching the last 2 mails for your reference)

Thanks,
Nitin

>
>Hello Anirudh,
>
>First of all, thanks for your reply ..
>
>on that only, I was wondering why would we need two ways to break the tie breaks

>.. 
>
>from the way I can see and understand, all internal updates are given birth

>( or propagated ) by an LS for only 2 possible cases :
>
>1) when either it gets a "new" route in an update from an LS in it's own ITAD

>
>2) when an update recvd. from an external LS causes change in it's Ext-TRIB

>/ Loc-TRIB.
>
>Am I getting it right  ?
>
>Now,  say a route comes from an external LS whose degree of preference is calculated

>and found to be higher than rest in the databse. It is thus now incorporated

>into the Ext-TRIB and the Loc-TRIB. Now, aren't we supposed to have this route

>forwarded to Internal LS, no matter what ? As Loc-TRIB of all the LS needs
to
>be the same and this is route has been say an external route update / local

>injection to this specific LS , so it is his duty to forward this news to everyone

>?
>
>So, where did we happen to use the Sec 10.3.1.1 conditions ? for calculation

>of route into the Ext -TRIB, we should be using Sec. 10.2.2.1 rules itself,

>isn't it ?
>
>Theoretically, we could have used Sec. 10.2.2.1 for route selection into Ext-TRIB

>and use 10.3.1.1 rule again on the Adj-TRIB-In data for selection of routes

>to be sent to Internal LS, but the outcome of this second phase of tie breaks

>is only for selection of routes to be propogated to Internal LS's .. 
>
>(Again -:) ) am I right ? was this what the draft was pointing to ?
>
>If yes, then doesn't it causes an obvious confusion as the route in Ext-TRIB

>would be different for sure than the route sent to Internal LS. ?
>
>If No, Please tell me where  am I going wrong ?
>
>Also , is there any logical belief in selecting lowest Multi Exit Desc value

>as in Sec 10.3.1.1 ? 
>
>Lastly, Sec 10.3.1.1 doesn't has the word "same" ,  in it's 1st Rule for Multi

>Exit Disc, so is it suggesting that we use the Multi Exit Disc even for the

>case when the routes being compared are not from same ITAD ? 
>My understanding says......... no  .. 
>
>and if that is the case could we have the "same" word added to the rule description

>in Sec 10.3.1.1, as it could be misleading.
>
>Thanks in Advance,
>
>Nitin
>
>
>>please see in line:
>>
>>Nitin Kumar wrote:
>>
>>> Hello,
>>>
>>> My name is Nitin Mahajan and the reason I am writting to you is because
I
>had
>>> just read the draft on TRIP i.e draft-ietf-iptel-trip-09.txt.
>>>
>>> I had some doubts which if you could please clarify (jonathan rosenberg
has
>
>>> referred me to you).
>>>
>>> For decision process architecture the draft says of rules to be followed

>for
>>> tie breaks. Now, I could see in Sec 10.2.2.1 the 3 rules to be used for
tie
>
>>> break (for internal as well as external ) but, the draft  mentions the 2

>rules
>>> to be used for tie breaks (for external peers) again in Sec 10.3.1.1.
>>>
>>> Though the rules in the later section boil down to be same, but why are
they
>
>>> given again , am I missing something ?
>>
>>This is my understanding:
>>The rule in 10.3.1.1 does not boil down to the same. 10.2.2 is used when
>>Ext-TRIB or Loc-TRIB is being updated and as a result a potential change
>>in Adj-TRIB-out and disseminating routes to external peers (external update).

>
>>10.3.1 is for internal updates.  Rule 1 in 10.2.2.1 is really different
>>from rule 1 of 10.3.1.1. 10.2.2.1 says if the routes are from
>>the _same_ neighboring ITADs then the route with
>>_larger_ MultiExitDisc is chosen.
>>Whereas 10.3.1.1 rule 1, I think, the peers are
>>from different ITADs. Also, in this case, it will choose the route
>>with _lowest_ MultiExitDisc.
>>
>>>
>>>
>>> Also, isn't the 2nd point in the later Section 10.3.1.1 mentions the use

>of
>>> TRIP Identifier for tie break , shouldn't it be ITAD number ? As otherwise

>don't
>>> we leave an another chance of tie ?
>>
>>I think it should be ITAD number instead of TRIP identifier, since the
>>routes are from peers of different ITAD.
>>
>>>
>>>
>>> Please correct me if I am going wrong somwhere ( this is my first time reading

>
>>> such draft).
>>>
>>> Thanks in Advance,
>>>
>>> Nitin
>>> ______________________________________________________
>>> Get Your FREE FlashMail Address now at http://www.flashmail.com
>>> It's Free, Easy, & Fun !!!
>>>
>>> _______________________________________________
>>> IPTEL mailing list
>>> IPTEL@lists.bell-labs.com
>>> http://lists.bell-labs.com/mailman/listinfo/iptel
>>
>>
>>
>______________________________________________________
>Get Your FREE FlashMail Address now at http://www.flashmail.com
>It's Free, Easy, & Fun !!!
>
>
______________________________________________________
Get Your FREE FlashMail Address now at http://www.flashmail.com
It's Free, Easy, & Fun !!!

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Fri Nov  9 03:58:38 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04874
	for <iptel-archive@lists.ietf.org>; Fri, 9 Nov 2001 03:58:37 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 0245544337; Fri,  9 Nov 2001 02:50:03 -0500 (EST)
Delivered-To: iptel@lists.bell-labs.com
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by lists.bell-labs.com (Postfix) with ESMTP id 4D06344336
	for <iptel@lists.bell-labs.com>; Fri,  9 Nov 2001 02:49:33 -0500 (EST)
Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.24.14])
	by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id fA98tsx17781;
	Fri, 9 Nov 2001 00:55:54 -0800 (PST)
Received: from cisco.com (sjc-vpn1-608.cisco.com [10.21.98.96])
	by mira-sjcm-2.cisco.com (Mirapoint)
	with ESMTP id AAS49679;
	Fri, 9 Nov 2001 00:58:03 -0800 (PST)
Message-ID: <3BEB9A46.5BA50269@cisco.com>
From: Manjunath Bangalore <manjax@cisco.com>
Organization: Cisco Systems
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: cipher_nitin@flashmail.com
Cc: iptel@lists.bell-labs.com, hsalama@cisco.com
Subject: Re: [IPTEL] a doubt on TRIP
References: <3beaa678.1a8.0@flashmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Fri, 09 Nov 2001 00:56:39 -0800
Content-Transfer-Encoding: 7bit

Hi Nitin,

  Please refer inline:

Nitin Kumar wrote:

> Hello Everyone,
>
> Just looking into the state machine diagram at the back of the draft for iptel-trip-09.
> A small doubt.
>
> Don't we have this scenario, if I have got the picture correctly, that on getting
> the start event we try and set up connection with the external LS acting as
> a client ( trying an outbound connection in other words ), as well as start
> looking for any inbound connection requests from the peer LS, in essence act
> as a server also.
>
> Now, say if we first have a transport connection succes as a client, don't we
> get the transport connection open event ?
>
> If yes, fine we do go ahead and send an open on this connection and say also
> get an open back on this connection from peer. Making our state for this peer
> LS as 'Open Confirm'.
>
> Now, say if we get an inbound connection request on the server side of our's,
> don't we still accept it and thus get an 'Transport Connection Open' event again
> ??
>
> If yes, then why is it that on getting this event as per the FSM table in Appendix,
> in the 'Open Confirm' State we move back to Idle.

The example that you have is a connection collision where two parallel connections between
the same peers exist at some point in time. In this case, (where one connection is in the
OpenConfirm state), and you receive an event 'Transport Connection Open', the LS should
check for the presence of any connection with that peer that are in the Established,
OpenConfirm or in the OpenSent state. If there are any, the LS should unconditionally close
the newly created connection.
The state table in the draft should be changed to reflect this.

It could well happen that both the peers use the above logic at their respective ends and
close the newly created connection hence leaving the connection in the OpenConfirm state
untouched.

Sec 6.8 discusses a Connection Collision Detection procedure that applies on the receipt of
an OPEN message but that cannot be applied here.  The example that you have reflects a
collision at an earlier stage.

>
> From, what I can think this is where we get to do connection collision detection
> and select one of the transport connections now after getting an 'open message'
> ?

>
> Also, I had written a mail some time back on the mailing list but didn't get
> any response regarding the need for 2 different  tie break mechanisms, could
> anyone please tell me where, I was so wrong.
>
> (Attaching the last 2 mails for your reference)
>

I haven't had a chance to look at your other mail. Will try to respond to that one...

Regards,
-Manjax


_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Tue Nov 20 16:27:13 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06791
	for <iptel-archive@odin.ietf.org>; Tue, 20 Nov 2001 16:27:13 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id A085144342; Tue, 20 Nov 2001 15:17:02 -0500 (EST)
Delivered-To: iptel@lists.bell-labs.com
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by lists.bell-labs.com (Postfix) with ESMTP id 701AB4433E
	for <iptel@lists.bell-labs.com>; Tue, 20 Nov 2001 15:16:21 -0500 (EST)
Received: from grandcentral.cs.columbia.edu (grandcentral.cs.columbia.edu [128.59.19.196])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id QAA29846;
	Tue, 20 Nov 2001 16:26:19 -0500 (EST)
Received: (from lennox@localhost)
	by grandcentral.cs.columbia.edu (8.10.2+Sun/8.9.3) id fAKLQCQ26063;
	Tue, 20 Nov 2001 16:26:12 -0500 (EST)
From: Jonathan Lennox <lennox@cs.columbia.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15354.51827.374964.687076@grandcentral.cs.columbia.edu>
To: iptel@lists.bell-labs.com
Cc: hgs@cs.columbia.edu, "Richard H. Gumpertz" <RGumpertz@Raviant.com>
X-Mailer: VM 6.75 under Emacs 20.7.1
Subject: [IPTEL] Change to CPL language specification
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Tue, 20 Nov 2001 16:26:11 -0500 (EST)
Content-Transfer-Encoding: 7bit

Richard Gumpertz pointed out to me a problem with CPL's language switches
using '<string-switch field="language">'.

Specifically, because of the structure of language tags, the match
lines of '<string contains="es">' can have false positive matches if the
caller sent 'Accept-Language: en,bes,fr'.  

Therefore, I propose to remove the 'language' field from string-switch, and
instead create a new language-switch.  In a language switch, the CPL script
can specify language-tags which are matched against the language-ranges of
the request.

Anyone have any issues with this?

-- 
Jonathan Lennox
lennox@cs.columbia.edu

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Wed Nov 21 01:54:21 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25851
	for <iptel-archive@odin.ietf.org>; Wed, 21 Nov 2001 01:54:20 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id EBB3F44353; Wed, 21 Nov 2001 00:44:02 -0500 (EST)
Delivered-To: iptel@lists.bell-labs.com
Received: from mail1.dynamicsoft.com (unknown [63.113.40.10])
	by lists.bell-labs.com (Postfix) with ESMTP id 0AA1D4434E
	for <iptel@lists.bell-labs.com>; Wed, 21 Nov 2001 00:43:14 -0500 (EST)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fAL6pDhp015903;
	Wed, 21 Nov 2001 01:51:13 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <XH6R4FX8>; Wed, 21 Nov 2001 01:52:36 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF020D6F8F@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Jonathan Lennox'" <lennox@cs.columbia.edu>, iptel@lists.bell-labs.com
Cc: hgs@cs.columbia.edu, "Richard H. Gumpertz" <RGumpertz@raviant.com>
Subject: RE: [IPTEL] Change to CPL language specification
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Wed, 21 Nov 2001 01:52:35 -0500

I think this is fine, but it will cause interop problems if people have lots
of scripts out there that are using string-switch with language. I suspect
that there are probably none in reality, but if you do have some, please
speak up.

Thanks,
Jonathan R.

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

> -----Original Message-----
> From: Jonathan Lennox [mailto:lennox@cs.columbia.edu]
> Sent: Tuesday, November 20, 2001 4:26 PM
> To: iptel@lists.bell-labs.com
> Cc: hgs@cs.columbia.edu; Richard H. Gumpertz
> Subject: [IPTEL] Change to CPL language specification
> 
> 
> Richard Gumpertz pointed out to me a problem with CPL's 
> language switches
> using '<string-switch field="language">'.
> 
> Specifically, because of the structure of language tags, the match
> lines of '<string contains="es">' can have false positive 
> matches if the
> caller sent 'Accept-Language: en,bes,fr'.  
> 
> Therefore, I propose to remove the 'language' field from 
> string-switch, and
> instead create a new language-switch.  In a language switch, 
> the CPL script
> can specify language-tags which are matched against the 
> language-ranges of
> the request.
> 
> Anyone have any issues with this?
> 
> -- 
> Jonathan Lennox
> lennox@cs.columbia.edu
> 
> _______________________________________________
> IPTEL mailing list
> IPTEL@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/iptel
> 

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Wed Nov 21 17:11:48 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10897
	for <iptel-archive@lists.ietf.org>; Wed, 21 Nov 2001 17:11:48 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 8DB744434E; Wed, 21 Nov 2001 16:01:01 -0500 (EST)
Delivered-To: iptel@lists.bell-labs.com
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by lists.bell-labs.com (Postfix) with ESMTP id 6496F4433E
	for <iptel@lists.bell-labs.com>; Wed, 21 Nov 2001 16:00:34 -0500 (EST)
Received: from grandcentral.cs.columbia.edu (grandcentral.cs.columbia.edu [128.59.19.196])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id RAA19408
	for <iptel@lists.bell-labs.com>; Wed, 21 Nov 2001 17:10:51 -0500 (EST)
Received: (from lennox@localhost)
	by grandcentral.cs.columbia.edu (8.10.2+Sun/8.9.3) id fALMApw03076;
	Wed, 21 Nov 2001 17:10:51 -0500 (EST)
From: Jonathan Lennox <lennox@cs.columbia.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15356.9834.902266.695171@grandcentral.cs.columbia.edu>
To: iptel@lists.bell-labs.com
X-Mailer: VM 6.75 under Emacs 20.7.1
Subject: [IPTEL] Now available: draft-ietf-iptel-cpl-05
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Wed, 21 Nov 2001 17:10:50 -0500 (EST)
Content-Transfer-Encoding: 7bit

The fifth (and hopefully final) revision of CPL, draft-ietf-iptel-cpl-05,
has just been submitted to the archive.  This version includes a resolution
of the issues with iCalendar over recurring intervals, as well as various
(hopefully minor) changes.  A full list of nontrivial changes is listed in
the changes section.

You can pick up a copy from
<http://www.cs.columbia.edu/~lennox/draft-ietf-iptel-cpl-05.txt> (text)
<http://www.cs.columbia.edu/~lennox/draft-ietf-iptel-cpl-05.ps>  (postscript)
<http://www.cs.columbia.edu/~lennox/draft-ietf-iptel-cpl-05.pdf> (PDF)

The Postscript and PDF versions contain changebars indicating significant
changes from draft -04.

This may or may not appear in the archive; for some reason the submission
bounced as being after the deadline, even though the bounced mail had a Date
header of around 4:45.

-- 
Jonathan Lennox
lennox@cs.columbia.edu

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Sun Nov 25 03:00:51 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17921
	for <iptel-archive@lists.ietf.org>; Sun, 25 Nov 2001 03:00:51 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id AE8D744337; Sun, 25 Nov 2001 01:50:03 -0500 (EST)
Delivered-To: iptel@lists.bell-labs.com
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by lists.bell-labs.com (Postfix) with ESMTP id BF89944336
	for <iptel@lists.bell-labs.com>; Sun, 25 Nov 2001 01:49:30 -0500 (EST)
Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.24.14])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id fAP80EE26361
	for <iptel@lists.bell-labs.com>; Sun, 25 Nov 2001 00:00:15 -0800 (PST)
Received: from cisco.com (sjc-vpn3-223.cisco.com [10.21.64.223])
	by mira-sjcm-2.cisco.com (Mirapoint)
	with ESMTP id AAV71490;
	Sun, 25 Nov 2001 00:00:06 -0800 (PST)
Message-ID: <3C00A4AA.4B553451@cisco.com>
From: Manjunath Bangalore <manjax@cisco.com>
Organization: Cisco Systems
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: iptel@lists.bell-labs.com
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: [IPTEL] IPTEL TRIP-GW draft
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Sat, 24 Nov 2001 23:58:35 -0800
Content-Transfer-Encoding: 7bit


The next version of the TRIP-GW draft is now available. Not sure if the
submission made on Wednesday, 11/21 made it to the archive. You can pick
up a copy from
ftp://ftpeng.cisco.com/ftp/dhaval/draft-rs-trip-gw-03.txt

Regards,
Manjunath Bangalore
 (Manjax)


_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From consultoriaemp7@yahoo.com.mx  Sun Nov 25 16:50:36 2001
Received: from smtp.prodigy.net.mx ([148.235.168.22])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25178
	for <iptel-archive@odin.ietf.org>; Sun, 25 Nov 2001 16:50:36 -0500 (EST)
Received: from frezzer (du-148-233-89-100.prodigy.net.mx [148.233.89.100])
 by SMTP.Prodigy.Net.mx (Sun Internet Mail Server sims.4.0.2001.07.26.11.50.p9)
 with SMTP id <0GND00JDGLX6JP@SMTP.Prodigy.Net.mx>; Sun,
 25 Nov 2001 15:49:19 -0600 (CST)
Date: Sun, 25 Nov 2001 15:50:39 -0600
From: "Lic. Alfredo Martinez Zepeda" <consultoriaemp7@yahoo.com.mx>
Subject: UNICO DIA 8 DE DICIEMBRE, SEMINARIO EL CERRADOR DE VENTAS.
To: iptel-archive@ietf.org
Reply-to: consultoriaemp7@yahoo.com.mx
Message-id: <0GND00JECLY2JP@SMTP.Prodigy.Net.mx>
MIME-version: 1.0
X-Mailer: Mailer Signature
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 8BIT
Content-Transfer-Encoding: 8BIT


SEMINARIO EL CERRADOR PROFESIONAL DE VENTAS
                            Temario:
1. Los factores claves para lograr un buen control del proceso de ventas.
2. Como incrementar los ingresos de su empresa por medio de un excelente control del cierre de ventas.
3. La importancia de la comunicacion efectiva en el cierre de ventas.
4. Como interesar al cliente en nuestro producto o servicio.
5. Como manejar en forma experta las objeciones del cliente.
6. Los pasos exactos para lograr el cierre de ventas.
7. Como incrementar su porcentaje de cierres de ventas.
8. Profesionalismo en ventas.
9. Los ingredientes claves para triunfar en ventas.
10. Ejercicios practicos en cada uno de los temas expuestos. Los ejercicios estan dirigidos a la aplicacion de los conocimientos aprendidos para lograr resultados de inmediato.

Fecha:	Sabado 8 de Diciembre del 2001
Lugar:	Hotel Bristol, Salon Bristol, Plaza Necaxa No. 17
		Rio Panuco esq. Rio Sena, Col. Cuauhtemoc, D.F.
Duracion:	8 horas, 50% del tiempo se dedica a la realizacion de ejercicios practicos.
Horario:	Seminario de las 9:00 A.M. a las 18:30 P.M.
Dirigido a:	Ejecutivos de ventas, vendedores y propietarios de negocios.
Inversion:	$1,900.00 por participante (mas I.V.A.)
Incluye:	Material de apoyo Coffee Breaks y comida.

              	Conferencista  Lic. Alfredo Martinez Zepeda.
CON MAS DE 7 ANOS DE EXPERIENCIA CAPACITANDO A MILES DE VENDEDORES PARA LA INDUSTRIA.

      	RESERVE HOY MISMO TEL: 5543 5961 y 5543 5781
      	CON LA SRA. LAURA AGUILAR
      	DIRECTORA DE RELACIONES PUBLICAS,
      	CONSULTORIA EMPRESARIAL


PD: Conforme a las leyes nacionales como internacionales este e-mail no podrá ser considerado como SPAM si incluye un procedimiento para ser removido de la lista. Si desea ser removido envienos un e-mail a consultoriaemp7@yahoo.com.mx indicandonos a que correo le hemos contactado y en el asunto indique "REMOVER DE LA LISTA"


From consultoriaemp7@yahoo.com.mx  Sun Nov 25 18:51:15 2001
Received: from smtp.prodigy.net.mx (dfproxy00.prodigy.net.mx [148.235.168.49] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25950
	for <iptel-archive@odin.ietf.org>; Sun, 25 Nov 2001 18:51:15 -0500 (EST)
Received: from frezzer (du-148-233-89-55.prodigy.net.mx [148.233.89.55])
 by SMTP.Prodigy.Net.mx (Sun Internet Mail Server sims.4.0.2001.07.26.11.50.p9)
 with SMTP id <0GND00DE5RO5CW@SMTP.Prodigy.Net.mx>; Sun,
 25 Nov 2001 17:54:47 -0600 (CST)
Date: Sun, 25 Nov 2001 17:51:26 -0600
From: "Lic. Alfredo Martinez Zepeda" <consultoriaemp7@yahoo.com.mx>
Subject: UNICO DIA 8 DE DICIEMBRE, SEMINARIO EL CERRADOR DE VENTAS.
To: iptel-archive@ietf.org
Reply-to: consultoriaemp7@yahoo.com.mx
Message-id: <0GND00DL8RR6CW@SMTP.Prodigy.Net.mx>
MIME-version: 1.0
X-Mailer: Mailer Signature
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 8BIT
Content-Transfer-Encoding: 8BIT


SEMINARIO EL CERRADOR PROFESIONAL DE VENTAS
                            Temario:
1. Los factores claves para lograr un buen control del proceso de ventas.
2. Como incrementar los ingresos de su empresa por medio de un excelente control del cierre de ventas.
3. La importancia de la comunicacion efectiva en el cierre de ventas.
4. Como interesar al cliente en nuestro producto o servicio.
5. Como manejar en forma experta las objeciones del cliente.
6. Los pasos exactos para lograr el cierre de ventas.
7. Como incrementar su porcentaje de cierres de ventas.
8. Profesionalismo en ventas.
9. Los ingredientes claves para triunfar en ventas.
10. Ejercicios practicos en cada uno de los temas expuestos. Los ejercicios estan dirigidos a la aplicacion de los conocimientos aprendidos para lograr resultados de inmediato.

Fecha:	Sabado 8 de Diciembre del 2001
Lugar:	Hotel Bristol, Salon Bristol, Plaza Necaxa No. 17
		Rio Panuco esq. Rio Sena, Col. Cuauhtemoc, D.F.
Duracion:	8 horas, 50% del tiempo se dedica a la realizacion de ejercicios practicos.
Horario:	Seminario de las 9:00 A.M. a las 18:30 P.M.
Dirigido a:	Ejecutivos de ventas, vendedores y propietarios de negocios.
Inversion:	$1,900.00 por participante (mas I.V.A.)
Incluye:	Material de apoyo Coffee Breaks y comida.

              	Conferencista  Lic. Alfredo Martinez Zepeda.
CON MAS DE 7 ANOS DE EXPERIENCIA CAPACITANDO A MILES DE VENDEDORES PARA LA INDUSTRIA.

      	RESERVE HOY MISMO TEL: 5543 5961 y 5543 5781
      	CON LA SRA. LAURA AGUILAR
      	DIRECTORA DE RELACIONES PUBLICAS,
      	CONSULTORIA EMPRESARIAL


PD: Conforme a las leyes nacionales como internacionales este e-mail no podrá ser considerado como SPAM si incluye un procedimiento para ser removido de la lista. Si desea ser removido envienos un e-mail a consultoriaemp7@yahoo.com.mx indicandonos a que correo le hemos contactado y en el asunto indique "REMOVER DE LA LISTA"


From iptel-admin@lists.bell-labs.com  Mon Nov 26 09:08:03 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27375
	for <iptel-archive@odin.ietf.org>; Mon, 26 Nov 2001 09:08:02 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 9676A4434A; Mon, 26 Nov 2001 07:57:02 -0500 (EST)
Delivered-To: iptel@lists.bell-labs.com
Received: from kcmso1.proxy.att.com (kcmso1.att.com [192.128.133.69])
	by lists.bell-labs.com (Postfix) with ESMTP id 67DE144346
	for <iptel@lists.bell-labs.com>; Mon, 26 Nov 2001 07:56:30 -0500 (EST)
Received: from njb140r1.ems.att.com ([135.65.202.58])
	by kcmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id fAQE7Ix16114;
	Mon, 26 Nov 2001 09:07:18 -0500 (EST)
Received: from njb140bh2.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2)
	id JAA11969; Mon, 26 Nov 2001 09:05:58 -0500 (EST)
Received: by NJB140BH2 with Internet Mail Service (5.5.2653.19)
	id <XJGD3W60>; Mon, 26 Nov 2001 09:07:18 -0500
Message-ID: <62DA45D4963FA747BA1B253E266760F958B8E7@OCCLUST04EVS1.ugd.att.com>
From: "Roy, Radhika R, ALCTA" <rrroy@att.com>
To: jdrosen@dynamicsoft.com
Cc: iptel@lists.bell-labs.com
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [IPTEL] Requirements for Gateway Registration I-D
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Mon, 26 Nov 2001 09:06:32 -0500

Hi, Jonathan:

I have the following comments for the I-D
<draft-rosenberg-iptel-gwreq-req-00.txt>:

1. The title should rather be " Requirements for intra-ITAD communications
protocol," because the protocol needs to do discovery, registration, and
communications among the gateways (GWs) and location servers (LSs).
2. Figure 1 should be modified to show that a GW can be Telephony gateway
(IP-PSTN) or SIP-H.323 interworking gateway (IP-IP).
3. The requirements should reflect that a GW can have the addresses of email
IDs and URL IDs and others in addition to Telephone addresses.
4. One additional requirement needs to be added: Synchronization of
information among the location servers.

In addition, we may also say that preferences will be given for selection of
the protocol in its "simplicity" and "efficiency" that can be used as an
"extension" or "subset" of TRIP protocol in satisfying the requirements.

Best regards,

Radhika R. Roy
rrroy@att.com

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Mon Nov 26 14:51:04 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24922
	for <iptel-archive@odin.ietf.org>; Mon, 26 Nov 2001 14:51:04 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 77D8944365; Mon, 26 Nov 2001 13:40:02 -0500 (EST)
Delivered-To: iptel@lists.bell-labs.com
Received: from sbcsmtp2.sbc.com (sbcsmtp2.sbc.com [209.184.203.4])
	by lists.bell-labs.com (Postfix) with ESMTP id AE61E44357
	for <iptel@lists.bell-labs.com>; Mon, 26 Nov 2001 13:30:27 -0500 (EST)
Received: from sbc.com (localhost [127.0.0.1])
	by sbcsmtp2.sbc.com (8.10.1/8.10.1) with ESMTP id fAQJcI214890;
	Mon, 26 Nov 2001 13:38:18 -0600 (CST)
Received: from msgstlhub02.sbc.com (msgstlhub02.sbc.com [132.201.87.59])
	by sbcsmtp2.sbc.com (8.10.1/8.10.1) with ESMTP id fAQJc8C14744;
	Mon, 26 Nov 2001 13:38:08 -0600 (CST)
Received: by msgstlhub02.sbc.com with Internet Mail Service (5.5.2653.19)
	id <WXFYL3Q8>; Mon, 26 Nov 2001 13:41:15 -0600
Message-ID: <C739248D6A6FD211B1940008C7A4752C09536F32@d072038.sbc.com>
From: "ANDERSON, DARBY (SBCTI)" <da7461@sbc.com>
To: "'Manjunath Bangalore'" <manjax@cisco.com>, iptel@lists.bell-labs.com
Subject: RE: [IPTEL] IPTEL TRIP-GW draft
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Mon, 26 Nov 2001 13:41:14 -0600

(If Ive sent this 2x, My appologies)

k...    Ive kinda been outta the loop for a couple weeks, but I just barely
saw the newest draft, and had some Q's bout routing...

Are we no longer routing on ITAD #'s, and now routing on FG-B/D CIC's??
What if someone outpulses digits to a gateway with a FG-D CIC in it, will
the gateway route the call on that CIC, or will there be some type of a
parameter in either the Voice G/W, or the RouteServ to implicitly deny
FG-B/FG-D Dial arrounds??

Also in reguards to trunking, how will TG's be tracked on the RouteServ for
traffic sculpting, and billing purposes??

-----Original Message-----
From: Manjunath Bangalore [mailto:manjax@cisco.com]
Sent: Sunday, November 25, 2001 12:59 AM
To: iptel@lists.bell-labs.com
Subject: [IPTEL] IPTEL TRIP-GW draft



The next version of the TRIP-GW draft is now available. Not sure if the
submission made on Wednesday, 11/21 made it to the archive. You can pick
up a copy from
ftp://ftpeng.cisco.com/ftp/dhaval/draft-rs-trip-gw-03.txt

Regards,
Manjunath Bangalore
 (Manjax)


_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Tue Nov 27 11:21:13 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07145
	for <iptel-archive@lists.ietf.org>; Tue, 27 Nov 2001 11:21:13 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 81EF344389; Tue, 27 Nov 2001 10:10:03 -0500 (EST)
Delivered-To: iptel@lists.bell-labs.com
Received: from mail1.dynamicsoft.com (unknown [63.113.40.10])
	by lists.bell-labs.com (Postfix) with ESMTP id 17D8844385
	for <iptel@lists.bell-labs.com>; Tue, 27 Nov 2001 10:09:25 -0500 (EST)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fARGIu7x010014;
	Tue, 27 Nov 2001 11:18:56 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <XH6R4P28>; Tue, 27 Nov 2001 11:20:22 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF020D7005@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Manjunath Bangalore'" <manjax@cisco.com>,
        Anirudh Sahoo <asahoo@cisco.com>
Cc: iptel@lists.bell-labs.com
Subject: RE: [IPTEL] few questions on TRIP
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Tue, 27 Nov 2001 11:20:13 -0500



  
-----Original Message-----
From: Manjunath Bangalore [mailto:manjax@cisco.com]
Sent: Sunday, November 04, 2001 4:39 AM
To: Anirudh Sahoo
Cc: iptel@lists.bell-labs.com
Subject: Re: [IPTEL] few questions on TRIP


Anirudh, 
Hi all, 
    I have a couple of questions on TRIP draft: 
1. The minimum length of OPEN message should be 
    17 (3 octets TRIP header + 14 octets of 
    OPEN msg header), instead of 14? I think the draft 
    does not take TRIP header into account while 
    counting the minimum length.
You are right, including the header, the minimum length should be 17 octets 
Looks like sec 4.2 was apparently supposed to read 
"(not including message header)" 

[JR] I will make sure this gets fixed during authors 48 hours.

-Jonathan R.  

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

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Tue Nov 27 12:01:08 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09845
	for <iptel-archive@lists.ietf.org>; Tue, 27 Nov 2001 12:01:07 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id E049644384; Tue, 27 Nov 2001 10:50:02 -0500 (EST)
Delivered-To: iptel@lists.bell-labs.com
Received: from mail1.dynamicsoft.com (unknown [63.113.40.10])
	by lists.bell-labs.com (Postfix) with ESMTP id 72C4044375
	for <iptel@lists.bell-labs.com>; Tue, 27 Nov 2001 10:49:42 -0500 (EST)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fARGxK7x010427
	for <iptel@lists.bell-labs.com>; Tue, 27 Nov 2001 11:59:21 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <XH6R4P30>; Tue, 27 Nov 2001 12:00:47 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF020D7006@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "List Iptel (E-mail)" <iptel@lists.bell-labs.com>
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [IPTEL] gateway registration - moving forward
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Tue, 27 Nov 2001 12:00:45 -0500

Folks,

I've been neglecting my duties as chair in helping guide the group forward
on this particular item. As you all know, I have a lot of IETF work on my
plate. Thats not an excuse, I know.

So, let me make some points on the gateway registration issue:

1. The scope of the work is clearly defined in the charter. Here is the
charter text:

---
However, this protocol does not address all the scenarios of route
information exchange between servers. One important scenario is the
propagation of routing information between gateways and the signaling
servers in front of them. This is also known as "gateway
registration". It allows the signaling server to make a routing decision
about which gateway to use based on dynamic information about
the gateway resources. Vendors have deployed proprietary solutions for this
communications interface. A standard is needed. The
group will generate a standards track document that defines a protocol
(possibly based on TRIP) for this interface. 
---

There are several key things in here. First, the charter item ONLY talks
about exchange of information between the gateways, and the servers directly
in front of them. This, by scope, EXCLUDES exchange of information between
LS/proxies within an ITAD. We are not working on the general intra-domain
problem at this time. Thus, draft-roy-iptel-itrp is OUT OF SCOPE and I want
no further discussion on this topic.


2. The charter talks about exchange of dynamic information about the gateway
resources. That is the main function provided by our protocol - not
discovery or "scale" or "reliability". Thus, it is important to focus more
time of the discussion on this issue. There were some proposals along those
lines - things like ASR and PDD, which need to be explored further. We have
also seen total capacity, available capacity, carriers, etc. I would like to
achieve consensus on a good set of these attributes, with a focus on the
dynamic ones, as thats what the charter talks about.

3. Monetary cost has come up again. I am ruling monetary cost OUT OF SCOPE.
It is a rathole and has serious issues with restricting business practice.
I'll also note that its pointless within a single domain, since cost
structures should generally be known a priori within the domain - I see
little need to have a protocol to exchange them. Protocols that do exchange
them, such as OSP, are used between different providers that have no way to
know the cost ahead of time. That is not the case here.

Henning had talked about some kind of relative, unit-less cost metrics. This
is similar to the LocalPreference attribute in TRIP, and is reasonable.
Additional discussion on this topic would certainly be welcome.

4. Much of the email discussions have focused on relatively content-free
comparisons of the protocols - mine is "more scalable" or "is easier to
interface to TRIP". These are vague and not solid enough. What we need to do
is figure out what we need from this protocol, on a concrete level, and then
we can see how the existing protocols match. For example, I would argue for
the following requirements:

  needs to have a persistent connection set up for the exchange of data, to
support congestion control

  should support establishment of a session key for authentication and
integrity; confidentiality is optional but helpful

  should support a keepalive, so that the LS can learn that the gateway has
failed. The keepalive should be fast, on the order to seconds, and not
require a lot of bandwidth (i.e., shouldn't have to refresh the entire set
of attributes as part of the keepalive)

  should support negotiation of the keepalive interval. The specific
requirement is for the server to tell the gateway what to use.

  should support partial updates, so that when a specific dynamic attribute
changes, only that attribute is sent


These are more detailed than the higher level requirements in
http://www.ietf.org/internet-drafts/draft-rosenberg-iptel-gwreg-req-00.txt,
but this level of requirement work is needed to determine what protocol we
want to use.

As Henning has pointed out, I think we will find that much of the discord on
requirements will likely come from different perspectives on the problems
that are being solved. I personally am most interested in a carrier
environment, where discovery is not needed, and where there will be lots of
gateways with lots of data to propagate. Thats different from a small
enterprise scenario, where one might want to have gateways that can be
discovered by an LS. I personally remain unconvinced that autodiscovery is
really useful in this kind of environment also, but I will post a separate
note on that. 

The main issue is this - how much do the requirements differ between these
differing environments? If we find that the discord is small, and that
perhaps auto-discovery is the only difference, that would argue for a single
solution with an optional capability to handle the differing requirement. As
Henning has pointed out, it is good to reuse a general purpose solution for
a specific scenario, if possible. This is not always possible, but it takes
requirements work to know that. If the discord is larger, that may require
separate protocols, and the group would need to decide which scenario to
address first. I would likely impose a decision based on the environement
with the smallest and simplest scope. 

Thus, I want to see the following:

1. I'd like people to post notes on the scenarios they see this protocol
being used - large carriers, enterprises, Internet2 usage, etc., and those
notes would have some diagrams of architectures along with statements of
some requirements that define that scenario. Having a common understand of
the problem areas people are trying to address is critical.

2. I'd like to see requirements posted on the functionality of the protocol,
and when those requirements are posted, I'd like to see that come with a
statement of what scenarios you believe that reuqirement is relevant for.


Once we have a fairly large set of these requirements, we can look at the
protocols on the table and see what is a match.

I'd also like to solicit a volunteer to begin edting together the scenarios
and reuqirements into a functional requirements I-D. I don't think this
would be a deliverable of the group per se, but it would help serve as a
point of documentation for whats been agreed to on the list. Please send me
a private note if you'd be interested, and have the time (the latter being
important) to do this.

I think the odds are slim that we will meet the current January deliverable
for this draft. I would propose pushing this to March, and will work with
Scott to have the charter updated to reflect that.


-Jonathan R.

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

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Tue Nov 27 12:49:10 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13187
	for <iptel-archive@odin.ietf.org>; Tue, 27 Nov 2001 12:49:10 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 9C0D244387; Tue, 27 Nov 2001 11:38:02 -0500 (EST)
Delivered-To: iptel@lists.bell-labs.com
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by lists.bell-labs.com (Postfix) with ESMTP id 164ED44385
	for <iptel@lists.bell-labs.com>; Tue, 27 Nov 2001 11:37:49 -0500 (EST)
Received: from cs.columbia.edu (metroliner.cs.columbia.edu [128.59.19.252])
	by opus.cs.columbia.edu (8.10.2+Sun/8.9.3) with ESMTP id fARHmnV26707;
	Tue, 27 Nov 2001 12:48:50 -0500 (EST)
Message-ID: <3C03D201.5C2039D5@cs.columbia.edu>
From: "Henning G. Schulzrinne" <hgs@cs.columbia.edu>
Organization: Dept. of Computer Science, Columbia University
X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.19-3cucs i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Cc: "List Iptel (E-mail)" <iptel@lists.bell-labs.com>
Subject: Re: [IPTEL] gateway registration - moving forward
References: <B65B4F8437968F488A01A940B21982BF020D7006@DYN-EXCH-001.dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Tue, 27 Nov 2001 12:48:49 -0500
Content-Transfer-Encoding: 7bit

Jonathan Rosenberg wrote:
> 

> 3. Monetary cost has come up again. I am ruling monetary cost OUT OF SCOPE.
> It is a rathole and has serious issues with restricting business practice.
> I'll also note that its pointless within a single domain, since cost
> structures should generally be known a priori within the domain - I see
> little need to have a protocol to exchange them. Protocols that do exchange
> them, such as OSP, are used between different providers that have no way to
> know the cost ahead of time. That is not the case here.

This depends a bit on the definition of "domain". I don't think the
current ITAD definition covers the whole spectrum of possibilities. For
example, in a semi-autonomous environment, some way of advertising
prices may be useful. (Branch offices of a corporation with gateways
that handle local calls, say.)

I agree that this is not appropriate for a WG standards-track document,
but I see no harm if somebody writes an experimental or informational
RFC saying "this is how we are doing it". Thus, any protocol should have
sufficient extensibility to accomodate this. But I suspect that this is
not even necessary for what people need in this type of environment, see
below.

> 
> Henning had talked about some kind of relative, unit-less cost metrics. This
> is similar to the LocalPreference attribute in TRIP, and is reasonable.
> Additional discussion on this topic would certainly be welcome.

I suspect that in many cases, even where some form of LCR is needed, the
unitless number will be sufficient once folks within a domain to define
what it means. Since the number is internal only, it doesn't matter to
anybody writing the protocol whether the number means thalers or simply
"don't go here unless you can't help it, we need our own phone lines".
Since updates within a domain can be frequent and people generally don't
book their phone calls like plane trips, there is no need to encode
tariffs into TLV format.


> 
>   should support partial updates, so that when a specific dynamic attribute
> changes, only that attribute is sent

To me, this seems less critical. Partial updates are always fraught with
danger, given possibilities for inconsistencies. This is only an
optimization that matters if the amount of data exchanged is large.
Maybe we should revisit this once we have a better idea how much data is
likely to be exchanged.


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

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Tue Nov 27 12:52:09 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13384
	for <iptel-archive@odin.ietf.org>; Tue, 27 Nov 2001 12:52:09 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id C088D4439A; Tue, 27 Nov 2001 11:41:01 -0500 (EST)
Delivered-To: iptel@lists.bell-labs.com
Received: from mail1.dynamicsoft.com (unknown [63.113.40.10])
	by lists.bell-labs.com (Postfix) with ESMTP id 92DE644383
	for <iptel@lists.bell-labs.com>; Tue, 27 Nov 2001 11:40:17 -0500 (EST)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fARHnu7x010874
	for <iptel@lists.bell-labs.com>; Tue, 27 Nov 2001 12:49:56 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <XH6R4PVR>; Tue, 27 Nov 2001 12:51:23 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF020D7009@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "List Iptel (E-mail)" <iptel@lists.bell-labs.com>
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [IPTEL] First cut at agenda for SLC IETF
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Tue, 27 Nov 2001 12:51:22 -0500

Folks,

Here is my first cut at an agenda for our meeting at Salt Lake City:

IP Telephony Working Group (iptel)

Tuesday, December 11 at 1415 - 1515
===================================

CHAIR: Jonathan Rosenberg <jdrosen@dynamicsoft.com>

AGENDA:

1. Agenda Bashing [Rosenberg]          
2. CPL, TRIP Updates  [Rosenberg]      5m
3. TRIP MIB [?]                        ?
4. Gateway Registration

     Scenarios Discussion 
       [?]                             10m
      
     Requirements Discussion
       [?]                             30m

     Attributes Discussion
       [?]                             10m




Some points to note:

* I don't know if there will be a MIB discussion; I am still trying to find
out who is going and whether an update was submitted.

* I want to break the Gateway registration discussion into three parts. The
first is a scenarios discussion. I'd like to take volunteers to each give a
slide or two on particular scenarios that they are interested in addressing.
The next is a requirements discussion, which will go through functional
requirements to get agreement or not on them. Last is the attributes (things
like total capacity, current capacity, etc.) to get agreement on those. I
want the TBD editor of the functional requirements doc to lead the
requirements discussion, I haven't decided who will lead the attributes
discussion. I am trying to personally not do all of that; iptel has had a
tendency to devolve into a Rosenberg monologue a few times and I don't want
that. 

* I only want to discuss requirements or attributes that have been presented
to the list previously. Same with scenarios. We have less than two weeks
till IETF. Let us please get functional requirements and attribute
discussions on the list. 


If you have anything else you want to discuss, let me know.

Thanks,
Jonathan R.

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

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Tue Nov 27 13:13:09 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14704
	for <iptel-archive@odin.ietf.org>; Tue, 27 Nov 2001 13:13:09 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id CA5D9443A1; Tue, 27 Nov 2001 12:02:01 -0500 (EST)
Delivered-To: iptel@lists.bell-labs.com
Received: from mail1.dynamicsoft.com (unknown [63.113.40.10])
	by lists.bell-labs.com (Postfix) with ESMTP id C5A08443AD
	for <iptel@lists.bell-labs.com>; Tue, 27 Nov 2001 12:01:04 -0500 (EST)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fARIAf7x011031;
	Tue, 27 Nov 2001 13:10:41 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <XH6R4PYD>; Tue, 27 Nov 2001 13:12:08 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF020D700F@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Roy, Radhika R, ALCTA'" <rrroy@att.com>,
        Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Cc: iptel@lists.bell-labs.com
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [IPTEL] RE: Requirements for Gateway Registration I-D
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Tue, 27 Nov 2001 13:12:07 -0500



 

> -----Original Message-----
> From: Roy, Radhika R, ALCTA [mailto:rrroy@att.com]
> Sent: Monday, November 26, 2001 9:07 AM
> To: jdrosen@dynamicsoft.com
> Cc: iptel@lists.bell-labs.com
> Subject: Requirements for Gateway Registration I-D
> 
> 
> Hi, Jonathan:
> 
> I have the following comments for the I-D
> <draft-rosenberg-iptel-gwreq-req-00.txt>:
> 
> 1. The title should rather be " Requirements for intra-ITAD 
> communications
> protocol," because the protocol needs to do discovery, 
> registration, and
> communications among the gateways (GWs) and location servers (LSs).

No. I have posted a note today on this; general intra-domain operation is
OUT OF SCOPE.

> 2. Figure 1 should be modified to show that a GW can be 
> Telephony gateway
> (IP-PSTN) or SIP-H.323 interworking gateway (IP-IP).

It is not clear to me that this is a requirement. Work so far has focused on
telephony gateways. Certainly the attributes will be significantly
different. Its not clear to me that the framework of this problem is
generally the same either. If you include SIP-H.323 gateways, would you
include SIP proxies? Both are signaling intermediaries that may server a
subset of addresses. However, I do not think those are in scope. As neither
SIP-H.323 gateways or proxies handle media, their notions of capacities and
load are much different. If the framework we build would support such things
by defining a different attribute set, great, but we are not designing
towards that in my opinion.


> 3. The requirements should reflect that a GW can have the 
> addresses of email
> IDs and URL IDs and others in addition to Telephone addresses.

See above.

> 4. One additional requirement needs to be added: Synchronization of
> information among the location servers.

No. See my response to (1).


> 
> In addition, we may also say that preferences will be given 
> for selection of
> the protocol in its "simplicity" and "efficiency" that can be 
> used as an
> "extension" or "subset" of TRIP protocol in satisfying the 
> requirements.

Choosing a protocol that is simple and efficient is a goal for all protocol
design work. I see no need to restate that. Whether to use an extension or
subset of TRIP is not a requirement, its a design choice. This document is
not about protocol design, its about high level reuqirements.

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

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Tue Nov 27 16:21:12 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25288
	for <iptel-archive@odin.ietf.org>; Tue, 27 Nov 2001 16:21:12 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id C3A8644375; Tue, 27 Nov 2001 15:10:02 -0500 (EST)
Delivered-To: iptel@lists.bell-labs.com
Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69])
	by lists.bell-labs.com (Postfix) with ESMTP id D096844372
	for <iptel@lists.bell-labs.com>; Tue, 27 Nov 2001 15:09:20 -0500 (EST)
Received: from gab200r1.ems.att.com ([135.37.94.32])
	by ckmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id fARLJrZ15082;
	Tue, 27 Nov 2001 16:19:53 -0500 (EST)
Received: from njb140bh1.ems.att.com by gab200r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2)
	id QAA14363; Tue, 27 Nov 2001 16:20:23 -0500 (EST)
Received: by njb140bh1.ems.att.com with Internet Mail Service (5.5.2653.19)
	id <XJ1TP48G>; Tue, 27 Nov 2001 16:19:51 -0500
Message-ID: <62DA45D4963FA747BA1B253E266760F958C3F7@OCCLUST04EVS1.ugd.att.com>
From: "Roy, Radhika R, ALCTA" <rrroy@att.com>
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Cc: iptel@lists.bell-labs.com
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [IPTEL] RE: Requirements for Gateway Registration I-D
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Tue, 27 Nov 2001 16:18:20 -0500


-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent: Tuesday, November 27, 2001 1:12 PM
To: Roy, Radhika R, ALCTA; Jonathan Rosenberg
 

> -----Original Message-----
> From: Roy, Radhika R, ALCTA [mailto:rrroy@att.com]
> Sent: Monday, November 26, 2001 9:07 AM
> To: jdrosen@dynamicsoft.com
> Cc: iptel@lists.bell-labs.com
> Subject: Requirements for Gateway Registration I-D
> 
> 
> Hi, Jonathan:
> 
> I have the following comments for the I-D
> <draft-rosenberg-iptel-gwreq-req-00.txt>:
> 
> 1. The title should rather be " Requirements for intra-ITAD 
> communications
> protocol," because the protocol needs to do discovery, 
> registration, and
> communications among the gateways (GWs) and location servers (LSs).

No. I have posted a note today on this; general intra-domain operation is
OUT OF SCOPE.

[RRR] If there is more than one LS in an ITAD, a proprietary protocol will
be used. Or, are you suggesting I-TRIP need to be used?

> 2. Figure 1 should be modified to show that a GW can be 
> Telephony gateway
> (IP-PSTN) or SIP-H.323 interworking gateway (IP-IP).

It is not clear to me that this is a requirement. Work so far has focused on
telephony gateways. 

[RRR] Can you define what the telephony GW is? 

[RRR] Is it the MGC of MEGACO (or MGCP)? If it is, MGC is a signaling entity
and the media GW (MGW) will handle the media/circuits and, they are separate
entities. However, a MGC provides all the information related to the MGW
(its capacity, and other attributes). A LS will communicate with the MGC
(not with the MGW).

Certainly the attributes will be significantly
different. Its not clear to me that the framework of this problem is
generally the same either. 

[RRR] Whatever attributes are needed, these attributes are passed by the
signaling entity (e.g., MGC), not the media entity (e.g., MGW).

If you include SIP-H.323 gateways, would you
include SIP proxies? 

[RRR] Why do I want to include SIP Proxy? SIP Proxy is handling the SIP
protocol only, it is not doing any protocol conversion. However, a SIP proxy
can talk to a SIP-H.323 IWF or MGC using SIP protocol (by the way, if the
SIP protocol would allow the registration of the GW, like H.323, we would
not go through unnecessary difficulties for registration). Similarly, a
location server (LS) will also talk to the SIP-H.323 IWF or MGC to get the
necessary information. Am I missing anything?

Both are signaling intermediaries that may server a
subset of addresses. However, I do not think those are in scope. 

[RRR] I am completely lost here. Can you be more specific?

As neither
SIP-H.323 gateways or proxies handle media, their notions of capacities and
load are much different. 

[RRR] A SIP-H.323 IWF or MGC will have the necessary information to pass to
the location servers.

If the framework we build would support such things
by defining a different attribute set, great, but we are not designing
towards that in my opinion.

[RRR] Could please clarify this?

> 3. The requirements should reflect that a GW can have the 
> addresses of email
> IDs and URL IDs and others in addition to Telephone addresses.

See above.

[RRR] Like any other attributes, email IDs, URL IDs, etc. can also be
passed.

> 4. One additional requirement needs to be added: Synchronization of
> information among the location servers.

No. See my response to (1).

[RRR] It is not a big deal. We are defining communications between the GW
and the LS. In the same token, the LS to LS communication can also be done
using the same sets of messages that are being used between the GW and the
LS (e.g., TRIP is doing. All we need to do here is to use the same or
similar messages, but do not do any route propagation). All LSs remain
within an ITAD. An ITAD has already been defined in the TRIP framework
document.

> 
> In addition, we may also say that preferences will be given 
> for selection of
> the protocol in its "simplicity" and "efficiency" that can be 
> used as an
> "extension" or "subset" of TRIP protocol in satisfying the 
> requirements.

Choosing a protocol that is simple and efficient is a goal for all protocol
design work. I see no need to restate that. Whether to use an extension or
subset of TRIP is not a requirement, its a design choice. This document is
not about protocol design, its about high level reuqirements.

[RRR] It is a fair statement. That does not mean we SHOULD only define one
message like "REGISTRATION/OPEN." (We will not use LS to LS communications,
we will not use auto-DISCOVERY, what else is left to define.)

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

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Tue Nov 27 16:33:12 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25833
	for <iptel-archive@odin.ietf.org>; Tue, 27 Nov 2001 16:33:11 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 110504439F; Tue, 27 Nov 2001 15:22:03 -0500 (EST)
Delivered-To: iptel@lists.bell-labs.com
Received: from mail1.dynamicsoft.com (unknown [63.113.40.10])
	by lists.bell-labs.com (Postfix) with ESMTP id BCBE444372
	for <iptel@lists.bell-labs.com>; Tue, 27 Nov 2001 15:21:55 -0500 (EST)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fARLVS7x012820;
	Tue, 27 Nov 2001 16:31:28 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <XH6R4QSG>; Tue, 27 Nov 2001 16:32:55 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF020D7024@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Roy, Radhika R, ALCTA'" <rrroy@att.com>
Cc: iptel@lists.bell-labs.com
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [IPTEL] RE: Requirements for Gateway Registration I-D
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Tue, 27 Nov 2001 16:32:54 -0500



 

> -----Original Message-----
> From: Roy, Radhika R, ALCTA [mailto:rrroy@att.com]
> Sent: Tuesday, November 27, 2001 4:18 PM
> To: Jonathan Rosenberg
> Cc: iptel@lists.bell-labs.com
> Subject: RE: Requirements for Gateway Registration I-D
> 
> > 1. The title should rather be " Requirements for intra-ITAD 
> > communications
> > protocol," because the protocol needs to do discovery, 
> > registration, and
> > communications among the gateways (GWs) and location servers (LSs).
> 
> No. I have posted a note today on this; general intra-domain 
> operation is
> OUT OF SCOPE.
> 
> [RRR] If there is more than one LS in an ITAD, a proprietary 
> protocol will
> be used. Or, are you suggesting I-TRIP need to be used?

I am suggesting exactly what I posted. THis work is OUT OF SCOPE for this
working group. That means we are not addressing it. 

> 
> > 2. Figure 1 should be modified to show that a GW can be 
> > Telephony gateway
> > (IP-PSTN) or SIP-H.323 interworking gateway (IP-IP).
> 
> It is not clear to me that this is a requirement. Work so far 
> has focused on
> telephony gateways. 
> 
> [RRR] Can you define what the telephony GW is? 
> 
> [RRR] Is it the MGC of MEGACO (or MGCP)? If it is, MGC is a 
> signaling entity
> and the media GW (MGW) will handle the media/circuits and, 
> they are separate
> entities. However, a MGC provides all the information related 
> to the MGW
> (its capacity, and other attributes). A LS will communicate 
> with the MGC
> (not with the MGW).

Its something for which attributes like total capacity, current capacity,
PDD and ASR are sane attributes to describe. Whether that element is
decomposed or not is irrelevant.

> If you include SIP-H.323 gateways, would you
> include SIP proxies? 
> 
> [RRR] Why do I want to include SIP Proxy? SIP Proxy is 
> handling the SIP
> protocol only, it is not doing any protocol conversion. 
> However, a SIP proxy
> can talk to a SIP-H.323 IWF or MGC using SIP protocol (by the 
> way, if the
> SIP protocol would allow the registration of the GW, like 
> H.323, we would
> not go through unnecessary difficulties for registration). 
> Similarly, a
> location server (LS) will also talk to the SIP-H.323 IWF or 
> MGC to get the
> necessary information. Am I missing anything?

Yes. I am trying to determine where you draw the line of the type of server
elements supported by the gateway registration protocol. I would argue that
it is very hard to differentiate a SIP proxy from a SIP-H.323 IWF through
external behaviors, metrics that define capacity, etc.

> As neither
> SIP-H.323 gateways or proxies handle media, their notions of 
> capacities and
> load are much different. 
> 
> [RRR] A SIP-H.323 IWF or MGC will have the necessary 
> information to pass to
> the location servers.

Your response is nonsensical. A SIP-H.323 IWF doesn't handle media. In that
regards, its like a proxy. Thus, metrics for measuring its capacity (in
terms of DS0, for example) are not the same as the ways you'd measure the
capacity of a PSTN gateway.

> 
> If the framework we build would support such things
> by defining a different attribute set, great, but we are not designing
> towards that in my opinion.
> 
> [RRR] Could please clarify this?

We are not designing a general purpose protocol for discovery of, and load
balancing across, servers. We are focusing on one type of server, PSTN
gateways. If the solution happens to be sturecutre in such a way that it can
work for other servers, great. But, that is not a goal we are working
towards.

> 
> > 3. The requirements should reflect that a GW can have the 
> > addresses of email
> > IDs and URL IDs and others in addition to Telephone addresses.
> 
> See above.
> 
> [RRR] Like any other attributes, email IDs, URL IDs, etc. can also be
> passed.

Not if its just a PSTN gateway.

> 
> > 4. One additional requirement needs to be added: Synchronization of
> > information among the location servers.
> 
> No. See my response to (1).
> 
> [RRR] It is not a big deal. We are defining communications 
> between the GW
> and the LS. In the same token, the LS to LS communication can 
> also be done
> using the same sets of messages that are being used between 
> the GW and the
> LS (e.g., TRIP is doing. 

That is an assumption of monstrous proportions.

You have a totally different view of what an intra-domain protocol is than I
do. In my view, it is more like the inter-domain problem. I suspect both of
our views are different from others in the group. This problem is not yet
sufficiently defined to start work on protocol specifications. Furthermore,
we are not chartered to do it. So, it is out of scope. Period. It is also
therefore out of scope to argue about what the intra-domain problem is.




> Choosing a protocol that is simple and efficient is a goal 
> for all protocol
> design work. I see no need to restate that. Whether to use an 
> extension or
> subset of TRIP is not a requirement, its a design choice. 
> This document is
> not about protocol design, its about high level reuqirements.
> 
> [RRR] It is a fair statement. That does not mean we SHOULD 
> only define one
> message like "REGISTRATION/OPEN." (We will not use LS to LS 
> communications,
> we will not use auto-DISCOVERY, what else is left to define.)

Your response makes no sense to me. The charter defines a problem. We will
first determine requirements for the solution, and then define the protocol.
I don't know how to explain that more clearly.

-Jonathan R.

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

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Tue Nov 27 17:29:11 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27765
	for <iptel-archive@odin.ietf.org>; Tue, 27 Nov 2001 17:29:09 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 9CEE244399; Tue, 27 Nov 2001 16:18:02 -0500 (EST)
Delivered-To: iptel@lists.bell-labs.com
Received: from kcmso1.proxy.att.com (kcmso1.att.com [192.128.133.69])
	by lists.bell-labs.com (Postfix) with ESMTP id 41C9344398
	for <iptel@lists.bell-labs.com>; Tue, 27 Nov 2001 16:17:05 -0500 (EST)
Received: from njb140r1.ems.att.com ([135.65.202.58])
	by kcmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id fARMS4x12344;
	Tue, 27 Nov 2001 17:28:04 -0500 (EST)
Received: from njb140bh2.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2)
	id RAA11948; Tue, 27 Nov 2001 17:26:44 -0500 (EST)
Received: by NJB140BH2 with Internet Mail Service (5.5.2653.19)
	id <XJGD4PLM>; Tue, 27 Nov 2001 17:28:03 -0500
Message-ID: <62DA45D4963FA747BA1B253E266760F958C4C9@OCCLUST04EVS1.ugd.att.com>
From: "Roy, Radhika R, ALCTA" <rrroy@att.com>
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Cc: iptel@lists.bell-labs.com
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [IPTEL] RE: Requirements for Gateway Registration I-D
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Tue, 27 Nov 2001 17:27:20 -0500



-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent: Tuesday, November 27, 2001 4:33 PM
To: Roy, Radhika R, ALCTA
Cc: iptel@lists.bell-labs.com
Subject: RE: Requirements for Gateway Registration I-D


> -----Original Message-----
> From: Roy, Radhika R, ALCTA [mailto:rrroy@att.com]
> Sent: Tuesday, November 27, 2001 4:18 PM
> To: Jonathan Rosenberg
> Cc: iptel@lists.bell-labs.com
> Subject: RE: Requirements for Gateway Registration I-D
> 
> > 1. The title should rather be " Requirements for intra-ITAD 
> > communications
> > protocol," because the protocol needs to do discovery, 
> > registration, and
> > communications among the gateways (GWs) and location servers (LSs).
> 
> No. I have posted a note today on this; general intra-domain 
> operation is
> OUT OF SCOPE.
> 
> [RRR] If there is more than one LS in an ITAD, a proprietary 
> protocol will
> be used. Or, are you suggesting I-TRIP need to be used?

I am suggesting exactly what I posted. THis work is OUT OF SCOPE for this
working group. That means we are not addressing it. 

[RRR] Please see my answers provided below.

> 
> > 2. Figure 1 should be modified to show that a GW can be 
> > Telephony gateway
> > (IP-PSTN) or SIP-H.323 interworking gateway (IP-IP).
> 
> It is not clear to me that this is a requirement. Work so far 
> has focused on
> telephony gateways. 
> 
> [RRR] Can you define what the telephony GW is? 
> 
> [RRR] Is it the MGC of MEGACO (or MGCP)? If it is, MGC is a 
> signaling entity
> and the media GW (MGW) will handle the media/circuits and, 
> they are separate
> entities. However, a MGC provides all the information related 
> to the MGW
> (its capacity, and other attributes). A LS will communicate 
> with the MGC
> (not with the MGW).

Its something for which attributes like total capacity, current capacity,
PDD and ASR are sane attributes to describe. Whether that element is
decomposed or not is irrelevant.

[RRR] Good. We are in agreement.

> If you include SIP-H.323 gateways, would you
> include SIP proxies? 
> 
> [RRR] Why do I want to include SIP Proxy? SIP Proxy is 
> handling the SIP
> protocol only, it is not doing any protocol conversion. 
> However, a SIP proxy
> can talk to a SIP-H.323 IWF or MGC using SIP protocol (by the 
> way, if the
> SIP protocol would allow the registration of the GW, like 
> H.323, we would
> not go through unnecessary difficulties for registration). 
> Similarly, a
> location server (LS) will also talk to the SIP-H.323 IWF or 
> MGC to get the
> necessary information. Am I missing anything?

Yes. I am trying to determine where you draw the line of the type of server
elements supported by the gateway registration protocol. I would argue that
it is very hard to differentiate a SIP proxy from a SIP-H.323 IWF through
external behaviors, metrics that define capacity, etc.

[RRR] Please see my answers provided below. (If I recollect your email in
the SIP-H.323-eGroup, you advocated that SIP-H.323 IWF will also be allowed
to register when the GW registration protocol is developed.)

> As neither
> SIP-H.323 gateways or proxies handle media, their notions of 
> capacities and
> load are much different. 
> 
> [RRR] A SIP-H.323 IWF or MGC will have the necessary 
> information to pass to
> the location servers.

Your response is nonsensical. A SIP-H.323 IWF doesn't handle media. In that
regards, its like a proxy. Thus, metrics for measuring its capacity (in
terms of DS0, for example) are not the same as the ways you'd measure the
capacity of a PSTN gateway.

[RRR] No one is saying that the capacity attributes for SIP-H.323 IWF and
the MGC (PSTN GW) should be the same. For SIP-H.323 IWF, it may be limited
to port capacity or like this, if it is (but not sure). Here (SIP-H.323
IWF), we are primarily concerned with the addresses only.

> 
> If the framework we build would support such things
> by defining a different attribute set, great, but we are not designing
> towards that in my opinion.
> 
> [RRR] Could please clarify this?

We are not designing a general purpose protocol for discovery of, and load
balancing across, servers. We are focusing on one type of server, PSTN
gateways. If the solution happens to be sturecutre in such a way that it can
work for other servers, great. But, that is not a goal we are working
towards.

[RRR] If I recollect your email in the SIP-H.323-eGroup, you also mentioned
that we will be working for registration of the GWs including PSTN and
SIP-H.323, because the registration of the GW is a generic problem. Now the
question is: If we can register the PSTN GW, why can we not register the
SIP-H.323 IWF? The only difference is that a SIP-H.323 IWF does not need to
use all capacity attributes that a PSTN GW does. In the same token, a PSTN
GW does not need to use the email IDs, or URL IDs.

> 
> > 3. The requirements should reflect that a GW can have the 
> > addresses of email
> > IDs and URL IDs and others in addition to Telephone addresses.
> 
> See above.
> 
> [RRR] Like any other attributes, email IDs, URL IDs, etc. can also be
> passed.

Not if its just a PSTN gateway.

[RRR] But we are defining a " GW registration" protocol for broader use. We
are not defining "PSTN GW REGISTRATION" protocol, I believe. There is a
fundamental difference in your understanding how to define the registration
protocol. One MUST not mandate to develop a protocol for such a narrow use.
It will be unacceptable from standardization point of view.

> 
> > 4. One additional requirement needs to be added: Synchronization of
> > information among the location servers.
> 
> No. See my response to (1).
> 
> [RRR] It is not a big deal. We are defining communications 
> between the GW
> and the LS. In the same token, the LS to LS communication can 
> also be done
> using the same sets of messages that are being used between 
> the GW and the
> LS (e.g., TRIP is doing. 

That is an assumption of monstrous proportions.

You have a totally different view of what an intra-domain protocol is than I
do. In my view, it is more like the inter-domain problem. I suspect both of
our views are different from others in the group. This problem is not yet
sufficiently defined to start work on protocol specifications.

[RRR] Again, I am saying that there are more than one LS in an ITAD. How do
you say that it is an inter-domain protocol? Does not the TRIP framework
document define that there can be multiple LSs in a given ITAD?

Furthermore,
we are not chartered to do it. So, it is out of scope. Period. It is also
therefore out of scope to argue about what the intra-domain problem is.

[RRR] I can rather accept this argument: Whether this is charter item or
not. It appears that the communication protocol between the GWs and the LSs
within an ITAD is a chartered item. However, the communication protocol
among the LSs is NOT a chartered item. (What I am arguing is that the
communications protocol among the LSs will not be a different one once we
complete the communication protocol between the GWs and LSs. I will wait to
see the development of the communication protocol between GWs and the LSs.)


> Choosing a protocol that is simple and efficient is a goal 
> for all protocol
> design work. I see no need to restate that. Whether to use an 
> extension or
> subset of TRIP is not a requirement, its a design choice. 
> This document is
> not about protocol design, its about high level reuqirements.
> 
> [RRR] It is a fair statement. That does not mean we SHOULD 
> only define one
> message like "REGISTRATION/OPEN." (We will not use LS to LS 
> communications,
> we will not use auto-DISCOVERY, what else is left to define.)

Your response makes no sense to me. The charter defines a problem. We will
first determine requirements for the solution, and then define the protocol.
I don't know how to explain that more clearly.

[RRR] Let us define the charter.

-Jonathan R.

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

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Tue Nov 27 18:06:15 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28844
	for <iptel-archive@odin.ietf.org>; Tue, 27 Nov 2001 18:06:15 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 3628544397; Tue, 27 Nov 2001 16:55:03 -0500 (EST)
Delivered-To: iptel@lists.bell-labs.com
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by lists.bell-labs.com (Postfix) with ESMTP id 4E90344396
	for <iptel@lists.bell-labs.com>; Tue, 27 Nov 2001 16:54:56 -0500 (EST)
Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.24.14])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id fARN62d12425;
	Tue, 27 Nov 2001 15:06:02 -0800 (PST)
Received: from cisco.com (dhcp-128-107-139-114.cisco.com [128.107.139.114])
	by mira-sjcm-2.cisco.com (Mirapoint)
	with ESMTP id AAW29046;
	Tue, 27 Nov 2001 15:06:00 -0800 (PST)
Message-ID: <3C041C19.8AD6BF2C@cisco.com>
From: Manjunath S Bangalore <manjax@cisco.com>
Organization: Cisco Systems
X-Mailer: Mozilla 4.5 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "ANDERSON, DARBY (SBCTI)" <da7461@sbc.com>
Cc: iptel@lists.bell-labs.com
Subject: Re: [IPTEL] IPTEL TRIP-GW draft
References: <C739248D6A6FD211B1940008C7A4752C09536F2B@d072038.sbc.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Tue, 27 Nov 2001 15:04:58 -0800
Content-Transfer-Encoding: 7bit


 Before Carrier Codes were introduced in TRIP-GW, routing was done primarily on
telephony prefixes. With Carrier information advertised in TRIP-GW as described
in the new draft, calls can be routed using a combination of the two.

 With carrier information being advertised in TRIP-GW, the Location Server has
information about the different carriers on which a given telephony prefix can
be terminated on. There will possibly be a Carrier-based routing policy in
place for the provider's domain as a whole which will determine which carrier
to use for a call. This could be a result of different factors like agreements
that exist between the ITSP and different Carriers, based on matching the
inbound and outbound carriers, based on the number of minutes terminated on a
carrier, Percentage-based distribution to different carriers, Least cost
considerations, etc.

> What if someone outpulses digits to a gateway with a FG-D CIC in it, will
> the gateway route the call on that CIC, or will there be some type of a
> parameter in either the Voice G/W, or the RouteServ to implicitly deny
> FG-B/FG-D Dial arrounds??

When the GW receives a call with a particular CIC, like you mentioned, that
information will be used in conjunction with the prefix to arrive at a route(s)
that terminate on the indicated carrier.  The LS/Proxy processing such a call
will forward it to domains that have advertised routes for that prefix
terminating on that carrier.

>
> Also in reguards to trunking, how will TG's be tracked on the RouteServ for
> traffic sculpting, and billing purposes??

A Route Server can keep informed about TrunkGroups by propogating the
information from the gateways on I-TRIP as described in the draft Or it can be
provisioned by ways, outside of TRIP, by static means, for example.

The new draft introduces the concept of a Carrier to facilitate Routing based
on Carrier preferences. Secondly, it provides the flexibility to report dynamic
characteristics of the gateway at the granularity of a Carrier or Carrier/Trunk
group combination to pave the way for scalable gateway management.

Regards,
-Manjax




_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Wed Nov 28 13:24:17 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27385
	for <iptel-archive@odin.ietf.org>; Wed, 28 Nov 2001 13:24:17 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id EDB46443B4; Wed, 28 Nov 2001 12:13:01 -0500 (EST)
Delivered-To: iptel@lists.bell-labs.com
Received: from smtp2.gtsgroup.com (smtp2.gtsgroup.com [195.158.230.80])
	by lists.bell-labs.com (Postfix) with SMTP id AA9B544395
	for <iptel@lists.bell-labs.com>; Wed, 28 Nov 2001 12:12:21 -0500 (EST)
Received: from 207.77.231.73 by smtp2.gtsgroup.com (InterScan E-Mail VirusWall NT); Wed, 28 Nov 2001 18:23:26 -0000
Received: by brubhdpnt01.gtsgroup.com with Internet Mail Service (5.5.2653.19)
	id <XVKLLHFL>; Wed, 28 Nov 2001 19:23:26 +0100
Message-ID: <D52BF6463BA3D311BFA700508B63C5AA05109EE7@brumsgpnt01.gtsgroup.com>
From: "Agboh, Charles" <Charles.Agboh@ebone.com>
To: "'Jonathan Rosenberg'" <jdrosen@dynamicsoft.com>,
        "'Roy, Radhika R, ALCTA'" <rrroy@att.com>
Cc: iptel@lists.bell-labs.com
Subject: RE: [IPTEL] RE: Requirements for Gateway Registration I-D
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Wed, 28 Nov 2001 19:23:25 +0100



> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: Tuesday, November 27, 2001 10:33 PM
> To: 'Roy, Radhika R, ALCTA'
> Cc: iptel@lists.bell-labs.com
> Subject: [IPTEL] RE: Requirements for Gateway Registration I-D
> 
> 
> 
> 
>  
> 
> > -----Original Message-----
> > From: Roy, Radhika R, ALCTA [mailto:rrroy@att.com]
> > Sent: Tuesday, November 27, 2001 4:18 PM
> > To: Jonathan Rosenberg
> > Cc: iptel@lists.bell-labs.com
> > Subject: RE: Requirements for Gateway Registration I-D
> > 
> > > 1. The title should rather be " Requirements for intra-ITAD 
> > > communications
> > > protocol," because the protocol needs to do discovery, 
> > > registration, and
> > > communications among the gateways (GWs) and location 
> servers (LSs).
> > 
> > No. I have posted a note today on this; general intra-domain 
> > operation is
> > OUT OF SCOPE.
> > 
> > [RRR] If there is more than one LS in an ITAD, a proprietary 
> > protocol will
> > be used. Or, are you suggesting I-TRIP need to be used?
> 
> I am suggesting exactly what I posted. THis work is OUT OF 
> SCOPE for this
> working group. That means we are not addressing it. 
> 
> > 
> > > 2. Figure 1 should be modified to show that a GW can be 
> > > Telephony gateway
> > > (IP-PSTN) or SIP-H.323 interworking gateway (IP-IP).
> > 
> > It is not clear to me that this is a requirement. Work so far 
> > has focused on
> > telephony gateways. 
> > 
> > [RRR] Can you define what the telephony GW is? 
> > 
> > [RRR] Is it the MGC of MEGACO (or MGCP)? If it is, MGC is a 
> > signaling entity
> > and the media GW (MGW) will handle the media/circuits and, 
> > they are separate
> > entities. However, a MGC provides all the information related 
> > to the MGW
> > (its capacity, and other attributes). A LS will communicate 
> > with the MGC
> > (not with the MGW).
> 
> Its something for which attributes like total capacity, 
> current capacity,
> PDD and ASR are sane attributes to describe. Whether that element is
> decomposed or not is irrelevant.
> 
> > If you include SIP-H.323 gateways, would you
> > include SIP proxies? 
> > 
> > [RRR] Why do I want to include SIP Proxy? SIP Proxy is 
> > handling the SIP
> > protocol only, it is not doing any protocol conversion. 
> > However, a SIP proxy
> > can talk to a SIP-H.323 IWF or MGC using SIP protocol (by the 
> > way, if the
> > SIP protocol would allow the registration of the GW, like 
> > H.323, we would
> > not go through unnecessary difficulties for registration). 
> > Similarly, a
> > location server (LS) will also talk to the SIP-H.323 IWF or 
> > MGC to get the
> > necessary information. Am I missing anything?
> 
> Yes. I am trying to determine where you draw the line of the 
> type of server
> elements supported by the gateway registration protocol. I 
> would argue that
> it is very hard to differentiate a SIP proxy from a SIP-H.323 
> IWF through
> external behaviors, metrics that define capacity, etc.
> 
> > As neither
> > SIP-H.323 gateways or proxies handle media, their notions of 
> > capacities and
> > load are much different. 
> > 
> > [RRR] A SIP-H.323 IWF or MGC will have the necessary 
> > information to pass to
> > the location servers.
> 
> Your response is nonsensical. A SIP-H.323 IWF doesn't handle 
> media.   

The SIP-H.323 IWF might be co-located with a Media Switching Fabric for
transcoding or sitting between multicast and unicast domains.  The
Requirements should catter for this type of IWF.    Customer security
requirements might also dictate that we use an IWF with an MSF.  Seems like
SIPPING should give this group input on requirements..

>In that
> regards, its like a proxy. Thus, metrics for measuring its 
> capacity (in
> terms of DS0, for example) are not the same as the ways you'd 
> measure the
> capacity of a PSTN gateway.
The capacity of a proxy can be calculated as a function of the media
gateway.   I aggree they are not the same but they are related.  For exmaple
when I want to calculate investments for a call control layer for an IP
Telephony VPN, I might make the following assumptions

-80% of calls are intra-VPN in an Enterprise environment.
- assume a 60% usage rate on each CPE channel
 and
make a plan calculating CCL investment as a function of CPE channels (CPE
channels * 60% * (0.2+1/2*0.8)) (the 1/2 accounts for the fact that for
intra VPN calls (80% here, there is only 1 call in the softswitch for 2 CPE
active channels).....
> > 
> > If the framework we build would support such things
> > by defining a different attribute set, great, but we are 
> not designing
> > towards that in my opinion.
> > 
> > [RRR] Could please clarify this?
> 
> We are not designing a general purpose protocol for discovery 
> of, and load
> balancing across, servers. We are focusing on one type of server, PSTN
> gateways. If the solution happens to be sturecutre in such a 

I don't believe that the solution should be focus on CO gateways.   PBX
switches generate very high call volumes between different branch
offices..Scalability and load balancing important requirements for this
environment.  Imagine I have 10 branch offices per customer and my forcasts
is 200 customers by end 2002....
> way that it can
> work for other servers, great. But, that is not a goal we are working
> towards.
> 
> > 
> > > 3. The requirements should reflect that a GW can have the 
> > > addresses of email
> > > IDs and URL IDs and others in addition to Telephone addresses.
> > 
> > See above.
> > 
> > [RRR] Like any other attributes, email IDs, URL IDs, etc. 
> can also be
> > passed.
> 
> Not if its just a PSTN gateway.
> 
> > 
> > > 4. One additional requirement needs to be added: 
> Synchronization of
> > > information among the location servers.
> > 
> > No. See my response to (1).
> > 
> > [RRR] It is not a big deal. We are defining communications 
> > between the GW
> > and the LS. In the same token, the LS to LS communication can 
> > also be done
> > using the same sets of messages that are being used between 
> > the GW and the
> > LS (e.g., TRIP is doing. 
> 
> That is an assumption of monstrous proportions.
> 
> You have a totally different view of what an intra-domain 
> protocol is than I
> do. In my view, it is more like the inter-domain problem. I 
> suspect both of
> our views are different from others in the group. This 
> problem is not yet
> sufficiently defined to start work on protocol 
> specifications. Furthermore,
> we are not chartered to do it. So, it is out of scope. 
> Period. It is also
> therefore out of scope to argue about what the intra-domain 
> problem is.
> 
> 
> 
> 
> > Choosing a protocol that is simple and efficient is a goal 
> > for all protocol
> > design work. I see no need to restate that. Whether to use an 
> > extension or
> > subset of TRIP is not a requirement, its a design choice. 
> > This document is
> > not about protocol design, its about high level reuqirements.
> > 
> > [RRR] It is a fair statement. That does not mean we SHOULD 
> > only define one
> > message like "REGISTRATION/OPEN." (We will not use LS to LS 
> > communications,
> > we will not use auto-DISCOVERY, what else is left to define.)
> 
> Your response makes no sense to me. The charter defines a 
> problem. We will
> first determine requirements for the solution, and then 
> define the protocol.
> I don't know how to explain that more clearly.
> 
> -Jonathan R.
> 
> ---
> Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
> 
> _______________________________________________
> IPTEL mailing list
> IPTEL@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/iptel
> 

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Thu Nov 29 10:05:25 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08190
	for <iptel-archive@odin.ietf.org>; Thu, 29 Nov 2001 10:05:24 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id D430C443BC; Thu, 29 Nov 2001 08:54:02 -0500 (EST)
Delivered-To: iptel@lists.bell-labs.com
Received: from face.sentitonetworks.com (user9.sentito.com [65.202.222.9])
	by lists.bell-labs.com (Postfix) with SMTP id CD112443A9
	for <iptel@lists.bell-labs.com>; Thu, 29 Nov 2001 08:53:13 -0500 (EST)
Received: (qmail 16528 invoked from network); 29 Nov 2001 14:56:27 -0000
Received: from unknown (HELO SAJAK) (10.0.0.235)
  by face.sentito.com with SMTP; 29 Nov 2001 14:56:27 -0000
From: "Shan Lu" <shanlu@sentito.com>
To: "IPTEL Mailing List" <iptel@lists.bell-labs.com>
Message-ID: <001601c178e7$25718660$eb00000a@SAJAK>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3311
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal
Subject: [IPTEL] New I-D on Gateway Registration Using SIP
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Thu, 29 Nov 2001 10:04:30 -0500
Content-Transfer-Encoding: 7bit

Hi all,

We intend to submit the following internet draft after the current
blackout is over. For now, you can pick up a copy at:

http://www.sentito.com/IETF/draft-lu-telurl-wildcard-00.txt
http://www.sentito.com/IETF/draft-lu-telurl-wildcard-00.pdf

Abstract

This document proposes two extensions to the telephone URL scheme. With 
these extensions, phone numbers starting with a given prefix or 
spanning a given range can be represented. Their applications in SIP-
PSTN gateway and large SIP endpoint registrations are also discussed.

Regards,

Shan Lu
sentitO Networks  


_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Fri Nov 30 15:04:33 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03132
	for <iptel-archive@odin.ietf.org>; Fri, 30 Nov 2001 15:04:33 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 5A30F443CE; Fri, 30 Nov 2001 13:53:02 -0500 (EST)
Delivered-To: iptel@lists.bell-labs.com
Received: from pine.il.neustar.com (pine.neustar.com [209.173.57.70])
	by lists.bell-labs.com (Postfix) with ESMTP id 186FB443C9
	for <iptel@lists.bell-labs.com>; Fri, 30 Nov 2001 13:52:26 -0500 (EST)
Received: from chiimc01.il.neustar.com (dmz1.il.neustar.com [209.173.57.65])
	by pine.il.neustar.com (8.11.0/8.11.0) with ESMTP id fAUK3tU32273
	for <iptel@lists.bell-labs.com>; Fri, 30 Nov 2001 14:03:57 -0600
Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19)
	id <XKKAAGHX>; Fri, 30 Nov 2001 14:06:21 -0600
Message-ID: <70565611B164D511957A001083FCDD56CAACAD@va02.va.neustar.com>
From: "Peterson, Jon" <jon.peterson@neustar.biz>
To: "'iptel@lists.bell-labs.com'" <iptel@lists.bell-labs.com>
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [IPTEL] carrier scenario for TRIP
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Fri, 30 Nov 2001 14:06:04 -0600

I'd like to describe a particular scenario for gateway registration, namely,
a case in which it could be used by a large US-based VoIP carrier.

The sort of carrier network I'm envisioning is composed of entities
responsible for routing call setup requests (like SIP proxy servers) and
entities that generate and receive call setup requests (in the scope of this
problem, PSTN gateways). However, there are many different types of PSTN
gateways; the broad delineation is between media gateway controllers (that
manage 'dumb' gateways) and self-contained 'smart' gateways. The formal
distinction here between smart and dumb gateways is that smart gateways
speak the call setup protocol (like SIP) and presumably the gateway
registration protocol themselves, whereas dumb gateways speak only a device
control protocol (like Megaco), and rely on their MGC to handle call setup
and gateway registration protocols.

In the field, smart gateways commonly have low capacities (on the order of a
couple of DS1s) whereas the scale of dumb gateways can get very large (many
DS3s). High-density dumb gateways tend to have support for SS7 intermachine
trunks (IMTs), whereas low-density smart gateways often forgo IMT support
for ISDN PRI or MF support; the signaling channels for each PRI and MF
trunks physically terminate on the gateway, but SS7 requires a consolidated
point at which signaling arrives for the trunks associated with multiple
gateways, and hence is conducive to the MGC/dumb gateway model. Some very
low-density residential gateways support POTS lines on the DS0 level, but
I'm not considering them in this architecture.

For reasons of economics, operation and management, among others, large
carriers are predominantly SS7-based, so I'm going to assume that MGCs and
large dumb gateways constitute the majority of the network in this scenario.
Smaller smart gateways may also be sparing deployed in the network to face
specific resources (mostly PBXs).

                                                                        
                                                                          
                                                                          
                                                      Trunks              
  Gateway                                                                 
  Registration                                                            
                                                      IMT                 
  Carrier Architecture                         +----+ ---->   +1          
                                        (H.248)|    |                     
                                  Device +---- | GW1| ---->   +1703,+1571...

                                  Control|     |    |                     
                                         |     +----+ ---->   +1202,+1703...
[TG1] 
                                         |                                
                                         |            IMT                 
                                         |     +----+ ---->   +1          
                      (SIP)   +-----+    |     |    |                     
                 +----------->| MGC |----+-----| GW2| ---->   +1540,+1804...

                 |            +--+--+    |     |    |                     
                 |               |       |     +----+ ---->   +1202,+1703...
[TG1] 
                 |               |       |                                
  Call     +----------+          |       |            IMT                 
  Setup    |          |          |       |     +----+ ---->   +1          
  (SIP)    | Routing  |          |       |     |    |                     
  -------->| Proxy    |          |       +-----| GW3| ---->   +1202555,
+122544...       
           |    (LS)  |          |             |    |                     
           +----------+          |             +----+ ---->   +44         
               |   |             |  SS7                                   
               |   |             +------------------------>   TO PSTN     
               |   |                                                      
               |   |                                                      
               |   |                           +----+ PRI (B&D)           
               |   +-------------------------->| GW4| ---->  +1202533     
               |                               +----+                     
               |            (SIP)                                         
               |                               +----+ MF                  
               +-------------------------------> GW5| ---->  +1703989     
                                               +----+                     

In the above picture, I envision that the gateway registration protocol
would be spoken between all of the entities that speak SIP.

By way of explanation, the diagram above shows multiple bundles of DS0
circuits (we'll refer to them as trunks) associated with each of the large
dumb gateways (GW1, GW2 and GW3). One or more E.164 number ranges is
associated with each of these trunks. '+1' indicates that all of the United
States is reachable through this trunk (probably, this is a trunk to an
interexchange carrier). The second trunk on GW1 (pointed to +1703,+1571...)
contains a set of reachable area codes within a rate center, suggesting that
the trunk is associated with a LEC tandem. The second trunk on GW3 (pointed
to +1202555, +1202544...) is associated with a set of specific exchange
codes, and is therefore probably an end office trunk pointing to a class 5
switch. The smaller gateways (GW4 and GW5) have trunks that are associated
with customers, possibly PBXs. Finally, note that logical 'trunk groups' can
span multiple gateways, as is the case with [TG1], the third trunks on GW1
and GW2 (each pointing to +1202,+1703...). 

Jonathan noted that the charter permits gateway registration for 'the
exchange of dynamic information' rather than reliability or scalability. I
think it is important to note that the reason why the exchange of dynamic
information is interesting to a carrier network is that it facilitates
provisioning and network management. I don't think that autodiscovery of the
LS by MGCs or vice versa would really make this system substantially easier
to manage or provision in any obvious way.

To my mind, the fundamental question about gateway registration in this
architecture is 'what are the resources whose availability is advertised by
gateway registration?'. I think it needs to be some combination of the
following:

- Availability of a gateway itself. In the case in which an MGC performs
gateway registration, it could notify the LS of the availability of any
individual gateway (for example GW1 above). If a standalone gateway (like
GW4) does not go offline gracefully, then of course no gateway
de-registration message could be sent, but the LS would presumably have some
other mechanism (absence of keepalive messages) to determine that the
gateway is unavailable. Since an MGC is not coupled to physical trunk
resources, it can take advantage of reliability mechanisms that a standalone
gateway cannot, and therefore it is well positioned to broker availability
information for gateways. Either way, clearly the availability of gateway
themselves can be made known to the LS.

- Availability of a number prefix/address. This is the traditional TRIP
model, in which an E.164 range (e.g. '+1303') is propagated from the gateway
to the LS. This model works best, I think, in the case of standalone smart
gateways (like GW4). In the MGC case, it is harder to see what prefixes
should be propagated by the MGC to the LS - merely propagating that '+1' is
available through the MGC doesn't take into account the different policies
that are potentially available on different trunks. In other words, the big
open issue here is whether the MGC should aggregate routes on behalf of its
gateways or not, and if so, how. Also note that in order to allow for more
complex PSTN features, routing by location routing numbers and carrier
identification codes should also be permitted, and that the availability of
particular CICs or LRNs through an MGC should be advertised.

- Availability of a trunk/PSTN interface on a gateway. Gateways generally
have more than one physical interface capable of supporting a trunk. If a
trunk has been established on a physical interface, it will have one of many
dynamic states (more precisely, the states on a trunk are an aggregate of
the states of its constituent circuts if no trunk-level events are taking
place); trunks can be busy, administratively blocked, idle, and so forth.
Trunks also have many different static attributes (some of which are
detailed below). Clearly, the availability of particular number ranges in a
gateway is dependent on the availability of trunks (i.e. if the third trunk
on GW3 goes off-line, then the +44 country code will no longer be available
in the MGC). For the purposes of scalability, a more useful construct is a
logical set of circuits known as a trunk group which allows multiple trunks
(potentially on different physical interfaces) to be grouped under the same
set of attributes and policies. A trunk group can also span multiple
gateways (as [TG1] spans the third circuits of GW1 and GW2) in order to
provide greater reliability. Consider, for example, that if GW2 were to go
offline, the trunk group consisting of the third trunks of GW1 and GW2 would
still be available (with diminished capacity). Note that these properties of
trunk groups also generally apply to ISDN NFAS trunks.

I suspect that bundling number prefix/address-based routed into trunk groups
is the right way for an MGC to aggregate routes for delivery to an LS.

Many static attributes that proxy servers might use for routing decisions
have dependencies on trunk groups. Some that come to mind:

- A trunk group has directionality. It may be one-way inbound, one-way
outbound, or two-way.

- The protocol used to establish calls on the trunk. In some instances, VoIP
messages might rely on signaling mechanisms that are specific to a
particular PSTN termination protocol. A good example would be if number
portability information is present in the VoIP signaling data - this
information will be lost if the call terminates on a PRI trunk (possibly
resulting in an error condition).

Even addresses can usefully be construed as attributes of trunk group:

- There is one and only one carrier that is responsible for the switch on
the other side of the trunk. One or more carrier identification codes can be
associated with a carrier. Of course, other carriers are also probably
reachable through the remote carrier's network.

- Trunks to end offices may be associated with a location routing number
(LRN) used to route calls for local number portability. Each NP-compliant
end office switch in the (USA) PSTN is associated with one LRN.

Note that neither of these forms of address are international in scope, and
therefore the set of all the carrier identification codes in the world is
not reachable by an ISUP signal sent through an American trunk.

Interestingly, I think most of the dynamic information that would be
exchanged by gateway registration messages are attributes of trunk groups.
For instance:

- The total capacity of a trunk might seem like a static attribute, but over
the long term it is actually dynamic. Existing trunk groups are augmented.
The total capacity of a trunk group can change over time due to capacity
constraints. Large carriers are constantly in the process of augmenting
exist trunks. The addition of circuits to an existing trunk group is
preferable to creating new trunk groups when the attributes of the trunk
remain the same.

- Trunk groups fill up with calls. If a trunk group is one-way outbound,
then in some architectures an LS could track the congestion of particular
trunk groups itself without any gateway registration attributes. However, if
the trunk group is two-way, it is much more difficult for an LS to keep an
accurate count of idle circuits in a trunk group without reporting from
gateways. One of the difficult problems with propagating dynamic capacity is
the thresholds for reporting - sending a gateway registration message each
time the state of a single circuit changes is probably not feasible, so
perhaps some fuzzier states for the entire trunk group (e.g. 'almost full')
would be needed.

- Trunk groups are created and destroyed. Switches associated with major
carriers are in an almost constant state of creating trunk groups as
connections to new switches are required or connections to existing switches
require augmentation with distinct policies.

- Trunk groups have maintenance conditions - most notably blocking and
unblocking. Sending a block for a trunk group prevents new calls from being
received on the group. Blocking can be used when a hardware failure occurs
that takes a trunk out of service, or as a pre-emptive measure (quiescence)
to empty a trunk gradually.

That's probably a good start as far as describing the architecture goes.

Jon Peterson
NeuStar, Inc


_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Fri Nov 30 15:13:33 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03583
	for <iptel-archive@odin.ietf.org>; Fri, 30 Nov 2001 15:13:33 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id A553D443D8; Fri, 30 Nov 2001 14:02:02 -0500 (EST)
Delivered-To: iptel@lists.bell-labs.com
Received: from pine.il.neustar.com (pine.neustar.com [209.173.57.70])
	by lists.bell-labs.com (Postfix) with ESMTP id 2AC44443D6
	for <iptel@lists.bell-labs.com>; Fri, 30 Nov 2001 14:01:07 -0500 (EST)
Received: from chiimc01.il.neustar.com (dmz1.il.neustar.com [209.173.57.65])
	by pine.il.neustar.com (8.11.0/8.11.0) with ESMTP id fAUKCcU32685
	for <iptel@lists.bell-labs.com>; Fri, 30 Nov 2001 14:12:38 -0600
Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19)
	id <XKKAAGLK>; Fri, 30 Nov 2001 14:15:05 -0600
Message-ID: <70565611B164D511957A001083FCDD56CAACAF@va02.va.neustar.com>
From: "Peterson, Jon" <jon.peterson@neustar.biz>
To: "'iptel@lists.bell-labs.com'" <iptel@lists.bell-labs.com>
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [IPTEL] iptel-gwreg-req open issues
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Fri, 30 Nov 2001 14:14:48 -0600


A few comments on the open issues listed in the draft.

REQ 6- I think this is a real requirement. I think that in many complex
architectures (such as ones in which MGCs are used as gateways), the
provisioning of ranges of POTS numbers associated with gateways must be
performed in multiple locations (proxy servers and gateways, at least) if
there is not some sort of gwreg mechanism that allows you to provision in
one place and then automatically propagate the data to any other systems
that need it. In my opinion, simplifying provisioning is one of the primary
reasons to use gateway registration. If you have to substantially
pre-provision proxies then I don't think gateway registration makes your
life that much easier.

As a side note on 6, I'd like to say that I agree with Jonathan that
(monetary) cost should not be considered at this time, especially since
settlement is poorly understood overall in the VoIP community and the
construction of some sort of attribute that expresses monetary cost does
seem to be a labyrinthine rat-hole. But it's also important to acknowledge
that every trunk that goes to a PSTN switch is potentially a route to every
E.164 number prefix - reachability of POTS number addresses in the PSTN is
(with only some obscure exceptions) ubiquitous. By associating E.164 number
prefixes with routes we are introducing an artificial, administrative
restriction on the traffic that uses a route - we are expressing a sort of
preference. The primary reason why carriers do so is because the cost of
terminating a particular E.164 range over a given trunk may be especially
favorable. In this sense, I think that the idea of LocalPreference (and to
some degree monetary cost) is built-in to the idea of routing by E.164
ranges. Under duress (due to congestion or failure on more desirable
resources) most carriers would override these restrictions and route other
traffic over such trunks.

REQ 8- I really think the gwreg protocol should be extensible, even if we
aren't sure how we'd like to extend it at the moment. As for whether these
attributes are attributed to routes or gateways, I'd actually suggest a
third alternative for consideration - trunk groups. My carrier architecture
provides a few examples of how such dynamic data depends on trunk groups
rather than gateways.

REQ 11- I'm not sure I entirely understand either the requirement or the
open issue here, but I'll take a stab at this. Since we're considering gwreg
in the absence of intradomain route propagation, independent routing
policies amongst multiple proxies in an ITAD seems like an unlikely issue to
address - any system in which there's a possibility that there are
independent proxies that could somehow be synchronized requires something
like routing policy centralization or intradomain propagation.

Is the assumption here that if there are multiple proxies in an ITAD, that
some gateways register with one proxy, and some gateways register with
another, perhaps depending on a POP at which the gateways are located?
(Also, is there a latent requirement here about the cardinality of the roles
of gateways and proxies?) Clearly if two proxies in an ITAD do not
communicate with one another, and each gateway registers with a single proxy
at a time (discounting failover), then I don't think it would even be
possible for two proxies to return the same decision. If allowing something
along these lines is what this requirement signifies, then I definitely
support it.

On another angle of this, perhaps support for some sort of load-balancing
should be its own requirement, since I'm not sure that's entirely dependent
on multiple proxies - I'd suggest that a single proxy should be capable of
returning different routes for two calls targeting the same address if it
has received multiple gateway registrations matching the parameters of the
call that have the same preference. Nor do I understand why a database
protocol would preclude load-balancing...

REQ 12- I'm not really sure why this sort of 'discovery' would be needed. I
agree that static configurations are more likely. Also, I  envision that
either the gateway or the proxy could initiate the connection. For the sort
of architecture I have in mind, it would make more sense to statically
configure the gateway with one or more proxies (each probably associated
with a preference) to which the gateway would attempt to connect.
Cryptographic authentication could let the proxy guarantee that the
connection is desirable.

Jon Peterson
NeuStar, Inc.

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel