Subject: Re: IPTEL meeting time

From: [email-masked] (Matthew Squire)
Date: Mon, 07 Dec 1998 21:48:09 -0500

At 12:42 PM 11/30/98 -0600, ronald h. davis wrote:
>here are some of my ideas as to how the two might fit together.  as
>i see it, a given location server gets information from 3 sources:
>	i)  information advertised from other location
>	    servers about gateways in other domains.
>	    this is equivalent to the rib-in information
>	    described in bgp-4.
>	ii) information about the local domain received
>	    from an interior gateway protocol (such as
>	    rip, or ospf).  this is equivalent to rib-local.
>	    this local information is to also include a
>	    transformation (by the local location server)
>	    of information received from other location
>	    servers.  in this way the local location server
>	    decides how it wants represent external
>	    information within the domain.
>	iii)information advertised to other location servers.
>	    this is equivalent to rib-out.  this information
>	    is a transformation of information received in
>	    i) and ii) in which the location server decides
>	    which information is to be (and how information
>	    is to be) presented to other location servers.
>
>i don't see the glp as specifically defining the polices and 
>transformations which produce i), ii), and iii) which are specific
>to individual domains and peering/bilateral agreements between
>domain operators.
>
>i see pgrp as providing information for item ii) above.
>
>without doubt, i think that location servers must have a keepalive
>(as well as a channel open/channel close) mechanism to ensure that
>status of the channel at any given time.  i would also suggest that
>glp *not* use aging of location information across domains but
>rather send information only when there is state change information
>to be propagated.
>

I agree with the non-aging part.  

My main comment on pgrp is that the whole TS-TS communication paradigm is
described as a simple database synchronization problem - ie you have a
'hello' protocol, an 'alignment' phase, and 'updates'.  Why not use SCSP
for this?  SCSP was designed as a generalized version of OSPF (ie database
syncronization not specific to routing data).  The protocol described in
the draft seems very close to SCSP give or take some terminology, and it
seems better not to reinvent db sync.  The intra-domain part of gateway
location seems like an excellent target for SCSP - they're both analogs to
OSPF.  

