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

From: James Yu <[email-masked]>
Date: Tue, 15 Aug 2000 17:04:09 -0500

Hussein,

What needs to be clearly indicated is that it should not happen that some
LSs/GWs announce the reachability of subscriber "POTS numbers" and others
announce the reachability of "routing" POTS numbers (e.g., LRNs) in the U.S.
and Canada.  Is the current TRIP document very clear and specific about
that? 

James

> -----Original Message-----
> From: Hussein F. Salama [mailto:[email-masked]]
> Sent: Monday, August 14, 2000 7:13 PM
> To: James Yu
> Cc: 'Jonathan Rosenberg'; [email-masked]'
> Subject: Re: [IPTEL] [TRIP] Address Families in 
> draft-ietf-iptel-trip-03
> 
> 
> James,
> 
> James Yu wrote:
> > 
> > Hussein,
> > 
> > In that case, do we just advertis the "POTS number" address 
> family in the
> 
> Yes, that should be sufficient.
> 
> In general, TRIP defines two address families and also allows peers to
> negotiate which address families each peer supports. More address
> families can be defined in the future, if needed. I think 
> that should be
> sufficient to satisfy the needs of different applications and regional
> requirements.
> 
> Hussein
> 
> 
> > U.S. and Canada and those numbers are all "routing numbers" 
> in the format of
> > +1+NPA+NXX?
> > 
> > James
> > 
> > > -----Original Message-----
> > > From: Hussein F. Salama [mailto:[email-masked]]
> > > Sent: Monday, August 14, 2000 4:42 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,
> > > >
> > > > Under NP, the NPA+NXXs in the U.S. and Canada are the
> > > "routing numbers" that
> > > > are used by the PSTN to route the call.  As indicated
> > > before, the LRN for
> > > > ported POTS number and the NPA-NXX of the non-ported POTS
> > > numbers are used
> > > > for routing.  Those numbers are viewed as "routing numbers"
> > > in the PSTN
> > > > until the calls reach the destination network/switch.
> > > >
> > > > For a ported POTS number, the destination switch/network
> > > retrieves the POTS
> > > > number from the ISUP Generic Address Parameter.  Note that
> > > the LRN is
> > > > carried in the ISUP Called Party Number (CdPN) parameter.
> > > For a non-ported
> > > > number, the POTS number is retrieved from the CdPN
> > > parameter (e.g., no LRN
> > > > is used, the "POTS number" is used for routing; therefore,
> > > is viewed as the
> > > > "routing number" before it reaches the destination 
> network/switch).
> > > >
> > > > If a switch serves several NPA+NXXs, one of the NPA+NXXs is
> > > used as the LRN
> > > > (note that LRN is a ten-digit number, NPA+NXX+XXXX and more
> > > than one LRN can
> > > > be assigned to a switch).  For a gateway that can reach
> > > this switch, the
> > > > "routing numbers" it announces would be those NPA+NXXs
> > > assigned to that
> > > > switch.  The "POTS numbers" it announce would be those POTS
> > > numbers that are
> > > > served by that switch.  This would include:
> > > >
> > > > - All the POTS numbers that begin with those NPA+NXXs
> > > assigned to that
> > > > switch excluding those that have been ported out.
> > > > - All the ported POTS numbers to that switch from other 
> switches.
> > > >
> > > > If a gateway can reach several switches, then aggregation
> > > is performed.  My
> > > > understanding of the POTS numbers are that they are the 
> "subscriber
> > > > telephone numbers."
> > >
> > > POTS-Numbers is just an address family. It does not imply 
> that numbers
> > > carried in that address family must be subscriber telephone
> > > numbers. For
> > > example, North American LRNs can be advertised using the 
> POTS-Numbers
> > > address family.
> > >
> > > Hussein
> > >
> > >
> > > May be I have a misunderstanding of the definition of
> > > > the "POTS number" address family.
> > > >
> > > > James
> > > >
> > > > > -----Original Message-----
> > > > > From: Jonathan Rosenberg [mailto:[email-masked]]
> > > > > Sent: Monday, August 14, 2000 2:37 AM
> > > > > To: James Yu
> > > > > Cc: [email-masked]; [email-masked]'
> > > > > Subject: Re: [IPTEL] [TRIP] Address Families in
> > > > > draft-ietf-iptel-trip-03
> > > > >
> > > > >
> > > > > Right, and thats called the "POTS Number" address family.
> > > > >
> > > > > -Jonathan R.
> > > > >
> > > > > James Yu wrote:
> > > > > >
> > > > > > It seems that there may be a need to define the routing
> > > > > numbers in such a
> > > > > > way (or by implementation?) that allows easy
> > > aggregation of "routing
> > > > > > numbers" that contain only digits 0 through 9 for countries
> > > > > that don't use
> > > > > > digits A through E in the "routing numbers."
> > > > > >
> > > > > > James
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Jonathan Rosenberg [mailto:[email-masked]]
> > > > > > > Sent: Friday, August 11, 2000 12:10 PM
> > > > > > > To: [email-masked]
> > > > > > > Cc: James Yu; [email-masked]'
> > > > > > > Subject: Re: [IPTEL] [TRIP] Address Families in
> > > > > > > draft-ietf-iptel-trip-03
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > "Hussein F. Salama" wrote:
> > > > > > > >
> > > > > > > > James,
> > > > > > > >
> > > > > > > > James Yu wrote:
> > > > > > > > >
> > > > > > > > > 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.
> > > > > > > >
> > > > > > > > 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?
> > > > > > >
> > > > > > > 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
> > > > > > >
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > IPTEL mailing list
> > > > > > > [email-masked]
> > > > > > > http://lists.bell-labs.com/mailman/listinfo/iptel
> > > > > > >
> > > > >
> > > > > --
> > > > > 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
> > > > >
> > > >
> > > > _______________________________________________
> > > > IPTEL mailing list
> > > > [email-masked]
> > > > http://lists.bell-labs.com/mailman/listinfo/iptel
> > >
> > > --
> > > 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
> > >
> 
> -- 
> 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
> 
> 
> _______________________________________________
> IPTEL mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/iptel
> 

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

---

From: "Hussein F. Salama" <[email-masked]>
Date: Wed, 16 Aug 2000 13:57:05 -0700

> and Canada.  Is the current TRIP document very clear and specific about

The Route Types Supported capability says:
"The Route Types Supported Capability Code lists the route types
 supported in this peering session by the transmitting LS.  An LS
 MUST NOT use route types that are not supported by the peer LS in
 any particular peering session.  If the route types supported by a
 peer are not satisfactory, an LS MAY terminate the peering session."

I think we should consider replacing the word "MAY" with "SHOULD" or
"MUST."

The above text is sufficient to prevent peer-to-peer capability
mismatch.  However, it doesn't prevent mismatches across an entire
domain, because TRIP can't prevent that. May be an application note
(TRIP applicability) is needed to clarify this issue and othe similar
issues which may arise in the future.

Hussein