Re: draft-ietf-iptel-trip-gw-00.txt has been posted
Dhaval Shah <[email protected]> Thu, 26 Sep 2002 13:05:16 -0700
| Newsgroups | gmane.ietf.iptel |
|---|---|
| Message-ID | <[email protected]> |
--=====================_12294348==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Anirudh, At 12:45 PM 9/26/2002 -0700, Anirudh Sahoo wrote: >All, > Regarding whether to allow advertisement of more than addr fam >or not, I feel we should allow advertisement of multiple addr fam >as long as the routes do not overlap. There may be scenarios where >it is more efficient to send non-overlapping routes in multiple >address families. > One case could be where a gateway is managed in such a way >that some trunks do not have a carrier associated with them and some >do. In this scenario it is more efficient to send both T and C family. >Otherwise, if we put restriction for one family advertisement, then >T family advertisement may be used (with C as attr). Right. We thought about this and felt it could be covered by T with attr C. Not sure what you mean by more efficient and whether it buys us much. >Then at the LS, to get carrier >level resource information, the LS has to compute it from the T >destination routes. So if we allow advertisement of non-overlapping >multiple addr fam, then implementors will have flexibility to >do whichever way they deem appropriate for their case. Any concrete examples? In general, there are many other ways we could add flexibility in the protocol as a whole but I guess we try to measure against potential of real use since else flexibility can also cause confusion/misconfigs etc. > Other case could be where a gateway which has some >analog (fxs) ports as well as some digital trunks. In this case, for >fxs port, only the reachability info is enough, resource info is >not important. So those could be advertised as prefix (e.g. e164) >family. But for digital trunks since accurate resource reporting is >important, a T family will be suitable. If resource info. is not important in certain cases, then don't include it. T family can cover both cases in this case. > Since allowing advertisement of multiple address family without >overlapping routes seems to have no adverse effect and at the same >time provides the flexibility in cases described above, I feel that Please see above. It'd be great if you could describe the concrete customer scenario in mind accompanied with reachability and call flows, if any.. Thx, Dhaval, Manjunath and Rajneesh >the draft should allow that. Otherwise, it will become restrictive for >the above scenarios. > >Dhaval Shah wrote: >> >>Please see some comments and questions inlined. >> >> >>>I don't think we need to standardize a window, but the spec should >>>suggest that sufficiently large windows be used to provide a useful >>>aggregated statistic. >> >> >>We'll incorporate this. >> >>>Two comments. >>> >>>First, I agree with Bob that we should allow the carrier attribute to be >>>present in the trunk group address family. There was another comment to >>>the list regarding that. >> >> >>Will do that. Also, we are thinking of proposing to allow for T attribute >>to be present in C address family. >> >> >>>I think we can allow a mix, so long as the meaning of this is well >>>defined. One possible model is that there is no overlap. So, if a >>>gateway has 5 trunk groups, it can advertise three of them using trunk >>>group address family, and the other two using prefix address families. >>>This would allow for an LS to convert the three trunk group family >>>routes to prefix routes, and then even aggregate them with the other two >>>prefix routes, without anything incorrect happening in terms of >>>information represtation. >>> >>>If the routes overlap, its more complex. An example of this case is a >>>gateway with 5 trunk groups. It advertises 5 routes using trunk group >>>families, and 5 with prefix families. In this case, an LS would need to >>>know how these are correlated in order to properly manipulate them. I >>>think this is a recipe for disaster, and I would prefer to mandate the >>>non-overlapping case above. >> >> >>After much thought, some of us feel that providing three address families >>but allowing use one at a time is >>sufficient. >> >>So, the question here is: Can we come up with a reasonable example, that >>includes a TGREP/TRIP reachability >>flow and a call flow, describing how/why an actual customer may need >>this flexibility? >> >>Thx, >>Dhaval >> >> >> >>>-Jonathan R. >>>-- >>>Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue >>>Chief Scientist First Floor >>>dynamicsoft East Hanover, NJ 07936 >>>[email protected] FAX: (973) 952-5050 >>>http://www.jdrosen.net PH: (973) 952-5000 >>>http://www.dynamicsoft.com >>> >>> >>>_______________________________________________ >>>IPTEL mailing list >>>[email protected] >>>http://lists.bell-labs.com/mailman/listinfo/iptel > >-- >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >| Name : Anirudh Sahoo | | US mail : | >| email : [email protected] | | 170 W. Tasman Dr| >| Tel : 408-525-4508 ||| ||| M/S: SJC21/2 | >| Fax : 408-526-8521 ||||| ||||| San Jose, | >| ..:|||||||:...:|||||||:.. CA - 95134 | >| Cisco Systems Inc. | >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > --=====================_12294348==_.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html> <font size=3D3>Hi Anirudh,<br> <br> At 12:45 PM 9/26/2002 -0700, Anirudh Sahoo wrote:<br> <blockquote type=3Dcite cite>All, <br> Regarding whether to allow advertisement of more than addr fam <br> or not, I feel we should allow advertisement of multiple addr fam <br> as long as the routes do not overlap. There may be scenarios where <br> it is more efficient to send non-overlapping routes in multiple <br> address families. <br> One case could be where a gateway is managed in such a way <br> that some trunks do not have a carrier associated with them and some <br> do. In this scenario it is more efficient to send both T and C family. <br> Otherwise, if we put restriction for one family advertisement, then=20 <br> T family advertisement may be used (with C as attr). </font></blockquote><br> Right. We thought about this and felt it could be covered by T with attr C.<br> Not sure what you mean by more efficient and whether it buys us much.<br> <br> <blockquote type=3Dcite cite><font size=3D3>Then at the LS, to get carrier <br> level resource information, the LS has to compute it from the T <br> destination routes. So if we allow advertisement of non-overlapping=20 <br> multiple addr fam, then implementors will have flexibility to <br> do whichever way they deem appropriate for their case. </font></blockquote><br> Any concrete examples? In general, there are many other ways we could<br> add flexibility in the protocol as a whole but I guess we try to measure against<br> potential of real use since else flexibility can also cause confusion/misconfigs etc. <br> <br> <blockquote type=3Dcite cite><font size=3D3> Other case could be where a gateway which has some <br> analog (fxs) ports as well as some digital trunks. In this case, for <br> fxs port, only the reachability info is enough, resource info is <br> not important. So those could be advertised as prefix (e.g. e164) <br> family. But for digital trunks since accurate resource reporting is=20 <br> important, a T family will be suitable. </font></blockquote><br> If resource info. is not important in certain cases, then don't include it.<br> T family can cover both cases in this case.<br> <br> <blockquote type=3Dcite cite><font size=3D3> Since allowin= g advertisement of multiple address family without <br> overlapping routes seems to have no adverse effect and at the same <br> time provides the flexibility in cases described above, I feel that </font></blockquote><br> Please see above.<br> <br> It'd be great if you could describe the concrete customer scenario in mind accompanied<br> with reachability and call flows, if any..<br> <br> <font size=3D3>Thx,<br> Dhaval, Manjunath and Rajneesh<br> <br> <blockquote type=3Dcite cite>the draft should allow that. Otherwise, it will become restrictive for <br> the above scenarios. <br> <br> Dhaval Shah wrote: <br> <blockquote type=3Dcite cite> <br> Please see some comments and questions inlined. <br> <br> <br> <blockquote type=3Dcite cite>I don't think we need to standardize a window, but the spec should suggest that sufficiently large windows be used to provide a useful aggregated statistic.</blockquote><br> <br> We'll incorporate this. <br> <br> <blockquote type=3Dcite cite>Two comments. <br> <br> First, I agree with Bob that we should allow the carrier attribute to be present in the trunk group address family. There was another comment to the list regarding that.</blockquote><br> <br> Will do that. Also, we are thinking of proposing to allow for T attribute to be present in C address family. <br> <br> <br> <blockquote type=3Dcite cite>I think we can allow a mix, so long as the meaning of this is well defined. One possible model is that there is no overlap. So, if a gateway has 5 trunk groups, it can advertise three of them using trunk group address family, and the other two using prefix address families. This would allow for an LS to convert the three trunk group family routes to prefix routes, and then even aggregate them with the other two prefix routes, without anything incorrect happening in terms of information represtation. <br> <br> If the routes overlap, its more complex. An example of this case is a gateway with 5 trunk groups. It advertises 5 routes using trunk group families, and 5 with prefix families. In this case, an LS would need to know how these are correlated in order to properly manipulate them. I think this is a recipe for disaster, and I would prefer to mandate the non-overlapping case above.</blockquote><br> <br> After much thought, some of us feel that providing three address families but allowing use one at a time is <br> sufficient. <br> <br> So, the question here is: Can we come up with a reasonable example, that includes a TGREP/TRIP reachability <br> flow and a call flow, describing how/why an actual customer may need this flexibility? <br> <br> Thx, <br> Dhaval <br> <br> <br> <br> <blockquote type=3Dcite cite>-Jonathan R. <br> -- <br> Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue <br> Chief Scientist &= nbsp;  = ; First Floor <br> dynamicsoft  = ; &nb= sp; East Hanover, NJ 07936 <br> [email protected]  = ; FAX: (973) 952-5050 <br> <a href=3D"http://www.jdrosen.net=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0/" eudora=3D"autourl">http://www.jdrosen.net  = ; </a> PH: (973) 952-5000 <br> <a href=3D"http://www.dynamicsoft.com/" eudora=3D"autourl">http://www.dynami= csoft.com</a> <br> <br> <br> _______________________________________________ <br> IPTEL mailing list <br> [email protected] <br> <a href=3D"http://lists.bell-labs.com/mailman/listinfo/iptel"= eudora=3D"autourl">http://lists.bell-labs.com/mailman/listinfo/iptel</a></b= lockquote></blockquote><br> -- <br> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ <br> | Name : Anirudh Sahoo = | = | US mail= : | <br> | email : [email protected] = | = | 170 W. Tasman Dr| <br> | Tel : 408-525-4508 = ||| = ||| M/S: SJC21/2 | <br> | Fax : 408-526-8521 = ||||| ||||| San= Jose, | <br> | &nb= sp; = ..:|||||||:...:|||||||:.. CA - 95134 | <br> | &nb= sp; &= nbsp; Cisco Systems= Inc.  = ; | <br> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ <br> </font></blockquote></html> --=====================_12294348==_.ALT--