Re: draft-ietf-iptel-trip-gw-00.txt has been posted
Sarabjeet Chugh <[email protected]> Sun, 23 Jun 2002 18:19:45 -0700
| Newsgroups | gmane.ietf.iptel |
|---|---|
| Message-ID | <[email protected]> |
--=====================_10249858==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed
Hi Dhaval, et. al.
I have some questions/concerns.
1) Aside from the three functions of the TRIP-Lite gateway that were
listed, viz.
- The initial OPEN phase, exchange of keepalive timers, and the process of
bringing up the state machine.
- Sending of one or more UPDATE messages containing the routes and
parameters of the gateways.
- Sending of a periodic keepalive.
Won't the TRIP-GW gateways also need to keep track of which LS/Proxy to
send its updates to ? That is, in scenarios when LS/Proxy are deployed in a
redundancy or HA mode, shouldn't a mechanism be implemented within the
TRIP-GW gateways to detect the change from Primary LS to backup/secondary
LS and vice versa?
As an extension to this thought, in cases when LSs are deployed in a
load-sharing manner for a given POP, as shown in figure below:
POP1
----------------------------------------------
| GW1 |
| / |
| / |
| LS2/-------GW2 |
| / |
| / GW3 |
| / / |
| LS1/------LS3/---- GW4 |
| \ |
| \ |
| LS4-----GW5 |
| \ |
| \ |
| GW6 |
|---------------------------------------------
What should be the best mechanism by which LS2 (that receives updates from
GW1 and GW2), LS3 (that receives updates from GW3 and GW4) and LS4 (that
receives updates from GW5 and GW6) respectively send their consolidated
update to the IP-facing Location Server , LS1? In this case LS1 should do
the ultimate consolidation for a given route/destination through this PoP.
In this scenario, how would the functionality of the attribute
"TotalCircuitCapacity" have to be modified?
2) TotalCircuitCapacity attribute
For a given PoP, the total number of routes to a destination DNIS/group of
DNIS/prefix may be fixed because of a pre-defined administrative policy
between the provider and the customers. In that case, on what basis will
individual gateways be able to assign values to the TotalCircuitCapacity
attribute for a given destination prefix or DNIS group?
The consolidated information is only available at LS, where the total
available circuits for a given destination are aggregated (as per Section
4.2.4).
So, shouldn't there be sync mechanism from LS to TRIP-GW gateways by which
the global TotalCircuitCapacity for a given destination for the entire PoP
be in sync with the sum of local values of TotalCircuitCapacity attributes
for the same destination present in all gateways? This can allow
implementation of circuit assignment based on pre-agreed upon policies
between the provider and retailer.
Regards,
Sarabjeet S. Chugh
VGDBU Software Engineer
Cisco Systems, Inc.
Email: [email protected]
Phone: (408) 853-5504
>Hi Folx, The draft is now available on the ftp server:
ftp://ftp-eng.cisco.com/dhaval/draft-ietf-iptel-trip-gw-00.txt
>If someone has problems retrieving it, please email directly and we will
email a copy to you.
>Please let us know if you have any questions.
>Thx, Dhaval (for the trip-gw team)
--=====================_10249858==_.ALT
Content-Type: text/html; charset="us-ascii"
<html>
Hi Dhaval, et. al.<br>
<br>
I have some questions/concerns.<br>
<br>
1) Aside from the three functions of the TRIP-Lite gateway that were
listed, viz.<br>
- The initial OPEN phase, exchange of keepalive timers, and the process
of bringing up the state machine. <br>
- Sending of one or more UPDATE messages containing the routes and
parameters of the gateways. <br>
- Sending of a periodic keepalive. <br>
Won't the TRIP-GW gateways also need to keep track of which LS/Proxy to
send its updates to ? That is, in scenarios when LS/Proxy are deployed in
a redundancy or HA mode, shouldn't a mechanism be implemented within the
TRIP-GW gateways to detect the change from Primary LS to backup/secondary
LS and vice versa?<br>
<br>
As an extension to this thought, in cases when LSs are deployed in a
load-sharing manner for a given POP, as shown in figure below:<br>
<x-tab> </x-tab> <br>
<x-tab> </x-tab>POP1<br>
----------------------------------------------<br>
|<x-tab> </x-tab>
GW1<x-tab> </x-tab><x-tab> </x-tab>|<br>
|<x-tab> </x-tab>
/<x-tab> </x-tab><x-tab> </x-tab><x-tab> </x-tab>|<br>
|<x-tab> </x-tab>
/<x-tab> </x-tab><x-tab> </x-tab><x-tab> </x-tab>|<br>
|
LS2/-------GW2<x-tab> </x-tab><x-tab> </x-tab>|<br>
|<x-tab> </x-tab>
/<x-tab> </x-tab><x-tab> </x-tab><x-tab> </x-tab>|<br>
|
/<x-tab> </x-tab>
GW3<x-tab> </x-tab><x-tab> </x-tab>|<br>
|
/<x-tab> </x-tab>
/<x-tab> </x-tab><x-tab> </x-tab>|<br>
| LS1/------LS3/----
GW4<x-tab> </x-tab>|<br>
|
\<x-tab> </x-tab><x-tab> </x-tab><x-tab> </x-tab><x-tab> </x-tab>|<br>
|
\<x-tab> </x-tab><x-tab> </x-tab><x-tab> </x-tab><x-tab> </x-tab>|<br>
|
LS4-----GW5<x-tab> </x-tab><x-tab> </x-tab>|<br>
|<x-tab> </x-tab>
\<x-tab> </x-tab><x-tab> </x-tab><x-tab> </x-tab>|<br>
|<x-tab> </x-tab>
\<x-tab> </x-tab><x-tab> </x-tab><x-tab> </x-tab>|<br>
|<x-tab> </x-tab>
GW6<x-tab> </x-tab><x-tab> </x-tab><x-tab> </x-tab>|<br>
|---------------------------------------------<br>
<x-tab> </x-tab><br>
What should be the best mechanism by which LS2 (that receives updates
from GW1 and GW2), LS3 (that receives updates from GW3 and GW4) and LS4
(that receives updates from GW5 and GW6) respectively send their
consolidated update to the IP-facing Location Server , LS1? In this case
LS1 should do the ultimate consolidation for a given route/destination
through this PoP.<br>
In this scenario, how would the functionality of the attribute
"TotalCircuitCapacity" have to be modified?<br>
<br>
2) TotalCircuitCapacity attribute<br>
For a given PoP, the total number of routes to a destination DNIS/group
of DNIS/prefix may be fixed because of a pre-defined administrative
policy between the provider and the customers. In that case, on what
basis will individual gateways be able to assign values to the
TotalCircuitCapacity attribute for a given destination prefix or DNIS
group?<br>
The consolidated information is only available at LS, where the total
available circuits for a given destination are aggregated (as per Section
4.2.4).<br>
So, shouldn't there be sync mechanism from LS to TRIP-GW gateways by
which the global TotalCircuitCapacity for a given destination for the
entire PoP be in sync with the sum of local values of
TotalCircuitCapacity attributes for the same destination present in all
gateways? This can allow implementation of circuit assignment based on
pre-agreed upon policies between the provider and retailer.<br>
<br>
Regards,<br>
Sarabjeet S. Chugh<br>
VGDBU Software Engineer<br>
Cisco Systems, Inc.<br>
Email: [email protected] <br>
Phone: (408) 853-5504<br>
<br>
<br>
>Hi Folx, The draft is now available on the ftp server:
<a href="ftp://ftp-eng.cisco.com/dhaval/draft-ietf-iptel-trip-gw-00.txt" eudora="autourl"><font color="#0000FF"><u>ftp://ftp-eng.cisco.com/dhaval/draft-ietf-iptel-trip-gw-00.</a><a href="ftp://ftp-eng.cisco.com/dhaval/draft-ietf-iptel-trip-gw-00.txt" eudora="autourl">txt</a></u></font>
<br>
>If someone has problems retrieving it, please email directly and we will email a copy to you. <br>
>Please let us know if you have any questions. <br>
>Thx, Dhaval (for the trip-gw team) <br>
</html>
--=====================_10249858==_.ALT--