Subject: some questions re draft-ietf-iptel-gwloc-framework-04.txt

From: Randy Bush <[email-masked]>
Date: Tue, 09 Nov 1999 08:01:52 -0500

pardon this off the wall message.  i happened to read gwloc-framework-04 and
had some questions back in early september.  somehow they got lost in intra-
iesg communication.  i would appreciate any education by direct email, as i
am not a wg/list member.

thanks.

randy

------

[3] seems to be a normative reference to an i-d.
[9] may be as well.

---

i am not entirely comfortable with

   The second of these mappings is needed to facilitate calls from
   traditional phones to IP terminals. When a user on the GSTN wishes to
   call a user with a terminal on the IP network, they need to dial a
   number identifying that terminal. This number could be an IP address.
   However, IP addresses are often ephemeral, assigned on demand by DHCP
   [4] or by dialup network access servers using PPP [5]. The number
   could be a hostname, obtained through some translation of groups of
   numbers to letters. However, this is cumbersome. It has been proposed
   instead to assign phone numbers to IP telephony terminals.

we already have dns to ip mapping, and having two parallel mappings worries
me.  e.g. will they reinvent dynamic update of ip->phone inverse mapping to
be hauled into dhcp?

---

may an itad exist which has no end users or gateways, i.e. just one or more
lss?  the definition allows this, 8.1, but i am not sure it is intended.  at
least it is not explicitly described.

   An IT administrative domain consists of zero or more gateways, at
   least one Location Server, and zero or more end users.

i suspect this may be useful, e.g. for an itad which aggregates and or
resells other gateway (or maybe even user) itads.  if this is intended, the
concept might be made explicit.

---

8.2 are the gateway attributes data communicated in a glp a user-extensible
list?

---

9.1 this omits the seemingly useful case where more than one idp is used
within a single idad.

   The intra-domain protocol which is used may be different from IT
   administrative domain to IT administrative domain, and is a matter of
   local configuration. An LS can also function without an intra-domain
   protocol. It may learn about gateways through static configuration,
   or may not know of any local gateways.

---

9.2 says

   The association between a pair of LS's is set up administratively. There
   is no autodiscovery procedure.

this explicitly precludes possibly interesting forms of dynamic discovery.
i can envision that, should the world gets large and inter-idad business
models become standardized, that automated discovery and itad-itad peering
would be useful.  it might also be useful in healing partitons caused by
failures of aggregation itads.

as the prohibition is so explicit, i imagine this was all thought out by the
iptel wg.  if the motivation is simple, perhaps it could be stated.

---

9.2.1 says

   The information exchanged by the LS's is a set of routing objects.
   Each routing object minimally consists of a range of telephone
   numbers which are reachable, and an IP address which is the layer 7
   "next hop" towards a gateway which can reach that range.

perhaps the resolution should be to a fqdn to give another degree of freedom
in the binding, e.g. to allow a multi-homed gateway.  as there is likely a
reason that this was not chosen, perhaps it could be stated in the document.

---

9.2.1 says

   The decision about which objects to aggregate and propagate is known
   as a route selection operation.  How the decision is made is at the
   discretion of the administrator, and is embodied in the LS
   policy. The decision can be made based on information learned through
   the GLP, or through any out of band means.

note that bgp has clear rules to decide what to propagate.  among other
reasons is loop prevention.  this loose specification would seem to allow
a large number of conflicting 'views' (in the database sense).  debugging
will provide full employment for a lot of folk.

this is a recognized problem, as is hinted in

   A routing object may have additional information which characterizes
   the service at the gateway. These attributes include things like
   protocols, features supported, and capacity. Greater numbers of
   attributes can provide useful information, however, they come at a
   cost. Aggregation becomes difficult with more and more information,
   impacting the scalability of the protocol.

if this thing is going to really scale, route propagation rules may need to
be more uniform and precise.

---

9.2.2 says that route selection will NOT be based on the characteristics of
the path between the end user and the gateway.  this seems amazing.  it
repeats bgp's weakness in lack of path metrics.

---

9.2.3 says that the glp does not carry cost metrics.  combined with the
above, one gets a gateway with unknown quality and unknown cost.  somehow i
think end users will not think this is a boon.

---

12 security considerations

   Since the relationships between LS's are based on pre-arranged
   administrative relationships, shared secrets seem an appropriate
   mechanism for the authentication and integrity.

shared secrets do not scale.  some sort of certificate system seems more
reasonable if this is to really grow.  and there are ietf protocols for
this.

-30-

---------
This message came from the IETF IPTEL Working Group Mailing List.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 09 Nov 1999 14:51:26 -0500

> iesg communication.  i would appreciate any education by direct email, as i

Thanks so much for your comments. Responses are below.

> [3] seems to be a normative reference to an i-d.

The framework document is not standards track, its going to be
informational. In any case, this reference is to MGCP, which is just
cited as a definition of a term. MGCP is now an informational rfc.

> [9] may be as well.

Same comment; this document is informational. In any case, SIP caller
preferences is not even a normative reference in the protocol itself.

> me.  e.g. will they reinvent dynamic update of ip->phone inverse mapping to

No, not at all. In fact, the purpose of this paragraph is to agree
completely with you. The  point here is that there are several problems
related to what we call here gateway discovery. One of them is this:
given a phone number that corresponds to an IP terminal, how does one
get its current IP address? We are not solving this problem, as the text
below indicates:

> The first mapping function, however, is fundamentally an address to
>    route translation problem. It is this problem which is considered by
>    GLP.

In fact, the enum group has now been chartered to solve the phone number
to host mapping problem you cite, using DNS.

Perhaps the wording needs to be stronger here, to explicitly say that we
are NOT trying to solve the other two.

> least it is not explicitly described.

Yes, it is definitely allowed. In fact, it used to not be allowed, but
it was changed to allow it. 

> concept might be made explicit.

OK. I will add some text along those lines.

> 8.2 are the gateway attributes data communicated in a glp a user-extensible

The list of attributes is extensible. The protocol itself is very
similar to BGP, and has attribute flags which describe how to handle
attributes that are unknown. I will add text indicating that this list
is extensible.

>    or may not know of any local gateways.

I hadn't considered that; I guess its possible here. I don't think the
text explicitly rules it out, but it doesn't explicitly disallow it
either. I'll add text saying its possible to have more than one.

> iptel wg.  if the motivation is simple, perhaps it could be stated.

It was explicit, and thats because peering relationships apply business
and administrative relationships. Because of that, we didn't think there
could be autoconfiguration. If an LS is configured with "allowed peer
domains", it is certainly reasonable to use an autodiscovery procedure
to find a specific LS within an allowed peer domain. This would also
support your idea of partition healing. I'm more skeptical about
standard inter-itad business models though.

I can change this to basically say that an association implies a
business relationship, and that generally this will be administratively
configured. This doesn't preclude autodiscovery if business
relationships have been pre-agreed upon.

> reason that this was not chosen, perhaps it could be stated in the document.

Good point. Our current protocol solution supports this, as next hops
are described by an address family, address value pair. Seems like a
fully qualified domain name could be an "address family". In any case, I
will change this.

> will provide full employment for a lot of folk.

We don't deviate from the bgp model in this regard. The text was not
meant to imply that we do. I'll change it to something like. "The
administrator has great latitude in selecting which objects to aggregate
and propagate, so long as they are within the bounds of correct protocol
operation (i.e, no loops are formed)."

> be more uniform and precise.

As I mention above, we stick with the bgp decision process.

> repeats bgp's weakness in lack of path metrics.

Thats because its infeasible here. This is not BGP. This is an
application layer protocol that runs between application providers. The
"paths" our protocol establishes are for the signaling protocols for
voice between application layer proxies. The actual media transport,
using RTP, follows a completely different path from the signaling
protocols, as a general rule. For example, I may call someone in NY from
my home in New Jersey. I'm using MCIWC as my gateway provider. As their
base of operations, say, is in texas, my call setup message goes to
texas, and from there forwarded to a gateway in NY (such a forwarding
table been established by our protocol, TRIP (aka GLP)). Once the call
is setup, I send media to the gateway. The media packets are forwarded
based on normal IP routing. These don't even pass through MCIWC network,
since I am purchasing my ISP service from a local company. Thus, the
signaling and media paths are completely independent. This means
GLP/TRIP cannot usefully carry media path information. It *does* carry
signaling path characteristics, though.

> think end users will not think this is a boon.

actually, we are going to define a pricing attribute, which may be
nothing more than a key into some local policy database, so this section
needs to change.

As I have discussed above, voice quality is outside of the scope of
control of GLP/TRIP, since it is based on media path characteristics.

> reasonable if this is to really grow.  and there are ietf protocols for

