Subject: RE: glp draft based on BGP

From: Alok Mittal <[email-masked]>
Date: Thu, 4 Mar 1999 12:29:55 -0000

Hi

 Some comments:

1. IT_SIG_PROTO should specify H.323 instead of Q.931/RAS -- a version
    number should also be supported here.
2. Some fields present in the SCSP based draft, such as lifetime and support 
    for range of numbers (for E.164) are useful -- Should we include those?
3. One drawback that I find in this approach is that the policy for forwarding 
    route information is present at every TBGP speaker (section 7.3) and hence
    when the information arrives at a particular speaker, it is already subjected 
    to a cascade of policies, which it doesn't even know. Support for exchange
    of full database (as in SCSP based draft) seems to be useful, if the policy
    leading to decision, should be applied independently in each domain. Of
    course, changes are exchanged incrementally so the network wouldn't be flooded.
4. In absence of a precise semantic definition of the IT_PATH_COST attribute,
    it seems premature to define an aggregation rule for it (section 7.4) -- we 
    should define what it really means, and then the aggregation rule would follow.
 
Best Regards
Alok

-----------------------------------------------------------------
Alok Mittal	
Technical Leader,	Hughes Software Systems
Prestige Opal, 146 Infantry Road, Bangalore - 560001
Tel: +91-80-2286390,91,92	Fax: +91-80-2286393
-----------------------------------------------------------------

-----Original Message-----
From:	Jonathan Rosenberg [SMTP:[email-masked]]
Sent:	Friday, February 26, 1999 8:40 PM
To:	list iptel
Subject:	New draft on glp

members of iptel,

Dave Hampton, Dave Oran, Hussein Salama, and Dhaval Shah have just
submitted a draft on using BGP4 as a basis for the GLP. Until the draft
appears in the archives, it is available from our webpage:

http://www.bell-labs.com/mailing-lists/iptel/

Please note that Cisco has indicated it may have IPR related to this
draft.

It seems we now have two competing proposals (one based on SCSP, and one
on BGP) for GLP. I'd like to begin some discussion on the lists here
debating the relative merits of the two approaches. Fire away....

-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.

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

---

From: "Hussein F. Salama" <[email-masked]>
Date: Thu, 04 Mar 1999 12:08:58 -0800

Alok,

Thanks for your comments. Some responses below.

Hussein

>     number should also be supported here.

An administrative domain, AD1, may wish that all incoming H.323 calls
from neighboring domains be routing by its gatekeeper first. The
gatekeeper then directs the incoming call to the appropriate gateway or
proxy. In this case, AD1, specifies the address of a gatekeeper as the
next hop and RAS as the signaling protocol. Alternatively, AD1, may
specify an H.323 gateway or proxy as the next hop and Q.931 as the call
signaling protocol. In the first case the gatekeeper is involved in both
call routing and admission control. In the second case, the gatekeeper
does admission control only.

I don't see the need for including version numbers. They are negotiated
within the protocols themselves, and I don't think there is a danger of
backward incompatibility in any of the protocols we're considering.

>     for range of numbers (for E.164) are useful -- Should we include those?

Yes, lifetime could be useful, especially if cost (pricing) information,
which change over time, are included in an Update. However, each new
attribute or field poses additional challenges and hazards to route
aggregation.

Regarding the use of ranges instead of prefixes, as you mentioned in an
earlier message, prefixes take less space than ranges. In addition, I
think, with proper use of aggregates and more specific call routes,
prefixes will be able to achieve the same degree of flexibility ranges
provide.

>     course, changes are exchanged incrementally so the network wouldn't be flooded.

If an administrative domain happens to lie on a specific call route, the
TBGP speakers representing that domain definitely have the right to
enforce their own policies on that route before advertising it further.
If an administrative domain doesn't have any policies to enforce, that's
fine.

Even the SCSP-based proposal permits intermediate LSes to enforce their
own policies (Matt, please correct me if I am wrong?). In the
inter-domain case, intermediate LSes may modify attributes and may
perform aggregation. They're not just synchronizing their databases.

>     should define what it really means, and then the aggregation rule would follow.

Good point.

-- 
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-2499

---------

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 04 Mar 1999 17:03:04 -0500

> backward incompatibility in any of the protocols we're considering.

Thats true so long as the protocol remains backwards compatible. If it
doesn't, we can always assign a new signaling protocol name. In other
words, we can group compatible versions together into a single name, and
define new names for incompatible versions. So, should H.323v4 be not
backwards compatible (just as an example), we would define two names:
H323 and H323V4.

> prefixes will be able to achieve the same degree of flexibility ranges

This alludes to an important point. It seems we have three possible ways
to represent number ranges: (1) a prefix, (2) a range, and (3) an MGCP
style digit map. When evaluating the choices, we need to consider the
utility of the approach (do we need ranges, or is a prefix sufficient?),
and the aggregatability of the approach. I suspect prefixes are easier
to aggregate than MGCP digit maps. The digit maps were not designed for
aggregation, but we will need to do it.