But, unfortunately, the intra-domain protocol is not what the group is
chartered to do.  One possibility is that we use SCSP as the link-state
protocol in point-to-point peering relationships for the GLP.  This would
get us the 'rib-in' equivalent in BGP.  If we decide not to define
aggregation and policy rules, then the procedures for computing the rib-in
and rib-local equivalents would be left unspecified.  Running through the
BGP4 spec, other things in BGP besides data definitions and synchronization
procedures include:
 - define data synchronized and data formats
 - version negotiation
 - state machines (if need any outside of SCSP's)
 - frequency of route advertisements/originations

I suggest that we consider SCSP for the peer-to-peer database
synchronization.  The WG could concentrate on what data requires
synchronization, and any other required procedures outside of db sync.  If
we also used SCSP for the intra-domain db synch, then we have a big plus
(but I know this wg isn't chartered to do this work item).  

Other comments on draft-ietf-iptel-pgrp-framework-00.txt:

 - Seems h323-centric.  Needs generalizations for SIP.
 - Not sure of the purpose of 'OUT OF SERVICE-TRANSITION' state (p7).  An
endpoint can either be accepting calls, or not.  GW location would be used
prior to setting up the call, so any information about current call state
doesn't seem necessary.  The only question is whether it can accept a call.
 - Can you clarify what is on the 'LIST OF ELEMENTS?'  The definitions
state that these are elements with wich the registrant is able to connect.
What kind of connectivity are we talking about here?  
 - The 'LOGICAL ELEMENT IDENTIFIER' is used for two gatekeepers to look
like a single gk.  Why isn't the fact that two gk's register sign up for
the same zone sufficient to detect this?
 - The topology area identifier (p 13) is said to be typically configured
to the ip address of the primary topology server.  How can you do this when
the primary topology server is determined by an election?
 - On p 26, a stated assumption is that 'if a topology server is not able
to communicate with another topology server over this channel" than "other
topology servers will have the same difficulty."  I think this is an
invalid assumption.  Its easy to cut a multicast tree in half.  Its also
easy to conceive of other cases of unidirectional connecitvity.  This
assumption breaks the protocol in some error situations.
 - I'd prefer more choices for the TS topology than a simple star
configuration with the DTS/BTS in the middle.  Why not permit more general
TS topologies and skip the election?  Easy to do with SCSP.

- Matt

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

---

From: "ronald h. davis" <[email-masked]>
Date: Fri, 11 Dec 1998 15:20:17 -0600

> location seems like an excellent target for SCSP - they're both analogs to

i thought that i would see you at the ietf meeting but there were so
many people at the iptel session (far more than i had expected)...

i took a quick look at scsp and it looks as though the authors did the
same thing that i did - took ospf and "skinnied" it down.  i agree that
scsp can be used for the topology server to topology server information
exchange part of pgrp, however, ospf has (and pgrp copied) an election
procedure which i don't know should be pitched for general purpose
networks (see comments on this below).

the model for information exchange between gatekeepers and topology 
servers is not based upon ospf but rather a "skinnied" down version of 
bgp-4.  the assumption here is that if you assume that information is 
synchronized among topology servers, then there is no need for 
information exchange between a gatekeeper and multiple topology servers.

> chartered to do. 

this comment should be addressed under a different thread so i'll start
one to discuss pgrp and the iptel charter in another message.

> One possibility is that we use SCSP as the link-state
> get us the 'rib-in' equivalent in BGP.
>

is there a need for a "hello" protocol over a point-to-point link?
why not use bgp-4 as the basis for interdomain information exchange
which i think can be applied more readily to glp?  from reading your
subsequent comments about applying bgp-4, i think that is what you are 
sort of suggesting anyway.

>  - Seems h323-centric.  Needs generalizations for SIP.

i haven't been involved in the ietf (or itu) long enough to understand
the fine points of any issues that might exist between the two groups,
but i wasn't trying to "trojan horse" an itu agenda into the workgroup
so i'd be happy to incorporate suggestions to generalize the language.

> What kind of connectivity are we talking about here?

the idea of the "list of elements" is that it contained a list of
elements (gateways, &c.) to which a given element could establish
communications.  so if we call the 'given element', "element_a", and
the elements in the "list of elements", "element_b", and "element_c")
then the topology state database entry for element_a would contain
(element_b, element_c).  the "connectivity state" associated with each
of these "list of elements" elements would indicate the ability of
element_a to communicate with these elements.

> the same zone sufficient to detect this?

i took a look at what i wrote after i read your comment and concluded
that there is no need for me to constrain mate gatekeepers to be in
the same zone (which is an h.323 protocol violation anyway); as long
as the gatekeepers have the same "logical element identifier" the
topology server can keep the two (or more) gatekeepers updated.  in
fact, ithe gatekeepers don't even have to be associated with the same 
topology server.

> the primary topology server is determined by an election?

the "designated topology server" is determined by election.  the
"primary topology server" is the topology server used by the gatekeeper
for establishment of a client-server channel.  the current draft of
pgrp allows a gatekeeper to be provisioned with a prioritized list of
potential topology servers.  prior to that, i had only allows two
potential topology servers to be so provisioned: a 'primary' topology
server and a 'backup' topology server.  when i changed terminology i
didn't go through the document to make everything consistent.

what's so confusing about that?  :-)

> invalid assumption.  Its easy to cut a multicast tree in half.
>

the assumption is still good in that case because if you cut the
multicast tree in half, the topology servers in each half will
see the same set of topology servers in the multicast group while
servers in the other half of the multicast tree will age off and
be declared dead by the hello protocol.  what i was assuming was
that there would not be the case that some of the topology servers
in a "half" would see half of the multicast tree while others in the
same half would see the whole multicast tree.

> Its also
> easy to conceive of other cases of unidirectional connecitvity.
>

in this case i would expect that all of the other topology servers in
the multicast group would detect that the server in question is not 
sending hello packets (as opposed to some topology servers receiving
hello packets while others aren't).

> This

i can't conceive of those situations.  would you describe one?

> TS topologies and skip the election?  Easy to do with SCSP.

i'm  not sure what you mean by "more general ts topologies", but:

ospf has the election scheme and i copied that to pgrp.  during the
iptel session at the ietf meeting a guy mentioned that the reason for
having an election is to help maintain orderly information exchange
when the network includes routers that don't have multicast capability.
now, i took that to mean elements in an nbma network (like atm switching
elements).

by that reasoning i should think that scsp would have wanted to also
include the election scheme from ospf.  maybe it does, but from my
perusal of scsp, i didn't see any mention of such.

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

---

From: "ronald h. davis" <[email-masked]>
Date: Fri, 11 Dec 1998 15:30:57 -0600

> But, unfortunately, the intra-domain protocol is not what the group is

if it's not then it *should* be in the charter.  when i think of ip
telephony, the function, the intra-domain problem is clearly part of
ip telephony.  in fact, i would think that the intra-domain problem
is probably of more immediate significance than the inter-domain
problem since i would expect that the intial efforts at doing ip
telephony would be within enterprises (intra-domain style) much as
has been the case with voice over atm.

therefore, it seems hard to imagine that the intra-domain should not
be relevant to the work of the iptel workgroup.  however, if such is
truly not the case, then there should be a separate iptel workgroup
which does make this a part of their charter.

a few people approached me after my presentation and expressed interest
in the intra-domain problem, and one person wondered why the iptel
workgroup didn't address that problem first - make that two, because i
was wondering the same thing, especially since (at least, as it appears
to me) itu study group 16 and iptel are addressing the same problem at
the same time.

furthermore, from my reading of annex g, study group 16 has *not*
limited their scope to the inter-domain problem.  so my question is
why should iptel limit themselves to the inter-domain problem?  is
this to suggest that iptel will therefore leave the intra-domain
problem unresolved?

anyway, some of my comments.  i'd be interested in seeing other views
on the matter, however.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 17 Dec 1998 10:12:27 -0500

> has been the case with voice over atm.

The intra-domain problem is important, and relevant to our work.
However, a group can only do so much at one time, before it becomes too
spread out and loses its focus. For the moment, our workplan is to
complete an inter-domain protocol. If we do a good job and finish it in
a timely fashion, we can consider working on an intra-domain protocol at
that time.

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