Subject: RE: [IPTEL] [TRIP] Address Families in draft-ietf-iptel-trip-03

From: James Yu <[email-masked]>
Date: Thu, 10 Aug 2000 21:40:11 -0500

Hussein,

As indicated earlier, the "POTS number" address family is a subset of
"routing number" address family (not in terms of the numbers but in terms of
allowable digits).  Aggregation needs to be done for the "routing numbers"
anyway if digits A through E may appear in the routing numbers.   So you are
not totally avoiding the problem.  If you need to aggregate for the routing
numbers and one "routing number" table can do the work, why announcing the
additional "POTS numbers" and managing an additional "POTS number table at
the LSs just because it is easier to aggregate that address family (this is
an "extra" work).  Under country code 1, digits A through E are not used.
It is then easy to aggregate the "routing numbers" under country code 1.

James 

> -----Original Message-----
> From: Hussein F. Salama [mailto:[email-masked]]
> Sent: Thursday, August 10, 2000 12:28 PM
> To: James Yu
> Cc: 'Jonathan Rosenberg'; [email-masked]'
> Subject: Re: [IPTEL] [TRIP] Address Families in 
> draft-ietf-iptel-trip-03
> 
> 
> 
> 
> James Yu wrote:
> > 
> > Jonathan,
> > 
> > In the example you gave, the gateway can still announce 
> that it can reach
> > the range of numbers that the user has as "routing 
> numbers."  If the call to
> > the user is received at the gateway, it then knows that it 
> has a direct T1
> > trunk to the user which is a more direct route than the one 
> going through
> > the PSTN.  But if that T1 trunk fails, it can set the 
> routing to route the
> > call through the PSTN.  Certainly, some other gateways may 
> get the call and
> > route the call through the PSTN to the user.   So if the 
> users owns/controls
> > +1-202-533-0000 to +1-202-533-0999, the gateway that the 
> user has direct T1
> > trunk connection with can advertise that it can reach 
> +1-202-533-0 in
> > addition to others as "routing numbers."  If those POTS 
> numbers are not
> > ported, this particular gateway may receive the calls to 
> the user ("may"
> > indicates that other gateways may receive some calls 
> because they can reach
> > those "routing numbers"). If those POTS numbers are ported 
> and if the IP
> > networks do not have the NP routing information (e.g., LRN 
> in the U.S. and
> > Canada), this particular gateway may receive the calls to 
> the user just like
> > the previous case.  But if those POTS numbers are ported 
> and if the IP
> > networks do have the NP routing information, I do see one 
> extra effort by
> > the gateway - to get and announce the additional "routing 
> number" of the
> > PSTN switch/network that serves this users' POTS numbers in 
> addition to
> > +1-202-533-0 and others  This is to ensure that this 
> gateway an receive
> > calls to the user when routing number for NP is available to the IP
> > networks.  But this is considered a minor effort comparing 
> to the effort of
> > announcing the POTS number address family via TRIP.
> > 
> > When NP is involved, if we only use one address family, the 
> "routing number"
> > table will get the call routed to the correct gateways 
> whether both routing
> > number and POTS number are present or just POTS number is 
> present.  But if
> > both address families are used, there must be a rule about 
> which number has
> > the precedence if both routing number and POTS number are present.
> 
> The rule is: 
> - If the destination number is a ported number, and NPDB lookup has
> already occured. In this case, we have both the LRN and the 
> destination
> POTS number. In this case the intermediate signaling server 
> should route
> the call using the LRN. The intermediate signaling server 
> should specify
> "address family = routing number" when it queries TRIP for a route to
> the given LRN.  TRIP then searches only those routes with 
> address family
> = routing number.
> - If destinatination is not a ported number, or if it is a ported
> number, but NPDB lookup hasn't occured yet (because e.g. the signaling
> servers traversed so far do not have access to the 
> appropriate NPDB). In
> this case, the intermediate signaling server should route the 
> call using
> the destination number. The intermediate signaling server 
> should specify
> "address family = POTS number" when it queries TRIP for a route to the
> given destination. TRIP then searches only those routes with address
> family = POTS number.
> 
> My main concern about using a single address family is still the
> difficulty of aggregation, because of different alphabets. If 
> we define
> a single address family with the alphabet {'1' .. '9', 'A' .. 'F'},
> automatic aggregation will not be easy. For example it will 
> never happen
> in the US. For example, a TRIP LS receives the following routes:
> 202530*, 202531*, 202532*, 202533*, ...., 202539*
> The LS will not aggregate these routes into 20253*, becasue it has not
> received 20253A*, 20253B*, ..., 20253F*, which do not exist.
> 
> Hussein
> 

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

---

From: "Hussein F. Salama" <[email-masked]>
Date: Fri, 11 Aug 2000 01:10:51 -0700

James,

> It is then easy to aggregate the "routing numbers" under country code 1.

I prefer having two separate address families to having a single address
family with two, or may be more, sets of aggregation rules. Deciding
which set of aggregation rules to use based on the first digit of the
prefix is too restrictive. For example, I can imagine TRIP applications,
with limited scope, local or national, which advertise numbers without
prepending the country code to them. Hence we won't have the '1' to
decide which aggregation rules to use?

Hussein

-- 
Hussein F. Salama
Cisco Systems
Mail Stop SJC6/3, 170 W. Tasman Drive, San Jose, CA 95134
Voice: +1 (408) 527-7147, Fax: +1 (408) 527-1714

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 11 Aug 2000 12:09:31 -0400

> decide which aggregation rules to use?

THe other issue is that you are forced to do semantic based aggregation.
We want to
allow (but not mandate of course)aggregation of numbers based on syntax
ONLY (i.e., I have 11, 12, 13 14, ... 10, and
since there are ten digits, I can aggregate to 1). This NECESSITATES
knowing the number
of digits that exist.

-Jonathan R.

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