I'd really love to hear from some experts in PSTN numbering here as
well.

> perform aggregation. They're not just synchronizing their databases.

I agree that the SCSP proposal also allows the enforcement of policies,
and thus with that approach routing objects will be received that have
had lots of cascaded policies applied. Thats the nature of policy.

The advantage of the synchronization approach in SCSP is for an I-BGP
equivalent. All of the LS's in an AD can sync their databases, and use
any sort of interconnection topology. This is as opposed to BGP, which
uses full mesh, or specific things like communities (I believe). SCSP
would allow arbitrary connection graphs.

There are really two separate issues we need to discuss. The first is
BGP vs. SCSP as a framework, and the second is structure of the
attributes, which is likely to be the same between the two. So, I would
propose that we try and discuss these separately. I'd love to see mails
from people about the relative pros and cons of BGP vs. SCSP as a
framework, without regard to the attributes. We can carry separate
threads to argue the attribute issues. The agenda for the upcoming
meeting will follow this structure as well.

-jonathan R.

---------

---

From: Hussein F Salama <[email-masked]>
Date: Mon, 15 Mar 1999 10:55:27 -0800

"ronald h. davis" wrote:
> h.323 signalling does not occur over the ras channel, but anyway, my

Above, I suggested using RAS for call routing and admission control.
Didn't mention anything about call signaling. 

> question has to do with the overhead of querying ts1 first and then
> sending the setup message (i am referencing figure 1 of your draft).
> is it valid for ua to send the setup message (this assumes that it
> knows the protocol that it is using) to ts1 straight on, with ts1
> using its routing information to determine the next hop for the
> message?
> 
> the thrust of my suggestion is to view the tbgp speaker as being an
> appliation layer router.  depending upon network policies, the tbgp
> speaker could send the equivalent of an icmp redirect message to ua
> that could be cached for future calls.

I think the proposed query/reply mechanism is simpler. Redirecting the
call involves more state setup/teardown/modification overhead.

Hussein

> 
> --
>   __  ______  __  / __/ |       lucent technologies, naperville il, usa
> _/ (_(_) / (_(_/_/_(_/  .       [email-masked]
> "if you ain't the lead dog, the scenery never changes"  -- edmund wilson

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

---------

---

From: "ronald h. davis" <[email-masked]>
Date: Mon, 15 Mar 1999 11:47:09 -0600

>     number should also be supported here.

i think that q.931 should stay in the document.  however, ras should
not as the 's' in 'ras' stands for status and not signalling.  instead
h.323 (or h.225) should be specified.

>     for range of numbers (for E.164) are useful -- Should we include those?

as i recall, the bgp-4 model does not use information refresh as is
done in intra-domain protocols like ospf.  instead, information is
only sent when there is an update.  as far as e.164 numbers goes
wouldn't that go into nlri?

>     course, changes are exchanged incrementally so the network wouldn't be flooded.

i'm not sure how much comparison should be made between bgp and scsp.
bgp is an inter-domain routing protocol, where scsp (which is a
derivative of ospf) is more suitable in an intra-domain routing context.

---------

---

From: "ronald h. davis" <[email-masked]>
Date: Mon, 15 Mar 1999 15:01:33 -0600

> call involves more state setup/teardown/modification overhead.

this is certainly a reasonable model if you view the tbgp speaker as
providing an address resolution function such as in the atmarp server
in classical ip over atm.  

pgrp was coming from the standpoint of endpoints providing trunk
connections to class 5 switches.  in this case, the query/reply 
mechanism requires full mesh connectivity among the endpoints in the 
packet network.

	[i am interested in hearing other views on the following
	 proposition.  i'm going out on a limb here; hope it
	 doesn't break! :-0 ]

full mesh connectivity would gas out in a large network.  using an
application layer routing scheme would support hierarchy in networks
and, thereby, make them more scaleable.  consequently, the view of
the tbgp speaker as providing a forwarding function at the application
layer.  this is also consistent with the gatekeeper routed call model
from h.323 (i think).

a side benefit is that you would eliminate the delays associated with 
executing a query/reply cycle before initiating a call.

---------

---

From: "ronald h. davis" <[email-masked]>
Date: Mon, 15 Mar 1999 12:07:44 -0600

---------

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 18 Mar 1999 22:07:38 -0500

> in classical ip over atm.

How the database built up by a location server (LS) is used is out of
scope for GLP itself. In the framework document, this interaction is
called the "front end". Several possibilities are identified:

1. query/response, called "direct mode", perhaps with LDAP or RAS LRQ or
SLP
2. "proxy mode" - send a signaling message to the LS, and have it do the
resolution (I believe this is what Ron is suggesting), then forwarding
it towards the next hop

Redirects are also possible, easily done with SIP 300 responses. This is
sort of a hybrid between proxy mode and direct mode. I'll add something
about it to the framework document. 

However, we don't decide how this is done. We only define the protocol
for populating the databases.

-Jonathan R.

---------