Re: Re: draft-ietf-iptel-trip-gw-00.txt has been posted
Dhaval Shah <[email protected]> Sun, 23 Jun 2002 21:47:52 -0700
| Newsgroups | gmane.ietf.iptel |
|---|---|
| Message-ID | <[email protected]> |
--=====================_285571910==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Sarabjeet, At 06:19 PM 6/23/2002 -0700, Sarabjeet Chugh wrote: >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? A Trip-lite gateway can have associations with multiple LS's. So one possible scenario, in case the fail-over is'nt transparent, is for the Trip-lite gateway to have assocation with both the primary and secondary LS's. >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? Not sure if I understand your question correctly, but I guess you could add the TotalCircuitCapacity. >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? If I understand your question correctly, this is a local policy issue. >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. TRIP-GW gateways feed information into the LS and then LS has the configured policies and also does the assignment so it can locally choose to do whatever it wants with that information. I may be missing something but I guess what you mention in your last sentence can be achieved, without the need for the sync from LS to gateways.. Thx for your input, Dhaval >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) --=====================_285571910==_.ALT Content-Type: text/html; charset="us-ascii" <html> <font size=3>Hi Sarabjeet,<br> <br> At 06:19 PM 6/23/2002 -0700, Sarabjeet Chugh wrote:<br> <blockquote type=cite cite>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?</font></blockquote><br> A Trip-lite gateway can have associations with multiple LS's. So one possible scenario, in case the fail-over is'nt transparent, is for the Trip-lite gateway to have assocation with both the primary and secondary LS's. <br> <br> <br> <br> <blockquote type=cite cite><font size=3>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?</font></blockquote><br> Not sure if I understand your question correctly, but I guess you could add the TotalCircuitCapacity.<br> <br> <br> <blockquote type=cite cite><font size=3>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?</font></blockquote><br> If I understand your question correctly, this is a local policy issue.<br> <br> <blockquote type=cite cite><font size=3>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.</font></blockquote><br> TRIP-GW gateways feed information into the LS and then LS has the configured policies and also does the assignment so it can locally choose to do whatever it wants with that information. I may be missing something but I guess what you mention in your last sentence can be achieved, without the need for the sync from LS to gateways..<br> <br> <font size=3>Thx for your input,<br> Dhaval<br> <br> <br> <blockquote type=cite cite>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: </font><a href="ftp://ftp-eng.cisco.com/dhaval/draft-ietf-iptel-trip-gw-00.txt" eudora="autourl"><font size=3 color="#0000FF"><u>ftp://ftp-eng.cisco.com/dhaval/draft-ietf-iptel-trip-gw-00.txt</a></u></font><font size=3> <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) </font></blockquote></html> --=====================_285571910==_.ALT--