From extest-admin@lists.bell-labs.com Mon Jul 1 05:00:13 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11306 for ; Mon, 1 Jul 2002 05:00:13 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g61910213709 for ; Mon, 1 Jul 2002 05:01:00 -0400 Date: Mon, 1 Jul 2002 05:01:00 -0400 Message-Id: <200207010901.g61910213709@share.research.bell-labs.com> Subject: lists.bell-labs.com mailing list memberships reminder From: mailman-owner@lists.bell-labs.com To: iptel-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: extest-admin@lists.bell-labs.com Errors-To: extest-admin@lists.bell-labs.com X-BeenThere: extest@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk This is a reminder, sent out once a month, about your lists.bell-labs.com mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, iptel-request@lists.bell-labs.com) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@lists.bell-labs.com. Thanks! Passwords for iptel-archive@lists.ietf.org: List Password // URL ---- -------- iptel@lists.bell-labs.com nexaew http://lists.bell-labs.com/mailman/options/iptel/iptel-archive%40lists.ietf.org From iptel-admin@lists.bell-labs.com Sat Jul 13 05:56:59 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18914 for ; Sat, 13 Jul 2002 05:56:59 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g6D9l7210424; Sat, 13 Jul 2002 05:47:07 -0400 Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g6D9ka210404 for ; Sat, 13 Jul 2002 05:46:36 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g6D9jV6R096683 for ; Sat, 13 Jul 2002 05:45:31 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id 160404439E; Sat, 13 Jul 2002 05:46:31 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.bell-labs.com (Postfix) with ESMTP id E13B54439D for ; Sat, 13 Jul 2002 05:46:30 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with SMTP id g6D9kTo04566 for ; Sat, 13 Jul 2002 05:46:29 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by dusty; Sat Jul 13 05:46:25 EDT 2002 Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g6D9kLYH005306 for ; Sat, 13 Jul 2002 05:46:23 -0400 (EDT) Message-ID: <3D2FA20E.3010202@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: list iptel Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPTEL] iptel wg meeting in Yokohama is CANCELLED Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Fri, 12 Jul 2002 23:44:14 -0400 Content-Transfer-Encoding: 7bit Folks, As you (possibly) know, I went ahead and reserved a meeting slot for the iptel group at IETF 54. The purpose would have been to facilitate discussion of any open issues on trip-gw which were not progressing well on the list. However, list traffic has been primarily queries and minor comments, nothing of sufficient difficulty to warrant any face-to-face time. Furthermore, no one sent me any agenda requests. I also suspect that many iptel participants are not at Yokohama. So, the iptel meeting at IETF 54 is CANCELLED. Lets try to finish trip-gw before the next IETF, so we don't have to go through this again. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Sat Jul 13 06:01:28 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19019 for ; Sat, 13 Jul 2002 06:01:28 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g6D9uR210569; Sat, 13 Jul 2002 05:56:27 -0400 Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g6D9ks210411 for ; Sat, 13 Jul 2002 05:46:54 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g6D9jm6R096689 for ; Sat, 13 Jul 2002 05:45:48 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id 8E0404439E; Sat, 13 Jul 2002 05:46:48 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.bell-labs.com (Postfix) with ESMTP id 576E24439D for ; Sat, 13 Jul 2002 05:46:48 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with SMTP id g6D9kko04608 for ; Sat, 13 Jul 2002 05:46:47 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by dusty; Sat Jul 13 05:46:40 EDT 2002 Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g6D9kdYH005312; Sat, 13 Jul 2002 05:46:40 -0400 (EDT) Message-ID: <3D2FA3DB.4030006@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gary Chung Wing Cc: "'iptel@lists.bell-labs.com'" Subject: Re: [IPTEL] TRIPGW Update Attributes References: <8BAF8B40C4D2D411ADC300508BD63D6901ADC3A1@mail.ss8.ca> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Fri, 12 Jul 2002 23:51:55 -0400 Content-Transfer-Encoding: 7bit responses inline. Sorry for the delay. Gary Chung Wing wrote: > Hello, I need some clarification regarding interpreting the new > attributes > sent in the Update. > > Can you confirm/correct my understanding of how to interpret a gateway's > advertisement for the following. Given an Update advertising a prefix > address family(say 1671) with 2 types of modifying attributes: carrier > attribute (cic1 and cic2) and trunk group attribute (tg1 and tg2). Is > the > following correct: > > - there is NO association between the cic and the trunk group attributes > sent in the Update; i.e. an LS cannot assume that the gateway advertises > that tg1 is connected to cic1 and tg2 is connected to cic2; or any kind > of > relationship between the cic attributes and the tg attributes. Correct. > - assuming the attributes are unassociated, the semantics of the message > states that the gateway can route incoming calls from the IP side for > the > given prefix on any of the trunk groups advertised OR through any of the > cics on the trunk (pstn) side. Is this right? Yes. > - assuming that the above is true, and given that the GW advertises as > above, does it make sense for any signaling hop on the IP side to send a > signaling message (eg. SIP INV) to this GW, specifying a combination > Prefix > Address Family, Carrier attribute, and Trunkgroup attribute (for example > 16172345678, cic1, tg1)? Sure. > How can a GW honour this request with this > combination of route elements? Well, its supported according to the advertised route. > - Again given the GW advertises as described above, what should the GW > (typically) do to route the call when it receives from a signaling hop > on > the IP side a signaling message (eg. SIP INV), as described below: > > case 1: > prefix=1617 > attribute cic=cic3: > > Should the GW select a route only using the prefix, discarding the cic? > or > should it fail the call since the cic specified in the INVITE cannot be > satisfied? This is more of a tel URI issue, as its orthogonal to TRIP. What generally does a gateway do when it receives a SIP request with a tel URI requesting an unsupported cic? I would argue it probably rejects it with a 404. > > case 2: > prefix=1617 > no attribute sent > > Should GW select a route only using the prefix as a criteria? If it receives a SIP INVITE like INVITE sip:16175551212@gw.com SIP/2.0 it routes that as best it can. Since no trunk group or cic or anything else was specified, it can route it however it likes. > > case 3: > prefix=1905 > cic=cic1 > > Should GW fail the call since the address family is prefix and there is > no > match on the given prefix or would it simply use the cic to route the > call. Same as all of the rest of the above. If the gateway can't complete a call to a given URI, it rejects with a 404. This has nothing to do with trip. > > - Is there any network topology on the trunk (pstn) side of the GW that > an > LS can assume when it receives a TRIPGW Update message as described > above? No. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Sat Jul 13 06:02:49 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19068 for ; Sat, 13 Jul 2002 06:02:49 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g6DA02210618; Sat, 13 Jul 2002 06:00:02 -0400 Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g6D9lB210426 for ; Sat, 13 Jul 2002 05:47:11 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by crufty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g6D9lBCT087299 for ; Sat, 13 Jul 2002 05:47:11 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id 584234439E; Sat, 13 Jul 2002 05:47:06 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.bell-labs.com (Postfix) with ESMTP id 0943D4439D for ; Sat, 13 Jul 2002 05:47:06 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with SMTP id g6D9l4o04632 for ; Sat, 13 Jul 2002 05:47:04 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by dusty; Sat Jul 13 05:46:58 EDT 2002 Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g6D9ksYH005318; Sat, 13 Jul 2002 05:46:55 -0400 (EDT) Message-ID: <3D2FA767.3060505@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Manjunath S Bangalore Cc: "Rick W. Porter" , IPTEL Subject: Re: [IPTEL] Prefix attribute References: <3D0915EA.1AE92C9@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Sat, 13 Jul 2002 00:07:03 -0400 Content-Transfer-Encoding: 7bit Manjunath S Bangalore wrote: >>2) Do the address families in the Prefix attribute need to be >> negotiated in >>the Open exchange? >> > > > I guess you are refering to the different prefix attribute types - > E.164, > Decimal, and PentaDecimal? > Each of these three prefix types has its own attribute type code. The > prefix > attribute types are > currently not included in the OPEN message caps exchange. > > Let me state the problem you mention, correct me if I am wrong. When a > Gateway > advertising routes > using the Trunkgroup address family, for instance, is reporting all the > three > prefix attribute types, but the > TRIP LS processing these gateway routes, has the capability for handling > only > the E.164 prefix type, it > could run into trouble, when it receives Decimal and Pentadecimal > Prefixes. > > I see your point, maybe we need to introduce a PrefixCapability in the > OPEN > message caps. negotiation. > Will write back on this issue after further thought. I think its sufficient to just apply the existing Route type capability to this attribute as well. That is, if a gateway advertises a capability for e.164 and pentadecimal, that means it can support those address families, and also the corresponding two prefix attributes. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Sat Jul 13 06:03:49 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19095 for ; Sat, 13 Jul 2002 06:03:49 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g6DA3I210759; Sat, 13 Jul 2002 06:03:18 -0400 Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g6D9lH210433 for ; Sat, 13 Jul 2002 05:47:17 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g6D9kC6R096695 for ; Sat, 13 Jul 2002 05:46:12 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id 2D4DF4439E; Sat, 13 Jul 2002 05:47:12 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.bell-labs.com (Postfix) with ESMTP id F1CDF4439D for ; Sat, 13 Jul 2002 05:47:11 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with SMTP id g6D9lAo04653 for ; Sat, 13 Jul 2002 05:47:10 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by dusty; Sat Jul 13 05:47:06 EDT 2002 Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g6D9l4YH005321; Sat, 13 Jul 2002 05:47:04 -0400 (EDT) Message-ID: <3D2FABE2.3010508@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Manjunath S Bangalore Cc: Bob Penfield , iptel@lists.bell-labs.com, Dhaval Shah Subject: Re: [IPTEL] draft-ietf-iptel-trip-gw-00.txt has been posted References: <3D07C83D.422AFEBB@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Sat, 13 Jul 2002 00:26:10 -0400 Content-Transfer-Encoding: 7bit inline. Manjunath S Bangalore wrote: > Hi Bob, > > Thank you for the comments. Some responses inlined... > > Bob Penfield wrote: > > >>2) For the CallSuccess attribute (sec 4.3), there is no guidance or >>indication given as to the time period for which the total and >> successful >>calls apply. Providing information which is measured over a several >> days may >>not be as useful as information about the last few minutes. I suggest >> the >>addition of the measurement period in seconds, and/or some guidance be >> given >>as the "time window" that gateways should use for reporting >> CallSuccess. > > The gateway reporting the Call Success attribute can discard old values > replacing them > with newer values after certain periods of time. The duration that it > chooses to > retain call > success information for, can be a local matter based on vendor > preferences, > possibly > based on the volume and nature of traffic handled by this network. > > We will give further thought on including a measurement period in > conjunction > with the > Call Success information that is reported. 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. > >>5) I don't understand why the Carrier attribute would be prohibited >> when the >>TrunkGroup address family is used and why the TrunkGroupAttribute >> cannot be >>used with the Carrier address family. It seems to me that a gateway >> divided >>into trunkgroups, each of which reach one or more carriers, would >> advertise >>its routes using the trunkgroup address family, listing the carriers >> and >>prefixes reachable thru that trunkgroup. The updates would include the >>available & total circuits, and call success attributes. When these >> routes >>were consolidated, the trunkgroup would be stripped, and a set of >>prefix-based routes (with carrier attributes) would be injected to the >>I-TRIP/E-TRIP LS. If the carrier attribute cannot be included, how are >> the >>trunkgroups and carriers to be associated? Are you suggesting the same >>routes would be multiply advertised with different address families? > > > The stance that we have taken with the current version of the draft is > to > address > gateway management based, purely on Carriers or Trunkgroups, not as a > combination. The policy in the provider network in combination with the > choice of managing gateway resources at the granularity of either > trunkgroups or > carrierswould help determine which address family is used to advertise > routes > from the gateway. Some additional comments in this regard follow later > > The current plan is to address management of gateways on the basis of > "Carrier and Trunkgroup" as a combined unit in the next version of the > draft. 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. Secondly, I do not think we should restrict a gw from advertising, to a particular peer LS, routes for EITHER the trunk group OR carrier OR regular e.164/dec/pent address families. It should be permitted to mix these. There are implications, however. This implies that there could be overlap in routes. What does this mean for things like TotalCapacity? > > >>BTW, I think the draft should explicitly mention "converting" routes >> from >>one address family to another using the associated attributes. For >> example, >>the Prefix attribute allows for converting trunkgroup-based and >>carrier-based routes into prefix-based routes for the I/E-TRIP LS. > > > Yes, this is one of the purposes of consolidation - Converting routes > from one > address family to > another using the relevant attributes to build the routes in the > recipient > address family. The > address family to which the gateway routes are transformed is dictated > by the > provider policy; > it is possible that the routing policy in the network is based on > Trunkgroups, > and routes > received on the Trunkgroup address family from the gateway may be > propogated to > I-TRIP > on the same address family, after possibly modifying the nexthop server > to the > managing LS/Proxy. > For E-TRIP, routes may be transformed to the Prefix address family as > you > mentioned above. > > The draft can mention "converting" routes from one address family to > another as > part of the > consolidation process but should not place a restriction on what address > families are chosen > to propogate the routes further on I/E TRIP, which is policy-driven. I agree it should mention this converstion. Indeed, the section on consolidation needs to talk a LOT more about the kinds of things that can be done. > > >>7) There is no restrictions or guidance given on the address families >> that >>gateways use to advertise their routes. There is almost an implication >> that >>gateways will advertise the same routes in different forms (with >> different >>address families). If a gateways advertises all its prefixes as >>reachable-routes an also advertises its trunk-groups as reachable >> routes >>with prefix attributes, Is the LS suppose to use the Prefix attribute >> in the >>trunkgroup reachable routes to determine that they are the same sets >> of >>routes? If so, it should be explicitly stated. As I indicated before, >> I >>think being able to take trunkgroup-based or carrier-based routes and >>convert them into prefix-based routes to inject into the I/E-TRIP is >> very >>useful because prefix-based routes are most suitable for I/E-TRIP and >>trunkgroup or carrier based routes bets express the routes in a >> gateway. > > The understanding is, that at any given time, it suffices for the > gateway to > advertise > routes on any one address family, the choice of which is driven by the > management > model in a provider network. If the choice is to manage gateways at the > granularity of > trunkgroup resources, then Trunkgroup address family can be used; > Similarly, > Carrier address family can be used if gateways are managed in terms of > Carriers. > If there > is no notion of trunkgroups or Carriers in the network, then Prefix > address > family should > be used to advertise only the reachability to PSTN prefixes. 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. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue Jul 16 18:35:42 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01544 for ; Tue, 16 Jul 2002 18:35:41 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g6GMGE205616; Tue, 16 Jul 2002 18:16:14 -0400 Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g6GMFK205603 for ; Tue, 16 Jul 2002 18:15:20 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g6GME76R033231 for ; Tue, 16 Jul 2002 18:14:07 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id 2CF0F4439E; Tue, 16 Jul 2002 18:15:15 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.bell-labs.com (Postfix) with ESMTP id 076104439D for ; Tue, 16 Jul 2002 18:15:15 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with SMTP id g6GMFDo50938 for ; Tue, 16 Jul 2002 18:15:13 -0400 (EDT) Received: from sj-msg-core-1.cisco.com ([171.71.163.11]) by dusty; Tue Jul 16 18:15:08 EDT 2002 Received: from mira-sjcm-4.cisco.com (IDENT:mirapoint@mira-sjcm-4.cisco.com [171.69.24.43]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g6GMFAM2025617 for ; Tue, 16 Jul 2002 15:15:10 -0700 (PDT) Received: from cisco.com (dhcp-128-107-166-89.cisco.com [128.107.166.89]) by mira-sjcm-4.cisco.com (Mirapoint) with ESMTP id AAT82330; Tue, 16 Jul 2002 15:39:45 -0700 (PDT) Message-ID: <3D349AEC.69787BDA@cisco.com> From: "Hussein F. Salama" X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: iptel@lists.bell-labs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [IPTEL] Bugs in RFC 3219 Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Tue, 16 Jul 2002 15:15:09 -0700 Content-Transfer-Encoding: 7bit A couple of errors in RFC 3219 were braught to my attention: 1. In Section 10.3.1.1, first bullet, replace "lowest value of MultiExitDisc" with "highest value of MultiExitDisc" to be consistent with Section 5.8.3. 2. In section 10.3.1.1, second bullet, replace "lowest TRIP identifier" with "lowest ITAD number" to be consistent with the text of Section 10.2.2.1. I propose to notify the RFC editor to post a note at http://www.rfc-editor.org/errata.html Thanks. Hussein -- Hussein F. Salama Cisco Systems Mail Stop SJC-24/3, 170 W. Tasman Drive, San Jose, CA 95134 Voice: +1 (408) 527-7147, Fax: +1 (408) 527-7147 _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Thu Jul 18 08:31:46 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00224 for ; Thu, 18 Jul 2002 08:31:46 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g6ICVm215936; Thu, 18 Jul 2002 08:31:48 -0400 Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g6ICN7215859 for ; Thu, 18 Jul 2002 08:23:07 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g6ICLo6R052843 for ; Thu, 18 Jul 2002 08:21:50 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id A7159443A0; Thu, 18 Jul 2002 08:23:01 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.bell-labs.com (Postfix) with ESMTP id 7B56E4439D for ; Thu, 18 Jul 2002 08:23:01 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with SMTP id g6ICMxk12607 for ; Thu, 18 Jul 2002 08:22:59 -0400 (EDT) Received: from smtp5.cluster.oleane.net ([195.25.12.27]) by dusty; Thu Jul 18 08:22:55 EDT 2002 Received: from oleane (upper-side.rain.fr [194.250.212.114]) by smtp5.cluster.oleane.net with SMTP id g6ICMuU82458 for ; Thu, 18 Jul 2002 14:22:56 +0200 (CEST) Message-ID: <007601c22e57$0fc38720$0701a8c0@oleane.com> From: "Peter Lewis" To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0073_01C22E67.D30933A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Subject: [IPTEL] International SIP conference, Paris, third edition Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Thu, 18 Jul 2002 14:31:37 +0200 This is a multi-part message in MIME format. ------=_NextPart_000_0073_01C22E67.D30933A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 International SIP conference, Paris, third edition. The principal worldwide SIP event will take place in Paris from 14 to 17 = January 2003. The call for proposals dead line has been postponed to August 21st. Please get all details at: http://www.upperside.fr/intersip03/sip03intro.htm ------=_NextPart_000_0073_01C22E67.D30933A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
International SIP conference, Paris, third=20 edition.
The principal worldwide SIP event will take place in = Paris=20 from 14 to 17 January 2003.
The call for proposals dead line has been postponed = to August=20 21st.
Please get all details at:
http://www.upp= erside.fr/intersip03/sip03intro.htm
 