Consensus is to use existing transport or IP layer security. We haven't
decided yet on which. I will change this to be more general; shared
secrets is a mechanism. The requirement we need to state is for
encryption and mututal authentication.

Once again, thanks for taking the time to review this.

-Jonathan R.
-- 
Jonathan D. Rosenberg                       200 Executive Drive
Chief Scientist                             Suite 120 
dynamicsoft                                 West Orange, NJ 07052
[email-masked]                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

---------

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 09 Nov 1999 16:10:10 -0500

> relationships have been pre-agreed upon.

It would be nice if there were some mechanism of discovering redundant
peers. For example, one could imagine a mapping from ITAD to DNS, and
then use SRV to find one of the LSs. Something like 17.itad.int.

In the future, ad-hoc business relationships may well form, in the sense
that if LS1 contacts LS2, they simply indicate a neutral third party
(Visa, say) that takes care of billing. Since every provider presumably
has an interest in being the destination of as many phone calls as
possible, I don't see why it would refuse any peering offer unless it is
expects not to be paid for services rendered. Since the peering itself
does not render any services by itself, it may not even matter whether
it knows the credit worthiness of the potential peer, in the sense that
it only refuses service to the actual SIP call rather than the peering
relationship.

Thus, unlike "real" routing, where bandwidth and packets are at stake,
this is simply an "offer to trade", more akin to a web page or other
advertisement. I would therefore see no reason why ad-hoc relationships
wouldn't be common, even without a written contract. Indeed, one of the
advantages of one of the earlier models of using multicast was that
discovering ITADs was easier.

Maybe we'll have a secondary SAP-like mechanism (or whatever wide-area
SLP version may emerge) where ITADs simply announce their presence.

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

---------

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 09 Nov 1999 16:50:33 -0500

Reinaldo Penno Filho wrote:
> 
> Well, since we don't have a advertisment path attribute with the same
> meaning as in BGP, things like LocalPref, MED and Communities loose much
> of their power. Most policy routing is done using the AS PATH attribute
> cause thats represents the data path also, so you can do things globaly
> (based on the AS PATH).

TRIP isn't BGP. We have an advertisement path, but it refers to the
SIGNALING NOT THE MEDIA  Its still useful, since I'd like to choose
places to send my signaling based on policy.

> 
> So (in the way TRIP works) if I want to, locally,  prefer some
> data (not control) routes instead of others (LocalPref), or advertise some
> routes with greater preference than others (MED), will I  have to do that
> based on the prefix only ? 

You can't prefer one voice path over another with TRIP. Thats because
TRIP establishes the SIGNALING PATH NOT THE MEDIA PATH. It has no
control over the media path. Normal, plain old BGP as its deployed right
this second is whats going to figure out how to route your media towards
the gateway. Given that the signaling and media paths are totally
orthogonal, there is NO WAY that TRIP can be used to express preferences
for how RTP packets are routed. RTP packets are routed based on regular
BGP, not TRIP.

If thats true, we better to a good job in
> aggregating phone numbers or we may have some scaling issues.

If we tried to have TRIP follow the AS topologies in BGP, such that ITAD
= AS, we would completely destroy the possibility of any phone number
aggregation. This was discussed on the list way back in the early days
when some people were proposing to unify the existing BGP infrastructure
with TRIP; i.e, inject phone prefixes into the existing BGP routing
infrastructure. If you did that, you could prefer media routes based on
TRIP policy, as you want to do. However, besides (1) completely
overloading BGP (2) breaking any hope of phone number aggregation (3)
mandating business practice, and (4) ruling out anyone but AS's from
being ITADs, doing this is an administrative nightmare.

> 
> In the draft it is also said that the Advertisement path attribute could
> be used to do route selection. Thats also caused me some confusion
> (coming from a BGP background). And since the Advertisement Path may
> include many more hops than the actual path to the destination, shouldn't
> the statement about route selection be moved to the RoutedPath section?
> Souldn't the routed path be mandatory? This way could choose the Gateway
> based on the real paths that are going to be transversed?

No no no. The RoutedPath attribute DOES NOT REFER TO THE MEDIA PATH. It
refers to the SIGNLAING PATH. This is a subset of the advertisement
path, which is the set of ITADs the TRIP advertisements flow through.
The signaling path will be a subset of the TRIp advertisement paths when
there are LSs which don't modify the next hop. 

Please, TRIP is *not* BGP. Its an application layer protocol for
establishing application layer signaling paths.

-Jonathan R.

