Re: draft-ietf-iptel-trip-gw-00.txt has been posted
Anirudh Sahoo <[email protected]> Thu, 26 Sep 2002 12:45:02 -0700
| Newsgroups | gmane.ietf.iptel |
|---|---|
| Message-ID | <[email protected]> |
--------------6D7CF4B0BED040ECBE5FDF6E
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
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).
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.
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.
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
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. |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--------------6D7CF4B0BED040ECBE5FDF6E
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by sj-msg-core-2.cisco.com id g8QJj3Ha017821
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
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
<br>T family advertisement may be used (with C as attr).
<br>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
<br>multiple addr fam, then implementors will have flexibility to
<br>do whichever way they deem appropriate for their case.
<br> 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
<br>important, a T family will be suitable.
<br> Since allowing 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
<br>the draft should allow that. Otherwise, it will become restrictive
for
<br>the above scenarios.
<p>Dhaval Shah wrote:
<blockquote TYPE=3DCITE>
<br><font size=3D+0>Please see some comments and questions inlined.</font=
>
<br>
<br>
<blockquote type=3Dcite cite><font size=3D+0>I don't think we need to sta=
ndardize
a window, but the spec should suggest that sufficiently large windows be
used to provide a useful aggregated statistic.</font></blockquote>
<p><br><font size=3D+0>We'll incorporate this.</font>
<br>
<blockquote type=3Dcite cite><font size=3D+0>Two comments.</font>
<p><font size=3D+0>First, I agree with Bob that we should allow the carri=
er
attribute to be present in the trunk group address family. There was anot=
her
comment to the list regarding that.</font></blockquote>
<p><br><font size=3D+0>Will do that. Also, we are thinking of proposing t=
o
allow for T attribute to be present in C address family.</font>
<br>
<br>
<blockquote type=3Dcite cite><font size=3D+0>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 advertis=
e
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.</font>
<p><font size=3D+0>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 wou=
ld
need to know how these are correlated in order to properly manipulate the=
m.
I think this is a recipe for disaster, and I would prefer to mandate the
non-overlapping case above.</font></blockquote>
<p><br><font size=3D+0>After much thought, some of us feel that providing
three address families but allowing use one at a time is</font>
<br><font size=3D+0>sufficient.</font>
<p><font size=3D+0>So, the question here is: Can we come up with a reason=
able
example, that includes a TGREP/TRIP reachability</font>
<br><font size=3D+0>flow and a call flow, describing how/why an actual&nb=
sp;
customer may need this flexibility?</font>
<p>Thx,
<br>Dhaval
<br>
<br>
<br>
<blockquote type=3Dcite cite><font size=3D+0>-Jonathan R.</font>
<br><font size=3D+0>--</font>
<br><font size=3D+0>Jonathan D. Rosenberg, Ph.D. &=
nbsp;
72 Eagle Rock Avenue</font>
<br><font size=3D+0>Chief Scientist &n=
bsp; &nb=
sp;
First Floor</font>
<br><font size=3D+0>dynamicsoft =
&=
nbsp;
East Hanover, NJ 07936</font>
<br><font size=3D+0>[email protected] =
FAX: (973) 952-5050</font>
<br><font size=3D+0><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.ne=
t =
</a>PH: (973) 952-5000</font>
<br><font size=3D+0><a href=3D"http://www.dynamicsoft.com/" eudora=3D"aut=
ourl">http://www.dynamicsoft.com</a></font>
<br>
<p><font size=3D+0>_______________________________________________</font>
<br><font size=3D+0>IPTEL mailing list</font>
<br><font size=3D+0>[email protected]</font>
<br><font size=3D+0><a href=3D"http://lists.bell-labs.com/mailman/listinf=
o/iptel" eudora=3D"autourl">http://lists.bell-labs.com/mailman/listinfo/i=
ptel</a></font></blockquote>
</blockquote>
<p>--
<br>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
<br>| Name : Anirudh Sahoo |&nb=
sp;
| US mail : &n=
bsp;
|
<br>| email : [email protected] |  =
;
| 170 W. Tasman Dr|
<br>| Tel : 408-525-4508
||| ||| =
M/S: SJC21/2 |
<br>| Fax : 408-526-8521 |||||&=
nbsp;
||||| San Jose, &nbs=
p;
|
<br>| &n=
bsp;
..:|||||||:...:|||||||:.. CA - 95134 |
<br>| &n=
bsp; &nb=
sp;
Cisco Systems Inc. &=
nbsp;
|
<br>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
<br> </html>
--------------6D7CF4B0BED040ECBE5FDF6E--