------=_NextPart_000_0073_01C22E67.D30933A0-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri Jul 19 15:31:56 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16353 for ; Fri, 19 Jul 2002 15:31:56 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g6JJW8225370; Fri, 19 Jul 2002 15:32:08 -0400 Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g6JJVp225357 for ; Fri, 19 Jul 2002 15:31:51 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g6JJUV6R071709 for ; Fri, 19 Jul 2002 15:30:31 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id 62E354439E; Fri, 19 Jul 2002 15:31:46 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.bell-labs.com (Postfix) with ESMTP id 3DA1E4439D for ; Fri, 19 Jul 2002 15:31:46 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with SMTP id g6JJVio39595 for ; Fri, 19 Jul 2002 15:31:44 -0400 (EDT) Received: from broadsoft.com ([198.104.184.110]) by dusty; Fri Jul 19 15:31:39 EDT 2002 Received: from tate (host4.brodsoft.com [66.160.10.4] (may be forged)) by broadsoft.com (8.11.6) id g6JJVdY32093; Fri, 19 Jul 2002 15:31:43 -0400 (EDT) Reply-To: From: "Brett Tate" To: Message-ID: <001401c22f5b$32979700$2b01a8c0@broadsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Subject: [IPTEL] rfc2806bis-05 comments: parameters and telephone-subscriber Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Fri, 19 Jul 2002 15:33:44 -0400 Content-Transfer-Encoding: 7bit rfc2806bis-05 BNF describes an explicit ordering of the parameters in regards to isdn-subaddress, context, and param. If this explicit ordering was not intended, the BNF should be changed or explicit text should be added to indicate that the above parameters are not required to be in an explicit order. Adding back a telephone-subscriber definition might help accommodate the above. It would also help in correlating rfc3261's telephone-subscriber reference to rfc2806bis. -brett _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel