Subject: Re: [IPTEL] draft-ietf-iptel-trip-gw-00.txt has been posted

From: Dhaval Shah <[email-masked]>
Date: Thu, 26 Sep 2002 10:53:25 -0700

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-masked]                 FAX: (973) 952-5050
>http://www.jdrosen.net                  PH:  (973) 952-5000
>http://www.dynamicsoft.com
>
>
>_______________________________________________
>IPTEL mailing list
>[email-masked]
>http://lists.bell-labs.com/mailman/listinfo/iptel

---

From: Anirudh Sahoo <[email-masked]>
Date: Thu, 26 Sep 2002 12:45:02 -0700

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:

>> 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.
>
>
>
>> 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.
>> --
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Name :  Anirudh Sahoo       |           |       US mail :       |
| email : [email-masked]    |           |       170 W. Tasman Dr|
| Tel :   408-525-4508       |||         |||      M/S: SJC21/2    |
| Fax :   408-526-8521      |||||       |||||     San Jose,       |
|                       ..:|||||||:...:|||||||:.. CA - 95134      |
|                           Cisco Systems Inc.                    |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---

From: Dhaval Shah <[email-masked]>
Date: Thu, 26 Sep 2002 13:05:16 -0700

Hi Anirudh,

>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.

>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.

>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.

>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

>>>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.
>>>