---------

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 09 Nov 1999 23:40:38 -0500

Reinaldo Penno Filho wrote:
> 
> On Tue, 9 Nov 1999, Jonathan Rosenberg wrote:
> 
> >
> >
> >
> > No no no. The RoutedPath attribute DOES NOT REFER TO THE MEDIA PATH.
> 
> No, I know that Jonathan. When I mentioned "routes" above, I meaned
> signalling routes.

OK... sorry for the flame... the issue comes up every so often and I
hate kicking around issues we resolved previously.

 Otherwise, If can't do policy routing on my signalling
> routes, we can take LoccalPref, MED and Communities of the spec. Don't you
> agree?

THis is a good point... I think you are right, that MED (not LocalPref,
which is strictly internal) is most useful when used along with the
routed path, not the advertisement path.

> So, If I want to use Localpref, MED or any other means to do *signalling
> route* manipulation, souldn't that be done with the RoutedPath Attribute
> instead of the AdvertisementPath attribute, since thats the attribute
> which really carries the signalling path?
> 
> You said yourself in the last email that we could choose the signalling
> path, and thats useful. Well, I can only choose the signalling path based
> on the Routee path, not on the Adverstisemtnpath. Is that correct? If
> thats correct, shouldn't the RoutedPath be mandatory?

Yes, that makes sense.

-Jonathan R.

---------

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 10 Nov 1999 00:45:21 -0500

> then use SRV to find one of the LSs. Something like 17.itad.int.

I think autodiscovery for LS's is a separate issue. I don't believe its
part of TRIP itself, and all we need to do in the framework is mention
that it might be possible. I don't doubt it would be nice, but I think
its right now a bit premature. If many folks are interested in
auto-discovery mechanisms, we could consider it as a work item once trip
itself is done.

As you mention, there are many ways this might be done - SLP, wide-area
SLP, DNS things, maybe even DHCP - who knows. 

-Jonathan R.

---------

---

From: "Hussein F. Salama" <[email-masked]>
Date: Tue, 09 Nov 1999 21:46:35 -0800

> routed path, not the advertisement path.

I think this argument applies to LocalPref as well since the LocalPref
of a route in a domain is computed based, among other factors, on the
identity of the external peer which advertised the route into that
domain.

> > thats correct, shouldn't the RoutedPath be mandatory?

Yes it makes sense that LocalPref and MED shouldn't be based on the next
hop ITAD along the AdvertisementPath. 

However, I don't think it is possible to compute LocalPref and MED based
on the next hop ITAD along the RoutedPath, because that next hop ITAD
may be several ITAD hops away from the current ITAD in the ITAD
topoplogy. 

In this case, computing the LocalPref requires an LS to be aware of all
ITADs in the network. 

In BGP, MED was originally defined to be used between two adjacent ASs
with more than one peer sessions running between them. When two ITADs
are not adjacent, there are no direct peer sessions running between them
and there is no way to tell how many possible RoutedPaths exist between
these two ITADs and definitely not what these RoutedPaths are.

However, there are cases where LocalPref and MED would still be very
useful. for example, the case where AdvertisementPath = RoutedPath =
MediaPath, my favorite case.

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: Reinaldo Penno Filho <[email-masked]>
Date: Tue, 9 Nov 1999 19:23:26 -0200 (EDT)

> signaling path characteristics, though.

This seems to confuse a lot of people (including me).  Information Path vs
Signalling Path.

based on the prefix only ? If thats true, we better to a good job in

thats my two cents folks...

Regards,

Reinaldo

---------

---

From: Reinaldo Penno Filho <[email-masked]>
Date: Tue, 9 Nov 1999 20:10:40 -0200 (EDT)

No, I know that Jonathan. When I mentioned "routes" above, I meaned
signalling routes. Otherwise, If can't do policy routing on my signalling
routes, we can take LoccalPref, MED and Communities of the spec. Don't you
agree?

It

[ ],

Reinaldo

---------

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 10 Nov 1999 10:27:22 -0500

"Hussein F. Salama" wrote:

> identity of the external peer which advertised the route into that

Good point. Sounds like consensus for making RoutedPath mandatory.

> may be several ITAD hops away from the current ITAD in the ITAD

Right, but it is the next hop ITAD in the topology in the
AdvertisementPath. So, local polciies would tell you whether to use the
RoutedPath (which Reinaldo wants), or the advertisementpath (which you
seem to prefer).

-Jonathan R.

---------