Re: draft-ietf-iptel-trip-gw-00.txt has been posted
Dhaval Shah <[email protected]> Thu, 26 Sep 2002 10:53:25 -0700
| Newsgroups | gmane.ietf.iptel |
|---|---|
| Message-ID | <[email protected]> |
--=====================_4405444==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed 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 --=====================_4405444==_.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html> <font size=3D3><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.</font></blockquote><br> <font size=3D3>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.</font></blockquote><br> <font size=3D3>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.</font></blockquote><br> <font size=3D3>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> </font>Thx,<br> Dhaval<br> <br> <br> <br> <blockquote type=3Dcite cite><font size=3D3>-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=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.dynamicsoft.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"auto= url">http://lists.bell-labs.com/mailman/listinfo/iptel</a></font></blockquot= e></html> --=====================_4405444==_.ALT--