From kcartwright@tnsi.com Mon Aug 3 12:25:02 2009 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEB3A3A6E25 for ; Mon, 3 Aug 2009 12:25:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0BIbQBsKp6Hv for ; Mon, 3 Aug 2009 12:25:01 -0700 (PDT) Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by core3.amsl.com (Postfix) with ESMTP id E0E603A6E9A for ; Mon, 3 Aug 2009 12:24:53 -0700 (PDT) Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.31394053; Mon, 03 Aug 2009 15:27:52 -0400 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.219]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Mon, 3 Aug 2009 15:24:36 -0400 From: "Cartwright, Kenneth" To: Brian Rosen , "'Guyton, Deborah A'" , "'PFAUTZ, PENN L, ATTCORP'" , 'Alexander Mayrhofer' , "drinks@ietf.org" Date: Mon, 3 Aug 2009 15:24:34 -0400 Thread-Topic: [drinks] Comment on today's drinks discussion Thread-Index: AcoO2bJ+NAGUY74URde2rAIW8CFO0wAASmUAAGuYGvAAFaa4wAAAl+uQAOMZsaA= Message-ID: <754963199212404AB8E9CFCA6C3D0CDA0725ACE318@TNS-MAIL-NA.win2k.corp.tnsi.com> References: <35FE871E2B085542A35726420E29DA6B01F18918@gaalpa1msgusr7a.ugd.att.com> <8BC845943058D844ABFC73D2220D46650863B5B0@nics-mail.sbg.nic.at> <35FE871E2B085542A35726420E29DA6B01FA1C64@gaalpa1msgusr7a.ugd.att.com> <00e801ca10e2$b043b100$10cb1300$@net> In-Reply-To: <00e801ca10e2$b043b100$10cb1300$@net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [drinks] Comment on today's drinks discussion X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 19:25:02 -0000 Thanks. Can you please provide more detail on this so that we are able to = assess whether we need to add something to the protocol to support it. Mor= e specifically: 1) Numbers can certainly be "resold" as you say (e.g. an MVNO). But what i= mpact does this have on the features of the protocol? I do not think the U= se Case document contains use cases that document what you may be getting a= t. 2) What exactly do you mean by "SOME provisioning responsibility goes with = the resale". 3) You separately ("there are also cases") refer to the fact that there are= "chains of resellers" and "the services each can provision may be differen= t". Can you be more specific with what you mean by "services" in the above= statement? Thanks -----Original Message----- From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of= Brian Rosen Sent: Thursday, July 30, 2009 2:55 AM To: 'Guyton, Deborah A'; 'PFAUTZ, PENN L, ATTCORP'; 'Alexander Mayrhofer'; = drinks@ietf.org Subject: Re: [drinks] Comment on today's drinks discussion I got into this with some real world issues where numbers are resold, and SOME provisioning responsibility goes with the resale. There are also case= s where there is a chain of resellers, and the services each can provision ma= y be different. Brian > -----Original Message----- > From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On > Behalf Of Guyton, Deborah A > Sent: Thursday, July 30, 2009 2:42 AM > To: 'PFAUTZ, PENN L, ATTCORP'; Alexander Mayrhofer; drinks@ietf.org > Subject: Re: [drinks] Comment on today's drinks discussion > > Hi Penn, > Hopefully I can clear up one item quickly. The idea of "Registrant" is > the notion that a "Registrar" who is the "holder" of the data or > carrier of record, for example, might outsource the administration of > that data to a "Registrant". An analogy in today's world is that some > companies do not manage their own data in LERG but outsource to a > third party. It may be necessary to allow for an individual > administrator "Joe Administrator" to be the responsible individual for > administering that data - hence having a login and password > (particularly for a GUI) but could be a login and password for a > service provisioning interface. For data issues, you might need to > resolve with a person. > If administration is done as it is today, perhaps for AT&T, Registrar =3D > AT&T and Registrant =3D AT&T. > Hope that helps. > Debbie > > -----Original Message----- > From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On > Behalf Of PFAUTZ, PENN L, ATTCORP > Sent: Wednesday, July 29, 2009 4:39 PM > To: Alexander Mayrhofer; drinks@ietf.org > Subject: Re: [drinks] Comment on today's drinks discussion > > Alex: > My concerns are not entirely with respect to the current draft but some > of the directions that the discussion during the WG session suggested > the work might be taking. > > I've had a lingering concern about the disconnect between what > Speermint > has proposed (LUF/LRF)and the route that drinks has taken. Since the > will of the design team seemed to be to get on with a simple protocol > directed toward provisioning DNS RRs I let that ride. Monday's session, > however brought up things like more abstraction of routing elements > which suggests to me assumptions about the nature of interconnections > and my issues with the original ESPP I-D. > > Brian Rosen's comment about number "ownership" relations also seemed to > suggest another complexity that the protocol would try to incorporate. > > I get concerned about a protocol that either makes a lot of specific > assumptions about the nature of the registry and the interconnection > framework and/or becomes bloated by trying to incorporate the panoply > of > possible cases. > > A more specific issue - the definition of Registrant as an "end user" - > this is at least confusing in the context of Infrastructure vs. End > User > ENUM. > > I'll keep watching how things evolve. It may be that others conclude > they need the added complexity but I wanted to be forthright about my > position. > Thanks for listening. > > > Penn Pfautz > AT&T Access Management > +1-732-420-4962 > > -----Original Message----- > From: Alexander Mayrhofer [mailto:alexander.mayrhofer@nic.at] > Sent: Monday, July 27, 2009 12:56 PM > To: PFAUTZ, PENN L, ATTCORP; drinks@ietf.org > Subject: RE: [drinks] Comment on today's drinks discussion > > > I for one have concerns about how useful the resulting > > protocol is likely to be, at least for my company's likely > > applications. > > Penn, > > Thanks for that "wakeup call" - as we said we want definitely a > deployable protocol, so i'm concerned about your statement - could you > elaborate of what properties of the current draft would make it less > useful for your company's applications, and what could be done to make > it fit better? > > Thanks > > Alex > _______________________________________________ > drinks mailing list > drinks@ietf.org > https://www.ietf.org/mailman/listinfo/drinks > _______________________________________________ > drinks mailing list > drinks@ietf.org > https://www.ietf.org/mailman/listinfo/drinks _______________________________________________ drinks mailing list drinks@ietf.org https://www.ietf.org/mailman/listinfo/drinks This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. From kcartwright@tnsi.com Mon Aug 3 12:28:08 2009 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D43D3A6BAA for ; Mon, 3 Aug 2009 12:28:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bzZYpN-xYhND for ; Mon, 3 Aug 2009 12:28:03 -0700 (PDT) Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by core3.amsl.com (Postfix) with ESMTP id 7E0C73A6985 for ; Mon, 3 Aug 2009 12:28:03 -0700 (PDT) Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.31394172; Mon, 03 Aug 2009 15:31:12 -0400 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.219]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Mon, 3 Aug 2009 15:27:56 -0400 From: "Cartwright, Kenneth" To: "PFAUTZ, PENN L, ATTCORP" , "drinks@ietf.org" Date: Mon, 3 Aug 2009 15:27:54 -0400 Thread-Topic: Comment on today's drinks discussion Thread-Index: AcoO2bJ+NAGUY74URde2rAIW8CFO0wFlm5ZQ Message-ID: <754963199212404AB8E9CFCA6C3D0CDA0725ACE31C@TNS-MAIL-NA.win2k.corp.tnsi.com> References: <35FE871E2B085542A35726420E29DA6B01F18918@gaalpa1msgusr7a.ugd.att.com> In-Reply-To: <35FE871E2B085542A35726420E29DA6B01F18918@gaalpa1msgusr7a.ugd.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_754963199212404AB8E9CFCA6C3D0CDA0725ACE31CTNSMAILNAwin2_" MIME-Version: 1.0 Subject: Re: [drinks] Comment on today's drinks discussion X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 19:28:08 -0000 --_000_754963199212404AB8E9CFCA6C3D0CDA0725ACE31CTNSMAILNAwin2_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for the feedback. 1) How do you feel that we are not supporting the LUF/LRF concepts? Can't = a Destination Group and its associated Route Group be used to return a URI = whose domain name is the one that requires as an output of the LUF? Or is = there something that I'm missing? 2) What specifically would need to be done to the protocol to make it more = useful for your company's likely applications? Ken ________________________________ From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of= PFAUTZ, PENN L, ATTCORP Sent: Monday, July 27, 2009 12:46 PM To: drinks@ietf.org Subject: [drinks] Comment on today's drinks discussion I've been away from the design group for a while since the focus seemed to = shift more to lower level design issues outside of my bailiwick but I came = away from today's IETF discussion with an uncomfortable feeling about where= the drinks effort is heading. One the one hand I feel that some of the issues we agreed to set aside to n= arrow scope (LUF/LRF) are coming back to haunt us and on the other that the= effort is straining as Otmar suggests to accommodate more and more complex= ity that should, perhaps be handled elsewhere. Perhaps these are different = sides of the same coin. I for one have concerns about how useful the resulting protocol is likely t= o be, at least for my company's likely applications. Penn Pfautz AT&T Access Management +1-732-420-4962 ________________________________ This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. --_000_754963199212404AB8E9CFCA6C3D0CDA0725ACE31CTNSMAILNAwin2_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks for the feedback.

 

1) How do you feel that we are not sup= porting the LUF/LRF concepts?  Can’t a Destination Group and its= associated Route Group be used to return a URI whose domain name is the one that requires as an output of= the LUF?  Or is there something that I’m missing?

 

2) What specifically would need to be = done to the protocol to make it more useful for your company’s likely= applications?

 

Ken

 

From: drin= ks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of PFAUTZ, PENN L,= ATTCORP
Sent: Monday, July 27, 2009 = 12:46 PM
To: drinks@ietf.org
Subject: [drinks] Comment on= today's drinks discussion

 

I've been away from the design group for a while since t= he focus seemed to shift more to lower level design issues outside of my ba= iliwick but I came away from today's IETF discussion with an uncomfortable feeling about where the= drinks effort is heading.

One the one hand I feel that some of the issues we agree= d to set aside to narrow scope (LUF/LRF) are coming back to haunt us a= nd on the other that the effort is straining as Otmar suggests to accommodate more and more complexity tha= t should, perhaps be handled elsewhere. Perhaps these are different sides o= f the same coin.

I for one have concerns about how useful the result= ing protocol is likely to be, at least for my company's likely applications= .

 

 

Penn Pfautz

AT&T Access Management

+1-732-420-4962

 


This e-mail message is for t= he sole use of the intended recipient(s)and may
contain confidential and privileged information of Transaction Network Serv= ices.
Any unauthorised review, use, disclosure or distribution is prohibited. If = you
are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message.

 --_000_754963199212404AB8E9CFCA6C3D0CDA0725ACE31CTNSMAILNAwin2_-- From ppfautz@att.com Mon Aug 3 12:37:12 2009 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7814E3A6DB8 for ; Mon, 3 Aug 2009 12:37:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s00xhkz-h77l for ; Mon, 3 Aug 2009 12:37:07 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by core3.amsl.com (Postfix) with ESMTP id 142423A6A57 for ; Mon, 3 Aug 2009 12:37:06 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-6.tower-120.messagelabs.com!1249328227!34049301!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 30704 invoked from network); 3 Aug 2009 19:37:08 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-6.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 Aug 2009 19:37:08 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n73Jb7PT006710 for ; Mon, 3 Aug 2009 15:37:07 -0400 Received: from gaalpa1msgusr7a.ugd.att.com (gaalpa1msgusr7a.ugd.att.com [135.53.26.15]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n73Jb1Dr006664 for ; Mon, 3 Aug 2009 15:37:01 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA1471.C5BA5CD6" Date: Mon, 3 Aug 2009 15:37:00 -0400 Message-ID: <35FE871E2B085542A35726420E29DA6B01FF41AF@gaalpa1msgusr7a.ugd.att.com> In-Reply-To: <754963199212404AB8E9CFCA6C3D0CDA0725ACE31C@TNS-MAIL-NA.win2k.corp.tnsi.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comment on today's drinks discussion Thread-Index: AcoO2bJ+NAGUY74URde2rAIW8CFO0wFlm5ZQAAAx7GA= References: <35FE871E2B085542A35726420E29DA6B01F18918@gaalpa1msgusr7a.ugd.att.com> <754963199212404AB8E9CFCA6C3D0CDA0725ACE31C@TNS-MAIL-NA.win2k.corp.tnsi.com> From: "PFAUTZ, PENN L, ATTCORP" To: "Cartwright, Kenneth" , Subject: Re: [drinks] Comment on today's drinks discussion X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 19:37:12 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA1471.C5BA5CD6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ken: 1) My take was that Speermint separates LUF/LRF. The protocol as defined can certainly support returning a LUF output, but folks seemed to want to push further than that or not make any distinction between the two functions. =20 2) my concern is the increasing complexity takes the protocol beyond our needs which might lead us to look towards something simpler. =20 Penn Pfautz AT&T Access Management +1-732-420-4962 =20 ________________________________ From: Cartwright, Kenneth [mailto:kcartwright@tnsi.com]=20 Sent: Monday, August 03, 2009 3:28 PM To: PFAUTZ, PENN L, ATTCORP; drinks@ietf.org Subject: RE: Comment on today's drinks discussion Thanks for the feedback. =20 1) How do you feel that we are not supporting the LUF/LRF concepts? Can't a Destination Group and its associated Route Group be used to return a URI whose domain name is the one that requires as an output of the LUF? Or is there something that I'm missing? =20 2) What specifically would need to be done to the protocol to make it more useful for your company's likely applications? =20 Ken =20 ________________________________ From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of PFAUTZ, PENN L, ATTCORP Sent: Monday, July 27, 2009 12:46 PM To: drinks@ietf.org Subject: [drinks] Comment on today's drinks discussion =20 I've been away from the design group for a while since the focus seemed to shift more to lower level design issues outside of my bailiwick but I came away from today's IETF discussion with an uncomfortable feeling about where the drinks effort is heading. One the one hand I feel that some of the issues we agreed to set aside to narrow scope (LUF/LRF) are coming back to haunt us and on the other that the effort is straining as Otmar suggests to accommodate more and more complexity that should, perhaps be handled elsewhere. Perhaps these are different sides of the same coin.=20 I for one have concerns about how useful the resulting protocol is likely to be, at least for my company's likely applications. =20 =20 Penn Pfautz AT&T Access Management +1-732-420-4962 =20 ________________________________ This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Services. Any unauthorised review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. ------_=_NextPart_001_01CA1471.C5BA5CD6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Ken:
1) My take was that Speermint separates = LUF/LRF. The=20 protocol as defined can certainly support returning a LUF output, but = folks=20 seemed to want to push further than that or not make any distinction = between the=20 two functions.
 
2) my concern is the increasing complexity = takes the=20 protocol beyond our needs which might lead us to look towards something=20 simpler.
 
Penn Pfautz
AT&T Access = Management
+1-732-420-4962
 

From: Cartwright, Kenneth=20 [mailto:kcartwright@tnsi.com]
Sent: Monday, August 03, 2009 = 3:28=20 PM
To: PFAUTZ, PENN L, ATTCORP; = drinks@ietf.org
Subject: RE:=20 Comment on today's drinks discussion

Thanks for = the=20 feedback.

 

1) How do you = feel that=20 we are not supporting the LUF/LRF concepts?  Can’t a = Destination Group and=20 its associated Route Group be used to return a URI whose domain name is = the one=20 that requires as an output of the LUF?  Or is there something that = I’m=20 missing?

 

2) What = specifically=20 would need to be done to the protocol to make it more useful for your = company’s=20 likely applications?

 

Ken

 

From:=20 drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of PFAUTZ, PENN L,=20 ATTCORP
Sent: Monday, = July 27,=20 2009 12:46 PM
To:=20 drinks@ietf.org
Subject:=20 [drinks] Comment on today's drinks = discussion

 

I've been away from the = design group=20 for a while since the focus seemed to shift more to lower level design = issues=20 outside of my bailiwick but I came away from today's IETF = discussion=20 with an uncomfortable feeling about where the drinks effort is=20 heading.

One the one hand I feel = that some of=20 the issues we agreed to set aside to narrow scope (LUF/LRF) are = coming back=20 to haunt us and on the other that the effort is straining as Otmar = suggests to=20 accommodate more and more complexity that should, perhaps be handled = elsewhere.=20 Perhaps these are different sides of the same coin.=20

I for one have = concerns about=20 how useful the resulting protocol is likely to be, at least for my = company's=20 likely applications.

 

 

Penn=20 Pfautz

AT&T Access=20 Management

+1-732-420-4962

 


This e-mail message is for the = sole use of=20 the intended recipient(s)and may
contain confidential and privileged=20 information of Transaction Network Services.
Any unauthorised review, = use,=20 disclosure or distribution is prohibited. If you
are not the intended = recipient, please contact the sender by reply e-mail and destroy all = copies of=20 the original message.

 ------_=_NextPart_001_01CA1471.C5BA5CD6-- From kcartwright@tnsi.com Mon Aug 3 12:41:51 2009 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CE903A6E7F for ; Mon, 3 Aug 2009 12:41:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ltsGkvsqS5Xl for ; Mon, 3 Aug 2009 12:41:42 -0700 (PDT) Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by core3.amsl.com (Postfix) with ESMTP id D1EFB28C158 for ; Mon, 3 Aug 2009 12:41:41 -0700 (PDT) Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.31394636; Mon, 03 Aug 2009 15:44:32 -0400 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.219]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Mon, 3 Aug 2009 15:41:16 -0400 From: "Cartwright, Kenneth" To: "PFAUTZ, PENN L, ATTCORP" , "drinks@ietf.org" Date: Mon, 3 Aug 2009 15:41:13 -0400 Thread-Topic: Comment on today's drinks discussion Thread-Index: AcoO2bJ+NAGUY74URde2rAIW8CFO0wFlm5ZQAAAx7GAAAEdSkA== Message-ID: <754963199212404AB8E9CFCA6C3D0CDA0725ACE330@TNS-MAIL-NA.win2k.corp.tnsi.com> References: <35FE871E2B085542A35726420E29DA6B01F18918@gaalpa1msgusr7a.ugd.att.com> <754963199212404AB8E9CFCA6C3D0CDA0725ACE31C@TNS-MAIL-NA.win2k.corp.tnsi.com> <35FE871E2B085542A35726420E29DA6B01FF41AF@gaalpa1msgusr7a.ugd.att.com> In-Reply-To: <35FE871E2B085542A35726420E29DA6B01FF41AF@gaalpa1msgusr7a.ugd.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_754963199212404AB8E9CFCA6C3D0CDA0725ACE330TNSMAILNAwin2_" MIME-Version: 1.0 Subject: Re: [drinks] Comment on today's drinks discussion X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 19:41:51 -0000 --_000_754963199212404AB8E9CFCA6C3D0CDA0725ACE330TNSMAILNAwin2_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks. 1) The Speermint Arch doc only separates them logically. It dose not= separate them physically. So Speermint certainly allows that a single pie= ce of software could be both LUF and LRF or just LUF or just LRF. So I thi= nk we're ok on that front. 2) What complexity has "increased"? iow, do you have some specific r= ecommendations? Ken ________________________________ From: PFAUTZ, PENN L, ATTCORP [mailto:ppfautz@att.com] Sent: Monday, August 03, 2009 3:37 PM To: Cartwright, Kenneth; drinks@ietf.org Subject: RE: Comment on today's drinks discussion Ken: 1) My take was that Speermint separates LUF/LRF. The protocol as defined ca= n certainly support returning a LUF output, but folks seemed to want to pus= h further than that or not make any distinction between the two functions. 2) my concern is the increasing complexity takes the protocol beyond our ne= eds which might lead us to look towards something simpler. Penn Pfautz AT&T Access Management +1-732-420-4962 ________________________________ From: Cartwright, Kenneth [mailto:kcartwright@tnsi.com] Sent: Monday, August 03, 2009 3:28 PM To: PFAUTZ, PENN L, ATTCORP; drinks@ietf.org Subject: RE: Comment on today's drinks discussion Thanks for the feedback. 1) How do you feel that we are not supporting the LUF/LRF concepts? Can't = a Destination Group and its associated Route Group be used to return a URI = whose domain name is the one that requires as an output of the LUF? Or is = there something that I'm missing? 2) What specifically would need to be done to the protocol to make it more = useful for your company's likely applications? Ken ________________________________ From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of= PFAUTZ, PENN L, ATTCORP Sent: Monday, July 27, 2009 12:46 PM To: drinks@ietf.org Subject: [drinks] Comment on today's drinks discussion I've been away from the design group for a while since the focus seemed to = shift more to lower level design issues outside of my bailiwick but I came = away from today's IETF discussion with an uncomfortable feeling about where= the drinks effort is heading. One the one hand I feel that some of the issues we agreed to set aside to n= arrow scope (LUF/LRF) are coming back to haunt us and on the other that the= effort is straining as Otmar suggests to accommodate more and more complex= ity that should, perhaps be handled elsewhere. Perhaps these are different = sides of the same coin. I for one have concerns about how useful the resulting protocol is likely t= o be, at least for my company's likely applications. Penn Pfautz AT&T Access Management +1-732-420-4962 ________________________________ This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. ________________________________ This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. --_000_754963199212404AB8E9CFCA6C3D0CDA0725ACE330TNSMAILNAwin2_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks.

 

1) &= nbsp;     The Speermint Arch doc only separates them logically.  It = dose not separate them physically.  So Speermint certainly allows that a single piece of software could be both LUF and LRF or just L= UF or just LRF.  So I think we’re ok on that front.

2) &= nbsp;     What complexity has “increased”?  iow, do you = have some specific recommendations?

 

Ken

 

From: PFAU= TZ, PENN L, ATTCORP [mailto:ppfautz@att.com]
Sent: Monday, August 03, 200= 9 3:37 PM
To: Cartwright, Kenneth; dri= nks@ietf.org
Subject: RE: Comment on toda= y's drinks discussion

 

Ken:

1) My take was that Speermint separate= s LUF/LRF. The protocol as defined can certainly support returning a LUF ou= tput, but folks seemed to want to push further than that or not make any distinction between the = two functions.

 

2) my concern is the increasing comple= xity takes the protocol beyond our needs which might lead us to look toward= s something simpler.

 

Penn Pfautz

AT&T Access Management

+1-732-420-4962

 

 

From: Cartwright, Kenneth [mailto:kcartwright@tnsi.com]
Sent: Monday, August 03, 200= 9 3:28 PM
To: PFAUTZ, PENN L, ATTCORP;= drinks@ietf.org
Subject: RE: Comment on toda= y's drinks discussion

Thanks for the feedback.

 

1) How do you feel that we are not sup= porting the LUF/LRF concepts?  Can’t a Destination Group and its= associated Route Group be used to return a URI whose domain name is the one that requires as an output of= the LUF?  Or is there something that I’m missing?

 

2) What specifically would need to be = done to the protocol to make it more useful for your company’s likely= applications?

 

Ken

 

From: drin= ks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of PFAUTZ, PENN L,= ATTCORP
Sent: Monday, July 27, 2009 = 12:46 PM
To: drinks@ietf.org
Subject: [drinks] Comment on= today's drinks discussion

 

I've been away from the design group for a while since t= he focus seemed to shift more to lower level design issues outside of my ba= iliwick but I came away from today's IETF discussion with an uncomfortable feeling about where the= drinks effort is heading.

One the one hand I feel that some of the issues we agree= d to set aside to narrow scope (LUF/LRF) are coming back to haunt us a= nd on the other that the effort is straining as Otmar suggests to accommodate more and more complexity tha= t should, perhaps be handled elsewhere. Perhaps these are different sides o= f the same coin.

I for one have concerns about how useful the result= ing protocol is likely to be, at least for my company's likely applications= .

 

 

Penn Pfautz

AT&T Access Management

+1-732-420-4962

 

 

This e-mail message is for the sole use of the intended recipie= nt(s)and may
contain confidential and privileged information of Transaction Network Serv= ices.
Any unauthorised review, use, disclosure or distribution is prohibited. If = you
are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message.


This e-mail message is for t= he sole use of the intended recipient(s)and may
contain confidential and privileged information of Transaction Network Serv= ices.
Any unauthorised review, use, disclosure or distribution is prohibited. If = you
are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message.

 --_000_754963199212404AB8E9CFCA6C3D0CDA0725ACE330TNSMAILNAwin2_-- From lendl@nic.at Mon Aug 10 08:40:41 2009 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85B713A6B13 for ; Mon, 10 Aug 2009 08:40:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.265 X-Spam-Level: X-Spam-Status: No, score=-0.265 tagged_above=-999 required=5 tests=[AWL=-0.565, BAYES_50=0.001, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_LOW=-1, SARE_RMML_Stock10=0.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R-cFoMT4fXsE for ; Mon, 10 Aug 2009 08:40:40 -0700 (PDT) Received: from mail.bofh.priv.at (fardach.bofh.priv.at [88.198.34.164]) by core3.amsl.com (Postfix) with ESMTP id 9FC343A6E8A for ; Mon, 10 Aug 2009 08:40:37 -0700 (PDT) Received: from [10.10.0.241] (nat.labs.nic.at [83.136.33.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bofh.priv.at (Postfix) with ESMTP id 7087F4C55B; Mon, 10 Aug 2009 17:40:38 +0200 (CEST) Message-ID: <4A803F75.50503@nic.at> Date: Mon, 10 Aug 2009 17:40:37 +0200 From: Otmar Lendl User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: "PFAUTZ, PENN L, ATTCORP" References: <35FE871E2B085542A35726420E29DA6B01F18918@gaalpa1msgusr7a.ugd.att.com> <8BC845943058D844ABFC73D2220D46650863B5B0@nics-mail.sbg.nic.at> <35FE871E2B085542A35726420E29DA6B01FA1C64@gaalpa1msgusr7a.ugd.att.com> In-Reply-To: <35FE871E2B085542A35726420E29DA6B01FA1C64@gaalpa1msgusr7a.ugd.att.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: drinks@ietf.org Subject: Re: [drinks] Comment on today's drinks discussion X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 15:40:41 -0000 PFAUTZ, PENN L, ATTCORP wrote: > > I've had a lingering concern about the disconnect between what Speermint > has proposed (LUF/LRF)and the route that drinks has taken. Since the > will of the design team seemed to be to get on with a simple protocol > directed toward provisioning DNS RRs I let that ride. Monday's session, > however brought up things like more abstraction of routing elements > which suggests to me assumptions about the nature of interconnections > and my issues with the original ESPP I-D. > > Brian Rosen's comment about number "ownership" relations also seemed to > suggest another complexity that the protocol would try to incorporate. > > I get concerned about a protocol that either makes a lot of specific > assumptions about the nature of the registry and the interconnection > framework and/or becomes bloated by trying to incorporate the panoply of > possible cases. > Penn, one of the problem I see is that these assumptions regarding the "interconnection framework" are never spelled out. I don't see a vision on how this might all fit together other than in very restricted situations. Anyway, on a recent train ride I tried to write up a summary on what bugs me about the Speermint/Drinks design. Here it is: -------------------------------------- Some comments on the direction Speermint and Drinks are taking First of all, why do we need these WGs at all? The quick answer is that VoIP interconnection based on plain SIP and ENUM did not work out as envisioned by the authors of the respective RFCs. There are a number of reasons for that (see draft-lendl-speermint-background), and I don’t expect that the IETF can do anything to change this. What happens in the ITU/ETSI/3GPP area? The PSTN interconnection used to be simple before the era of telecom liberalization: you had one incumbent per country and close to a full mesh of interconnection links between all countries. In the GSM world, the possibility of roaming led to a large number (scaling with O(n*n)) of contracts between operators. In both the fixed line business, as well as in the mobile telephony world, the number of operators has markedly increased over the last years. A full mesh of links just is not possible any longer. Even if the underlying network does not need dedicated links any more, just doing contracts between all possible pairs is no longer a viable option. Recent developments in the GRX and IPX demonstrate this: The introduction of "hubs" was necessary to get the quadratic scaling under control. The time of full meshes is over. Call routing was rather simple in the full mesh world (be it PSTN or RFC3263 SIP), it only needed some directory service to map Public Identities (PI = phone numbers or SIP URIs) to operators. In a lot of cases, these directories are static simple mappings like "route anything starting with +49 to Deutsche Telekom". This is no longer sufficient. Any solution to the current world-wide call routing problem needs to cope with arbitrary interconnection graphs, not just the trivial case of full meshes. A directory will not suffice any more: we need a full blown routing algorithm. I repeat: The current graph of interconnection between carriers has no special properties any more. We have a text-book routing problem to solve. This is not what Speermint is supposed to solve. As the name says: It is supposed to do “peering” and not “routing”. In other words, Speermint covers what two operators need to do to exchange calls between their direct customers. As the need to cover transit is clear, it has crept into a good number of Speermint documents. This just amounts to “we need to consider these scenarios”, but not to “here is how you solve them”. Why is Speermint restricted to peering? My guess is the following: * The driving force behind the establishment of this working group is the set of US MSOs. Their motivation is simple: enable direct call routing amongst them. They do not care about transit. * Doing a routing protocol for VoIP violates the IETF end-to-end principle and is thus not politically correct. * A full routing architecture plus routing protocol for VoIP is a huge task and to be successful needs buy-in from traditional carriers. This is more than the IETF is willing to tackle. * Peering can be stacked on existing protocols as implemented in the SIP devices: all the reachability/routing information is stored in ENUM trees which the SIP devices query. The only protocol work relates to how these ENUM trees get populated. Thus DRINKS. What’s not to like? * Transit will be back. It’s an illusion that we can build a system solely for peering setups. This will get used for transit. The foundations build by Speermint will not be able to really support transit. I predict utterly messy and unstable deployments down the road as transit will be bolted on peering. It is far better protocol design to see peering as a simple special case of transit. What DRINKS is doing is the SIP equivalent of a provisioning protocol to drive proxy-ARP servers for the interconnection of LANs. Nice and simple if everybody you every want to reach is just a hop away, but complete unsuitable for transit. * ENUM will not be enough. ENUM is a simple lookup protocol: The input is an E.164 number and the result is an ordered set of service-type/URI pairs. ENUM is not a SIP device control protocol. It is way too limited in the information the SIP device can pack into the _query_ (e.g.: source URI, source trunk information, SIP device ID, media requested, ...). You can fudge more information into the ENUM _answers_ by excessive use of URI parameters, but the query is limited by the underlying DNS protocol. * Excessive use of Registries. The LERG and LNP databases are know solutions. The default solution for data-interchange problems in the PSTN world seems to be registries. (Remember the old adage of a problems looking like nails when all you have are hammers?) In the Internet architecture, central registries are sometimes a necessary evil and are kept as small as possible. In the VoIP routing case, registries are certainly part of a solution, but only to manage a shared namespace (domain registries for URIs and ENUM registries for E.164 numbers). * LUF / LRF confusion. In a rare moment of sanity, Speermint came up with the distinction between LUF and LRF. In a nutshell: the LUF (Lookup Function) maps the public identifier to some aggregation concept like "destination group", "routing key", "destination domain",... whereas the LRF (Location Routing Function) take this Identifier as input an finds the next SIP hop towards that destination. This is a common concept in the Internet: typically a domain-name is first mapped to an IP address, and then the IP routing algorithm finds the next hop towards the host offering services for that domain. The basic concept behind this is the difference between a "name" (identifying what you want, regardless where it is) and an "address" (identifying where something is, preferably amenable to aggregation). The result of the LRF is the Session Establishment Data (SED) which is a "route" (identifying the next hop towards the destination). The LUF is best implemented by an on-demand lookup function to central database (which does not preclude local replicas for performance reasons). The LUF is querier-independent; everybody will get the same answer. The LRF is the lookup into a local routing database. No external database needs to be involved. But you need either a lot of manual work or a routing protocol between the interconnection-partners to build up the local routing tables. * Too much information in the Registry. As should be clear from the preceding remarks, I consider it to be a serious mistake that the current DRINKS design completely merges LUF and LRF into one single protocol. This overloads the registry with data that should not be there. * No consideration for multiple Registries. If registries are pure LUFs, then there are natural ways to distribute the namespace over multiple registries: Both in the E.164/ENUM case and the URI/domains case, the hierarchical DNS can delegate parts of the global namespace to local registries. The actual call routing is not affected as the LUF registries do not contain routing data. There is no need for a registry-registry protocol to synchronize "routes" or "routing groups". If the registries are mixed LUF/LRF ones, then multiple registries lead to interesting routing problems: Unless every carrier is a customer of every registry, then achieving worldwide VoIP routing gets tricky. Either: o Transit carriers re-announce PIs they learned from one registry into all other registry they are connected to. That means that the same PI will appear in each registry multiple times and the registry needs to decide which path announce with what preference to carriers in need of transit. Additionally, I don't see how you can prevent routing loops in this scenario. o We invent a registry-registry protocol that avoids these re-announcements. That just opens another can of worms: will there be a full mesh between the registries? What kind of routing policies will the registries implement on behalf of their customers? * Routing is a core competence of a carrier. I just cannot image the any serious transit carrier will want to outsource its transit routing algorithm to a foreign party. This is not an issue as long as the registry will contain only pure peering data. __Summary__ Both working-groups are building a complex solution for a very restricted special case of the generic VoIP routing problem. This will work only in tightly restricted setups. But it will block a clean solution for the underlying problem and will encourage ugly hacks in the long term. This is like designing the IBM PC with its 640kB limit while you already know that this will lead to EMS, XMS, himem.sys and all these kludges once you want to do more with the design than just run visicalc. /ol -- // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // From john.elwell@siemens-enterprise.com Tue Aug 11 00:35:18 2009 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B37E23A682D for ; Tue, 11 Aug 2009 00:35:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.512 X-Spam-Level: X-Spam-Status: No, score=-1.512 tagged_above=-999 required=5 tests=[AWL=-0.902, BAYES_20=-0.74, SARE_RMML_Stock10=0.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1rfbZSJU5xhP for ; Tue, 11 Aug 2009 00:35:17 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 1D3393A6A5B for ; Tue, 11 Aug 2009 00:35:17 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([172.23.15.171]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KO70023CBQVMP@siemenscomms.co.uk> for drinks@ietf.org; Tue, 11 Aug 2009 08:35:19 +0100 (BST) Date: Tue, 11 Aug 2009 08:35:17 +0100 From: "Elwell, John" In-reply-to: <4A803F75.50503@nic.at> To: Otmar Lendl , "PFAUTZ, PENN L, ATTCORP" Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0023D229D@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [drinks] Comment on today's drinks discussion Thread-Index: AcoZ0P5vhsx0GiUfTc2IVSbmebVs3QAhOPjw Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <35FE871E2B085542A35726420E29DA6B01F18918@gaalpa1msgusr7a.ugd.att.com> <8BC845943058D844ABFC73D2220D46650863B5B0@nics-mail.sbg.nic.at> <35FE871E2B085542A35726420E29DA6B01FA1C64@gaalpa1msgusr7a.ugd.att.com> <4A803F75.50503@nic.at> Cc: drinks@ietf.org Subject: Re: [drinks] Comment on today's drinks discussion X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 07:35:18 -0000 Otmar, Why do you say both WGs are to blame? SPEERMINT does indeed have the LUF/LRF split, so what do you feel is the problem in SPEERMINT? Also, perhaps you should post this to the SPEERMINT list too and say that discussions are taking place on the DRINKS list (to avoid ongoing cross-posting). John=20 > -----Original Message----- > From: drinks-bounces@ietf.org=20 > [mailto:drinks-bounces@ietf.org] On Behalf Of Otmar Lendl > Sent: 10 August 2009 16:41 > To: PFAUTZ, PENN L, ATTCORP > Cc: drinks@ietf.org > Subject: Re: [drinks] Comment on today's drinks discussion >=20 > PFAUTZ, PENN L, ATTCORP wrote: > >=20 > > I've had a lingering concern about the disconnect between=20 > what Speermint > > has proposed (LUF/LRF)and the route that drinks has taken. Since the > > will of the design team seemed to be to get on with a=20 > simple protocol > > directed toward provisioning DNS RRs I let that ride.=20 > Monday's session, > > however brought up things like more abstraction of routing elements > > which suggests to me assumptions about the nature of=20 > interconnections > > and my issues with the original ESPP I-D. > >=20 > > Brian Rosen's comment about number "ownership" relations=20 > also seemed to > > suggest another complexity that the protocol would try to=20 > incorporate.=20 > >=20 > > I get concerned about a protocol that either makes a lot of specific > > assumptions about the nature of the registry and the interconnection > > framework and/or becomes bloated by trying to incorporate=20 > the panoply of > > possible cases. > >=20 >=20 > Penn, >=20 > one of the problem I see is that these assumptions regarding the > "interconnection framework" are never spelled out. I don't=20 > see a vision on > how this might all fit together other than in very restricted=20 > situations. >=20 > Anyway, on a recent train ride I tried to write up a summary=20 > on what bugs > me about the Speermint/Drinks design. Here it is: >=20 > -------------------------------------- >=20 > Some comments on the direction Speermint and Drinks are taking >=20 > First of all, why do we need these WGs at all? The quick=20 > answer is that > VoIP interconnection based on plain SIP and ENUM did not work out as > envisioned by the authors of the respective RFCs. There are a=20 > number of > reasons for that (see draft-lendl-speermint-background), and=20 > I don't expect > that the IETF can do anything to change this. >=20 > What happens in the ITU/ETSI/3GPP area? The PSTN=20 > interconnection used to be > simple before the era of telecom liberalization: you had one=20 > incumbent per > country and close to a full mesh of interconnection links between all > countries. In the GSM world, the possibility of roaming led to a large > number (scaling with O(n*n)) of contracts between operators.=20 > In both the > fixed line business, as well as in the mobile telephony=20 > world, the number > of operators has markedly increased over the last years. A=20 > full mesh of > links just is not possible any longer. Even if the underlying=20 > network does > not need dedicated links any more, just doing contracts between all > possible pairs is no longer a viable option. Recent=20 > developments in the GRX > and IPX demonstrate this: The introduction of "hubs" was=20 > necessary to get > the quadratic scaling under control. The time of full meshes is over. >=20 > Call routing was rather simple in the full mesh world (be it PSTN or > RFC3263 SIP), it only needed some directory service to map Public > Identities (PI =3D phone numbers or SIP URIs) to operators. In a lot = of > cases, these directories are static simple mappings like=20 > "route anything > starting with +49 to Deutsche Telekom". >=20 > This is no longer sufficient. Any solution to the current=20 > world-wide call > routing problem needs to cope with arbitrary interconnection=20 > graphs, not > just the trivial case of full meshes. A directory will not suffice any > more: we need a full blown routing algorithm. >=20 > I repeat: The current graph of interconnection between carriers has no > special properties any more. We have a text-book routing=20 > problem to solve. >=20 > This is not what Speermint is supposed to solve. As the name=20 > says: It is > supposed to do "peering" and not "routing". In other words, Speermint > covers what two operators need to do to exchange calls=20 > between their direct > customers. >=20 > As the need to cover transit is clear, it has crept into a=20 > good number of > Speermint documents. This just amounts to "we need to consider these > scenarios", but not to "here is how you solve them". >=20 > Why is Speermint restricted to peering? My guess is the following: >=20 > * The driving force behind the establishment of this=20 > working group is > the set of US MSOs. Their motivation is simple: enable direct=20 > call routing > amongst them. They do not care about transit. >=20 > * Doing a routing protocol for VoIP violates the IETF end-to-end > principle and is thus not politically correct. >=20 > * A full routing architecture plus routing protocol for=20 > VoIP is a huge > task and to be successful needs buy-in from traditional=20 > carriers. This is > more than the IETF is willing to tackle. >=20 > * Peering can be stacked on existing protocols as=20 > implemented in the > SIP devices: all the reachability/routing information is=20 > stored in ENUM > trees which the SIP devices query. The only protocol work=20 > relates to how > these ENUM trees get populated. Thus DRINKS. >=20 > What's not to like? >=20 > * Transit will be back. >=20 > It's an illusion that we can build a system solely for peering > setups. This will get used for transit. The foundations build=20 > by Speermint > will not be able to really support transit. I predict utterly=20 > messy and > unstable deployments down the road as transit will be bolted=20 > on peering. >=20 > It is far better protocol design to see peering as a=20 > simple special > case of transit. >=20 > What DRINKS is doing is the SIP equivalent of a=20 > provisioning protocol > to drive proxy-ARP servers for the interconnection of LANs.=20 > Nice and simple > if everybody you every want to reach is just a hop away, but complete > unsuitable for transit. >=20 > * ENUM will not be enough. >=20 > ENUM is a simple lookup protocol: The input is an E.164=20 > number and > the result is an ordered set of service-type/URI pairs. ENUM=20 > is not a SIP > device control protocol. It is way too limited in the=20 > information the SIP > device can pack into the _query_ (e.g.: source URI, source trunk > information, SIP device ID, media requested, ...). You can fudge more > information into the ENUM _answers_ by excessive use of URI=20 > parameters, but > the query is limited by the underlying DNS protocol. >=20 > * Excessive use of Registries. >=20 > The LERG and LNP databases are know solutions. The=20 > default solution > for data-interchange problems in the PSTN world seems to be=20 > registries. > (Remember the old adage of a problems looking like nails when=20 > all you have > are hammers?) >=20 > In the Internet architecture, central registries are sometimes a > necessary evil and are kept as small as possible. In the VoIP=20 > routing case, > registries are certainly part of a solution, but only to=20 > manage a shared > namespace (domain registries for URIs and ENUM registries for=20 > E.164 numbers). >=20 > * LUF / LRF confusion. >=20 > In a rare moment of sanity, Speermint came up with the=20 > distinction > between LUF and LRF. In a nutshell: the LUF (Lookup Function) maps the > public identifier to some aggregation concept like=20 > "destination group", > "routing key", "destination domain",... whereas the LRF=20 > (Location Routing > Function) take this Identifier as input an finds the next SIP=20 > hop towards > that destination. >=20 > This is a common concept in the Internet: typically a=20 > domain-name is > first mapped to an IP address, and then the IP routing=20 > algorithm finds the > next hop towards the host offering services for that domain. >=20 > The basic concept behind this is the difference between a "name" > (identifying what you want, regardless where it is) and an "address" > (identifying where something is, preferably amenable to=20 > aggregation). The > result of the LRF is the Session Establishment Data (SED) which is a > "route" (identifying the next hop towards the destination). >=20 > The LUF is best implemented by an on-demand lookup function to > central database (which does not preclude local replicas for=20 > performance > reasons). The LUF is querier-independent; everybody will get=20 > the same answer. >=20 > The LRF is the lookup into a local routing database. No external > database needs to be involved. But you need either a lot of=20 > manual work or > a routing protocol between the interconnection-partners to=20 > build up the > local routing tables. >=20 > * Too much information in the Registry. >=20 > As should be clear from the preceding remarks, I=20 > consider it to be a > serious mistake that the current DRINKS design completely=20 > merges LUF and > LRF into one single protocol. >=20 > This overloads the registry with data that should not be there. >=20 > * No consideration for multiple Registries. >=20 > If registries are pure LUFs, then there are natural ways to > distribute the namespace over multiple registries: Both in=20 > the E.164/ENUM > case and the URI/domains case, the hierarchical DNS can=20 > delegate parts of > the global namespace to local registries. The actual call=20 > routing is not > affected as the LUF registries do not contain routing data.=20 > There is no > need for a registry-registry protocol to synchronize "routes"=20 > or "routing > groups". >=20 > If the registries are mixed LUF/LRF ones, then multiple=20 > registries > lead to interesting routing problems: Unless every carrier is=20 > a customer of > every registry, then achieving worldwide VoIP routing gets=20 > tricky. Either: >=20 > o Transit carriers re-announce PIs they learned=20 > from one registry > into all other registry they are connected to. That means=20 > that the same PI > will appear in each registry multiple times and the registry needs to > decide which path announce with what preference to carriers in need of > transit. Additionally, I don't see how you can prevent=20 > routing loops in > this scenario. >=20 > o We invent a registry-registry protocol that avoids these > re-announcements. That just opens another can of worms: will=20 > there be a > full mesh between the registries? What kind of routing=20 > policies will the > registries implement on behalf of their customers? >=20 > * Routing is a core competence of a carrier. >=20 > I just cannot image the any serious transit carrier will want to > outsource its transit routing algorithm to a foreign party. >=20 > This is not an issue as long as the registry will=20 > contain only pure > peering data. >=20 > __Summary__ >=20 > Both working-groups are building a complex solution for a=20 > very restricted > special case of the generic VoIP routing problem. This will=20 > work only in > tightly restricted setups. >=20 > But it will block a clean solution for the underlying problem and will > encourage ugly hacks in the long term. >=20 > This is like designing the IBM PC with its 640kB limit while=20 > you already > know that this will lead to EMS, XMS, himem.sys and all these=20 > kludges once > you want to do more with the design than just run visicalc. >=20 > /ol > --=20 > // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // > _______________________________________________ > drinks mailing list > drinks@ietf.org > https://www.ietf.org/mailman/listinfo/drinks >=20 From kcartwright@tnsi.com Tue Aug 11 06:13:28 2009 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FF003A6FB1 for ; Tue, 11 Aug 2009 06:13:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.604 X-Spam-Level: X-Spam-Status: No, score=-1.604 tagged_above=-999 required=5 tests=[AWL=-0.994, BAYES_20=-0.74, SARE_RMML_Stock10=0.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5C-VNo2FXhPx for ; Tue, 11 Aug 2009 06:13:26 -0700 (PDT) Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by core3.amsl.com (Postfix) with ESMTP id 6BE973A6B93 for ; Tue, 11 Aug 2009 06:13:25 -0700 (PDT) Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.31722426; Tue, 11 Aug 2009 09:15:44 -0400 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.219]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Tue, 11 Aug 2009 09:12:12 -0400 From: "Cartwright, Kenneth" To: "Elwell, John" , Otmar Lendl , "PFAUTZ, PENN L, ATTCORP" Date: Tue, 11 Aug 2009 09:12:09 -0400 Thread-Topic: [drinks] Comment on today's drinks discussion Thread-Index: AcoZ0P5vhsx0GiUfTc2IVSbmebVs3QAhOPjwAAvTjvA= Message-ID: <754963199212404AB8E9CFCA6C3D0CDA0725C94EDB@TNS-MAIL-NA.win2k.corp.tnsi.com> References: <35FE871E2B085542A35726420E29DA6B01F18918@gaalpa1msgusr7a.ugd.att.com> <8BC845943058D844ABFC73D2220D46650863B5B0@nics-mail.sbg.nic.at> <35FE871E2B085542A35726420E29DA6B01FA1C64@gaalpa1msgusr7a.ugd.att.com> <4A803F75.50503@nic.at> <0D5F89FAC29E2C41B98A6A762007F5D0023D229D@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0023D229D@GBNTHT12009MSX.gb002.siemens.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "drinks@ietf.org" Subject: Re: [drinks] Comment on today's drinks discussion X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 13:13:28 -0000 That's an odd statement. I take Otmar's input as constructive, not an atte= mpt to assign "blame". Ken -----Original Message----- From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of= Elwell, John Sent: Tuesday, August 11, 2009 3:35 AM To: Otmar Lendl; PFAUTZ, PENN L, ATTCORP Cc: drinks@ietf.org Subject: Re: [drinks] Comment on today's drinks discussion Otmar, Why do you say both WGs are to blame? SPEERMINT does indeed have the LUF/LRF split, so what do you feel is the problem in SPEERMINT? Also, perhaps you should post this to the SPEERMINT list too and say that discussions are taking place on the DRINKS list (to avoid ongoing cross-posting). John > -----Original Message----- > From: drinks-bounces@ietf.org > [mailto:drinks-bounces@ietf.org] On Behalf Of Otmar Lendl > Sent: 10 August 2009 16:41 > To: PFAUTZ, PENN L, ATTCORP > Cc: drinks@ietf.org > Subject: Re: [drinks] Comment on today's drinks discussion > > PFAUTZ, PENN L, ATTCORP wrote: > > > > I've had a lingering concern about the disconnect between > what Speermint > > has proposed (LUF/LRF)and the route that drinks has taken. Since the > > will of the design team seemed to be to get on with a > simple protocol > > directed toward provisioning DNS RRs I let that ride. > Monday's session, > > however brought up things like more abstraction of routing elements > > which suggests to me assumptions about the nature of > interconnections > > and my issues with the original ESPP I-D. > > > > Brian Rosen's comment about number "ownership" relations > also seemed to > > suggest another complexity that the protocol would try to > incorporate. > > > > I get concerned about a protocol that either makes a lot of specific > > assumptions about the nature of the registry and the interconnection > > framework and/or becomes bloated by trying to incorporate > the panoply of > > possible cases. > > > > Penn, > > one of the problem I see is that these assumptions regarding the > "interconnection framework" are never spelled out. I don't > see a vision on > how this might all fit together other than in very restricted > situations. > > Anyway, on a recent train ride I tried to write up a summary > on what bugs > me about the Speermint/Drinks design. Here it is: > > -------------------------------------- > > Some comments on the direction Speermint and Drinks are taking > > First of all, why do we need these WGs at all? The quick > answer is that > VoIP interconnection based on plain SIP and ENUM did not work out as > envisioned by the authors of the respective RFCs. There are a > number of > reasons for that (see draft-lendl-speermint-background), and > I don't expect > that the IETF can do anything to change this. > > What happens in the ITU/ETSI/3GPP area? The PSTN > interconnection used to be > simple before the era of telecom liberalization: you had one > incumbent per > country and close to a full mesh of interconnection links between all > countries. In the GSM world, the possibility of roaming led to a large > number (scaling with O(n*n)) of contracts between operators. > In both the > fixed line business, as well as in the mobile telephony > world, the number > of operators has markedly increased over the last years. A > full mesh of > links just is not possible any longer. Even if the underlying > network does > not need dedicated links any more, just doing contracts between all > possible pairs is no longer a viable option. Recent > developments in the GRX > and IPX demonstrate this: The introduction of "hubs" was > necessary to get > the quadratic scaling under control. The time of full meshes is over. > > Call routing was rather simple in the full mesh world (be it PSTN or > RFC3263 SIP), it only needed some directory service to map Public > Identities (PI =3D phone numbers or SIP URIs) to operators. In a lot of > cases, these directories are static simple mappings like > "route anything > starting with +49 to Deutsche Telekom". > > This is no longer sufficient. Any solution to the current > world-wide call > routing problem needs to cope with arbitrary interconnection > graphs, not > just the trivial case of full meshes. A directory will not suffice any > more: we need a full blown routing algorithm. > > I repeat: The current graph of interconnection between carriers has no > special properties any more. We have a text-book routing > problem to solve. > > This is not what Speermint is supposed to solve. As the name > says: It is > supposed to do "peering" and not "routing". In other words, Speermint > covers what two operators need to do to exchange calls > between their direct > customers. > > As the need to cover transit is clear, it has crept into a > good number of > Speermint documents. This just amounts to "we need to consider these > scenarios", but not to "here is how you solve them". > > Why is Speermint restricted to peering? My guess is the following: > > * The driving force behind the establishment of this > working group is > the set of US MSOs. Their motivation is simple: enable direct > call routing > amongst them. They do not care about transit. > > * Doing a routing protocol for VoIP violates the IETF end-to-end > principle and is thus not politically correct. > > * A full routing architecture plus routing protocol for > VoIP is a huge > task and to be successful needs buy-in from traditional > carriers. This is > more than the IETF is willing to tackle. > > * Peering can be stacked on existing protocols as > implemented in the > SIP devices: all the reachability/routing information is > stored in ENUM > trees which the SIP devices query. The only protocol work > relates to how > these ENUM trees get populated. Thus DRINKS. > > What's not to like? > > * Transit will be back. > > It's an illusion that we can build a system solely for peering > setups. This will get used for transit. The foundations build > by Speermint > will not be able to really support transit. I predict utterly > messy and > unstable deployments down the road as transit will be bolted > on peering. > > It is far better protocol design to see peering as a > simple special > case of transit. > > What DRINKS is doing is the SIP equivalent of a > provisioning protocol > to drive proxy-ARP servers for the interconnection of LANs. > Nice and simple > if everybody you every want to reach is just a hop away, but complete > unsuitable for transit. > > * ENUM will not be enough. > > ENUM is a simple lookup protocol: The input is an E.164 > number and > the result is an ordered set of service-type/URI pairs. ENUM > is not a SIP > device control protocol. It is way too limited in the > information the SIP > device can pack into the _query_ (e.g.: source URI, source trunk > information, SIP device ID, media requested, ...). You can fudge more > information into the ENUM _answers_ by excessive use of URI > parameters, but > the query is limited by the underlying DNS protocol. > > * Excessive use of Registries. > > The LERG and LNP databases are know solutions. The > default solution > for data-interchange problems in the PSTN world seems to be > registries. > (Remember the old adage of a problems looking like nails when > all you have > are hammers?) > > In the Internet architecture, central registries are sometimes a > necessary evil and are kept as small as possible. In the VoIP > routing case, > registries are certainly part of a solution, but only to > manage a shared > namespace (domain registries for URIs and ENUM registries for > E.164 numbers). > > * LUF / LRF confusion. > > In a rare moment of sanity, Speermint came up with the > distinction > between LUF and LRF. In a nutshell: the LUF (Lookup Function) maps the > public identifier to some aggregation concept like > "destination group", > "routing key", "destination domain",... whereas the LRF > (Location Routing > Function) take this Identifier as input an finds the next SIP > hop towards > that destination. > > This is a common concept in the Internet: typically a > domain-name is > first mapped to an IP address, and then the IP routing > algorithm finds the > next hop towards the host offering services for that domain. > > The basic concept behind this is the difference between a "name" > (identifying what you want, regardless where it is) and an "address" > (identifying where something is, preferably amenable to > aggregation). The > result of the LRF is the Session Establishment Data (SED) which is a > "route" (identifying the next hop towards the destination). > > The LUF is best implemented by an on-demand lookup function to > central database (which does not preclude local replicas for > performance > reasons). The LUF is querier-independent; everybody will get > the same answer. > > The LRF is the lookup into a local routing database. No external > database needs to be involved. But you need either a lot of > manual work or > a routing protocol between the interconnection-partners to > build up the > local routing tables. > > * Too much information in the Registry. > > As should be clear from the preceding remarks, I > consider it to be a > serious mistake that the current DRINKS design completely > merges LUF and > LRF into one single protocol. > > This overloads the registry with data that should not be there. > > * No consideration for multiple Registries. > > If registries are pure LUFs, then there are natural ways to > distribute the namespace over multiple registries: Both in > the E.164/ENUM > case and the URI/domains case, the hierarchical DNS can > delegate parts of > the global namespace to local registries. The actual call > routing is not > affected as the LUF registries do not contain routing data. > There is no > need for a registry-registry protocol to synchronize "routes" > or "routing > groups". > > If the registries are mixed LUF/LRF ones, then multiple > registries > lead to interesting routing problems: Unless every carrier is > a customer of > every registry, then achieving worldwide VoIP routing gets > tricky. Either: > > o Transit carriers re-announce PIs they learned > from one registry > into all other registry they are connected to. That means > that the same PI > will appear in each registry multiple times and the registry needs to > decide which path announce with what preference to carriers in need of > transit. Additionally, I don't see how you can prevent > routing loops in > this scenario. > > o We invent a registry-registry protocol that avoids these > re-announcements. That just opens another can of worms: will > there be a > full mesh between the registries? What kind of routing > policies will the > registries implement on behalf of their customers? > > * Routing is a core competence of a carrier. > > I just cannot image the any serious transit carrier will want to > outsource its transit routing algorithm to a foreign party. > > This is not an issue as long as the registry will > contain only pure > peering data. > > __Summary__ > > Both working-groups are building a complex solution for a > very restricted > special case of the generic VoIP routing problem. This will > work only in > tightly restricted setups. > > But it will block a clean solution for the underlying problem and will > encourage ugly hacks in the long term. > > This is like designing the IBM PC with its 640kB limit while > you already > know that this will lead to EMS, XMS, himem.sys and all these > kludges once > you want to do more with the design than just run visicalc. > > /ol > -- > // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // > _______________________________________________ > drinks mailing list > drinks@ietf.org > https://www.ietf.org/mailman/listinfo/drinks > _______________________________________________ drinks mailing list drinks@ietf.org https://www.ietf.org/mailman/listinfo/drinks This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. From john.elwell@siemens-enterprise.com Tue Aug 11 09:00:45 2009 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 551153A70A2 for ; Tue, 11 Aug 2009 09:00:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.632 X-Spam-Level: X-Spam-Status: No, score=-1.632 tagged_above=-999 required=5 tests=[AWL=-0.652, BAYES_05=-1.11, SARE_RMML_Stock10=0.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v12csyr-2W-F for ; Tue, 11 Aug 2009 09:00:43 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 623B23A7018 for ; Tue, 11 Aug 2009 09:00:43 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([172.23.15.171]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KO70024HTQDUA@siemenscomms.co.uk> for drinks@ietf.org; Tue, 11 Aug 2009 15:03:49 +0100 (BST) Date: Tue, 11 Aug 2009 15:03:46 +0100 From: "Elwell, John" In-reply-to: <754963199212404AB8E9CFCA6C3D0CDA0725C94EDB@TNS-MAIL-NA.win2k.corp.tnsi.com> To: "Cartwright, Kenneth" , Otmar Lendl , "PFAUTZ, PENN L, ATTCORP" Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0023D250F@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [drinks] Comment on today's drinks discussion Thread-Index: AcoZ0P5vhsx0GiUfTc2IVSbmebVs3QAhOPjwAAvTjvAAAbo1oA== Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <35FE871E2B085542A35726420E29DA6B01F18918@gaalpa1msgusr7a.ugd.att.com> <8BC845943058D844ABFC73D2220D46650863B5B0@nics-mail.sbg.nic.at> <35FE871E2B085542A35726420E29DA6B01FA1C64@gaalpa1msgusr7a.ugd.att.com> <4A803F75.50503@nic.at> <0D5F89FAC29E2C41B98A6A762007F5D0023D229D@GBNTHT12009MSX.gb002.siemens.net> <754963199212404AB8E9CFCA6C3D0CDA0725C94EDB@TNS-MAIL-NA.win2k.corp.tnsi.com> Cc: drinks@ietf.org Subject: Re: [drinks] Comment on today's drinks discussion X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 16:00:45 -0000 Yes, I too took it as constructive, but it seemed to suggest both DRINKS and SPEERMINT had taken a turn in the wrong direction. Whilst it is clear from his message why he thinks DRINKS has done so, it is not so clear to me why he thinks SPEERMINT has done so. Sorry about the choice of word. John=20 > -----Original Message----- > From: Cartwright, Kenneth [mailto:kcartwright@tnsi.com]=20 > Sent: 11 August 2009 14:12 > To: Elwell, John; Otmar Lendl; PFAUTZ, PENN L, ATTCORP > Cc: drinks@ietf.org > Subject: RE: [drinks] Comment on today's drinks discussion >=20 > That's an odd statement. I take Otmar's input as=20 > constructive, not an attempt to assign "blame". >=20 > Ken >=20 > -----Original Message----- > From: drinks-bounces@ietf.org=20 > [mailto:drinks-bounces@ietf.org] On Behalf Of Elwell, John > Sent: Tuesday, August 11, 2009 3:35 AM > To: Otmar Lendl; PFAUTZ, PENN L, ATTCORP > Cc: drinks@ietf.org > Subject: Re: [drinks] Comment on today's drinks discussion >=20 > Otmar, >=20 > Why do you say both WGs are to blame? SPEERMINT does indeed have the > LUF/LRF split, so what do you feel is the problem in SPEERMINT? >=20 > Also, perhaps you should post this to the SPEERMINT list too and say > that discussions are taking place on the DRINKS list (to avoid ongoing > cross-posting). >=20 > John >=20 > > -----Original Message----- > > From: drinks-bounces@ietf.org > > [mailto:drinks-bounces@ietf.org] On Behalf Of Otmar Lendl > > Sent: 10 August 2009 16:41 > > To: PFAUTZ, PENN L, ATTCORP > > Cc: drinks@ietf.org > > Subject: Re: [drinks] Comment on today's drinks discussion > > > > PFAUTZ, PENN L, ATTCORP wrote: > > > > > > I've had a lingering concern about the disconnect between > > what Speermint > > > has proposed (LUF/LRF)and the route that drinks has=20 > taken. Since the > > > will of the design team seemed to be to get on with a > > simple protocol > > > directed toward provisioning DNS RRs I let that ride. > > Monday's session, > > > however brought up things like more abstraction of=20 > routing elements > > > which suggests to me assumptions about the nature of > > interconnections > > > and my issues with the original ESPP I-D. > > > > > > Brian Rosen's comment about number "ownership" relations > > also seemed to > > > suggest another complexity that the protocol would try to > > incorporate. > > > > > > I get concerned about a protocol that either makes a lot=20 > of specific > > > assumptions about the nature of the registry and the=20 > interconnection > > > framework and/or becomes bloated by trying to incorporate > > the panoply of > > > possible cases. > > > > > > > Penn, > > > > one of the problem I see is that these assumptions regarding the > > "interconnection framework" are never spelled out. I don't > > see a vision on > > how this might all fit together other than in very restricted > > situations. > > > > Anyway, on a recent train ride I tried to write up a summary > > on what bugs > > me about the Speermint/Drinks design. Here it is: > > > > -------------------------------------- > > > > Some comments on the direction Speermint and Drinks are taking > > > > First of all, why do we need these WGs at all? The quick > > answer is that > > VoIP interconnection based on plain SIP and ENUM did not work out as > > envisioned by the authors of the respective RFCs. There are a > > number of > > reasons for that (see draft-lendl-speermint-background), and > > I don't expect > > that the IETF can do anything to change this. > > > > What happens in the ITU/ETSI/3GPP area? The PSTN > > interconnection used to be > > simple before the era of telecom liberalization: you had one > > incumbent per > > country and close to a full mesh of interconnection links=20 > between all > > countries. In the GSM world, the possibility of roaming led=20 > to a large > > number (scaling with O(n*n)) of contracts between operators. > > In both the > > fixed line business, as well as in the mobile telephony > > world, the number > > of operators has markedly increased over the last years. A > > full mesh of > > links just is not possible any longer. Even if the underlying > > network does > > not need dedicated links any more, just doing contracts between all > > possible pairs is no longer a viable option. Recent > > developments in the GRX > > and IPX demonstrate this: The introduction of "hubs" was > > necessary to get > > the quadratic scaling under control. The time of full=20 > meshes is over. > > > > Call routing was rather simple in the full mesh world (be it PSTN or > > RFC3263 SIP), it only needed some directory service to map Public > > Identities (PI =3D phone numbers or SIP URIs) to operators.=20 > In a lot of > > cases, these directories are static simple mappings like > > "route anything > > starting with +49 to Deutsche Telekom". > > > > This is no longer sufficient. Any solution to the current > > world-wide call > > routing problem needs to cope with arbitrary interconnection > > graphs, not > > just the trivial case of full meshes. A directory will not=20 > suffice any > > more: we need a full blown routing algorithm. > > > > I repeat: The current graph of interconnection between=20 > carriers has no > > special properties any more. We have a text-book routing > > problem to solve. > > > > This is not what Speermint is supposed to solve. As the name > > says: It is > > supposed to do "peering" and not "routing". In other words,=20 > Speermint > > covers what two operators need to do to exchange calls > > between their direct > > customers. > > > > As the need to cover transit is clear, it has crept into a > > good number of > > Speermint documents. This just amounts to "we need to consider these > > scenarios", but not to "here is how you solve them". > > > > Why is Speermint restricted to peering? My guess is the following: > > > > * The driving force behind the establishment of this > > working group is > > the set of US MSOs. Their motivation is simple: enable direct > > call routing > > amongst them. They do not care about transit. > > > > * Doing a routing protocol for VoIP violates the IETF end-to-end > > principle and is thus not politically correct. > > > > * A full routing architecture plus routing protocol for > > VoIP is a huge > > task and to be successful needs buy-in from traditional > > carriers. This is > > more than the IETF is willing to tackle. > > > > * Peering can be stacked on existing protocols as > > implemented in the > > SIP devices: all the reachability/routing information is > > stored in ENUM > > trees which the SIP devices query. The only protocol work > > relates to how > > these ENUM trees get populated. Thus DRINKS. > > > > What's not to like? > > > > * Transit will be back. > > > > It's an illusion that we can build a system solely for peering > > setups. This will get used for transit. The foundations build > > by Speermint > > will not be able to really support transit. I predict utterly > > messy and > > unstable deployments down the road as transit will be bolted > > on peering. > > > > It is far better protocol design to see peering as a > > simple special > > case of transit. > > > > What DRINKS is doing is the SIP equivalent of a > > provisioning protocol > > to drive proxy-ARP servers for the interconnection of LANs. > > Nice and simple > > if everybody you every want to reach is just a hop away,=20 > but complete > > unsuitable for transit. > > > > * ENUM will not be enough. > > > > ENUM is a simple lookup protocol: The input is an E.164 > > number and > > the result is an ordered set of service-type/URI pairs. ENUM > > is not a SIP > > device control protocol. It is way too limited in the > > information the SIP > > device can pack into the _query_ (e.g.: source URI, source trunk > > information, SIP device ID, media requested, ...). You can=20 > fudge more > > information into the ENUM _answers_ by excessive use of URI > > parameters, but > > the query is limited by the underlying DNS protocol. > > > > * Excessive use of Registries. > > > > The LERG and LNP databases are know solutions. The > > default solution > > for data-interchange problems in the PSTN world seems to be > > registries. > > (Remember the old adage of a problems looking like nails when > > all you have > > are hammers?) > > > > In the Internet architecture, central registries are=20 > sometimes a > > necessary evil and are kept as small as possible. In the VoIP > > routing case, > > registries are certainly part of a solution, but only to > > manage a shared > > namespace (domain registries for URIs and ENUM registries for > > E.164 numbers). > > > > * LUF / LRF confusion. > > > > In a rare moment of sanity, Speermint came up with the > > distinction > > between LUF and LRF. In a nutshell: the LUF (Lookup=20 > Function) maps the > > public identifier to some aggregation concept like > > "destination group", > > "routing key", "destination domain",... whereas the LRF > > (Location Routing > > Function) take this Identifier as input an finds the next SIP > > hop towards > > that destination. > > > > This is a common concept in the Internet: typically a > > domain-name is > > first mapped to an IP address, and then the IP routing > > algorithm finds the > > next hop towards the host offering services for that domain. > > > > The basic concept behind this is the difference=20 > between a "name" > > (identifying what you want, regardless where it is) and an "address" > > (identifying where something is, preferably amenable to > > aggregation). The > > result of the LRF is the Session Establishment Data (SED) which is a > > "route" (identifying the next hop towards the destination). > > > > The LUF is best implemented by an on-demand lookup function to > > central database (which does not preclude local replicas for > > performance > > reasons). The LUF is querier-independent; everybody will get > > the same answer. > > > > The LRF is the lookup into a local routing database.=20 > No external > > database needs to be involved. But you need either a lot of > > manual work or > > a routing protocol between the interconnection-partners to > > build up the > > local routing tables. > > > > * Too much information in the Registry. > > > > As should be clear from the preceding remarks, I > > consider it to be a > > serious mistake that the current DRINKS design completely > > merges LUF and > > LRF into one single protocol. > > > > This overloads the registry with data that should not=20 > be there. > > > > * No consideration for multiple Registries. > > > > If registries are pure LUFs, then there are natural ways to > > distribute the namespace over multiple registries: Both in > > the E.164/ENUM > > case and the URI/domains case, the hierarchical DNS can > > delegate parts of > > the global namespace to local registries. The actual call > > routing is not > > affected as the LUF registries do not contain routing data. > > There is no > > need for a registry-registry protocol to synchronize "routes" > > or "routing > > groups". > > > > If the registries are mixed LUF/LRF ones, then multiple > > registries > > lead to interesting routing problems: Unless every carrier is > > a customer of > > every registry, then achieving worldwide VoIP routing gets > > tricky. Either: > > > > o Transit carriers re-announce PIs they learned > > from one registry > > into all other registry they are connected to. That means > > that the same PI > > will appear in each registry multiple times and the=20 > registry needs to > > decide which path announce with what preference to carriers=20 > in need of > > transit. Additionally, I don't see how you can prevent > > routing loops in > > this scenario. > > > > o We invent a registry-registry protocol that avoids these > > re-announcements. That just opens another can of worms: will > > there be a > > full mesh between the registries? What kind of routing > > policies will the > > registries implement on behalf of their customers? > > > > * Routing is a core competence of a carrier. > > > > I just cannot image the any serious transit carrier=20 > will want to > > outsource its transit routing algorithm to a foreign party. > > > > This is not an issue as long as the registry will > > contain only pure > > peering data. > > > > __Summary__ > > > > Both working-groups are building a complex solution for a > > very restricted > > special case of the generic VoIP routing problem. This will > > work only in > > tightly restricted setups. > > > > But it will block a clean solution for the underlying=20 > problem and will > > encourage ugly hacks in the long term. > > > > This is like designing the IBM PC with its 640kB limit while > > you already > > know that this will lead to EMS, XMS, himem.sys and all these > > kludges once > > you want to do more with the design than just run visicalc. > > > > /ol > > -- > > // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // > > _______________________________________________ > > drinks mailing list > > drinks@ietf.org > > https://www.ietf.org/mailman/listinfo/drinks > > > _______________________________________________ > drinks mailing list > drinks@ietf.org > https://www.ietf.org/mailman/listinfo/drinks >=20 > This e-mail message is for the sole use of the intended=20 > recipient(s)and may > contain confidential and privileged information of=20 > Transaction Network Services. > Any unauthorised review, use, disclosure or distribution is=20 > prohibited. If you > are not the intended recipient, please contact the sender by=20 > reply e-mail and destroy all copies of the original message. >=20 >=20 From john.elwell@siemens-enterprise.com Tue Aug 11 12:36:26 2009 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CEC33A67A8 for ; Tue, 11 Aug 2009 12:36:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.419 X-Spam-Level: X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wa2oQJYB3Il4 for ; Tue, 11 Aug 2009 12:36:26 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id D34893A6FE9 for ; Tue, 11 Aug 2009 12:36:22 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([172.23.15.171]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KO800M36910U6@siemenscomms.co.uk> for drinks@ietf.org; Tue, 11 Aug 2009 20:34:12 +0100 (BST) Date: Tue, 11 Aug 2009 20:34:13 +0100 From: "Elwell, John" In-reply-to: <4A81BFFE.8050604@nic.at> To: Otmar Lendl Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0023D2643@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [drinks] Comment on today's drinks discussion Thread-Index: AcoatiCSCBhy0bC4Th2UgkiN+ps7DgABAvHg Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <35FE871E2B085542A35726420E29DA6B01F18918@gaalpa1msgusr7a.ugd.att.com> <8BC845943058D844ABFC73D2220D46650863B5B0@nics-mail.sbg.nic.at> <35FE871E2B085542A35726420E29DA6B01FA1C64@gaalpa1msgusr7a.ugd.att.com> <4A803F75.50503@nic.at> <0D5F89FAC29E2C41B98A6A762007F5D0023D229D@GBNTHT12009MSX.gb002.siemens.net> <4A81BFFE.8050604@nic.at> Cc: drinks@ietf.org Subject: Re: [drinks] Comment on today's drinks discussion X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 19:36:26 -0000 =20 > -----Original Message----- > From: Otmar Lendl [mailto:lendl@nic.at]=20 > Sent: 11 August 2009 20:01 > To: Elwell, John > Cc: drinks@ietf.org > Subject: Re: [drinks] Comment on today's drinks discussion >=20 > Elwell, John wrote: > > Otmar, > >=20 > > Why do you say both WGs are to blame? SPEERMINT does indeed have the > > LUF/LRF split, so what do you feel is the problem in SPEERMINT? >=20 > John, >=20 > I haven't read the speermint docs (or the mailinglist) in a while, and > missed the last session, too. But a quick glance at > draft-ietf-speermint-voip-consolidated-usecases-13 shows fundamental > LUF/LRF missunderstandings in that document. The SED should=20 > be the output > of the LRF and not the LUF. [JRE] I see - that does indeed appear to be wrong. John >=20 > *shrug* >=20 > > Also, perhaps you should post this to the SPEERMINT list too and say > > that discussions are taking place on the DRINKS list (to=20 > avoid ongoing > > cross-posting). >=20 > I was mentioned by name in this thread, thus I replied here. >=20 > /ol > --=20 > // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // >=20 From lendl@nic.at Tue Aug 11 13:07:41 2009 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E98803A6AB1 for ; Tue, 11 Aug 2009 13:07:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.43 X-Spam-Level: X-Spam-Status: No, score=-2.43 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FsOHQnPR2eMV for ; Tue, 11 Aug 2009 13:07:41 -0700 (PDT) Received: from mail.bofh.priv.at (fardach.bofh.priv.at [88.198.34.164]) by core3.amsl.com (Postfix) with ESMTP id 3835A3A6F67 for ; Tue, 11 Aug 2009 13:07:40 -0700 (PDT) Received: from [84.20.184.64] (mk084020184064.a1.net [84.20.184.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bofh.priv.at (Postfix) with ESMTP id CB8F84CDD6; Tue, 11 Aug 2009 21:01:23 +0200 (CEST) Message-ID: <4A81BFFE.8050604@nic.at> Date: Tue, 11 Aug 2009 21:01:18 +0200 From: Otmar Lendl User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: "Elwell, John" References: <35FE871E2B085542A35726420E29DA6B01F18918@gaalpa1msgusr7a.ugd.att.com> <8BC845943058D844ABFC73D2220D46650863B5B0@nics-mail.sbg.nic.at> <35FE871E2B085542A35726420E29DA6B01FA1C64@gaalpa1msgusr7a.ugd.att.com> <4A803F75.50503@nic.at> <0D5F89FAC29E2C41B98A6A762007F5D0023D229D@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0023D229D@GBNTHT12009MSX.gb002.siemens.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: drinks@ietf.org Subject: Re: [drinks] Comment on today's drinks discussion X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 20:07:42 -0000 Elwell, John wrote: > Otmar, > > Why do you say both WGs are to blame? SPEERMINT does indeed have the > LUF/LRF split, so what do you feel is the problem in SPEERMINT? John, I haven't read the speermint docs (or the mailinglist) in a while, and missed the last session, too. But a quick glance at draft-ietf-speermint-voip-consolidated-usecases-13 shows fundamental LUF/LRF missunderstandings in that document. The SED should be the output of the LRF and not the LUF. *shrug* > Also, perhaps you should post this to the SPEERMINT list too and say > that discussions are taking place on the DRINKS list (to avoid ongoing > cross-posting). I was mentioned by name in this thread, thus I replied here. /ol -- // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // From kcartwright@tnsi.com Thu Aug 13 12:57:06 2009 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3992128C200 for ; Thu, 13 Aug 2009 12:57:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.133 X-Spam-Level: X-Spam-Status: No, score=-2.133 tagged_above=-999 required=5 tests=[AWL=-0.134, BAYES_00=-2.599, J_CHICKENPOX_32=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6YnKKhjHgMNT for ; Thu, 13 Aug 2009 12:57:05 -0700 (PDT) Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by core3.amsl.com (Postfix) with ESMTP id 02CCF28C1F1 for ; Thu, 13 Aug 2009 12:57:04 -0700 (PDT) Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.31826115; Thu, 13 Aug 2009 16:00:22 -0400 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.219]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Thu, 13 Aug 2009 15:56:45 -0400 From: "Cartwright, Kenneth" To: Otmar Lendl , "drinks@ietf.org" Date: Thu, 13 Aug 2009 15:56:42 -0400 Thread-Topic: [drinks] Comment on the NAPTR question Thread-Index: AcoOzOvnrBh2H/CLTfGanDp40rOc8ANeX7bQ Message-ID: <754963199212404AB8E9CFCA6C3D0CDA0725C95A5F@TNS-MAIL-NA.win2k.corp.tnsi.com> References: <20090727151328.GA12249@nic.at> In-Reply-To: <20090727151328.GA12249@nic.at> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [drinks] Comment on the NAPTR question X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 19:57:06 -0000 See responses inline. -----Original Message----- From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of= Otmar Lendl Sent: Monday, July 27, 2009 11:13 AM To: drinks@ietf.org Subject: [drinks] Comment on the NAPTR question This is too long to be asked on the Jabber channel, but let me bring it up here: The question was whether we can capture all information needed in NAPTR records. I think that is definitetly the case for the Number->DestinationGroup mapping. KJC> Agree, I think. NAPTRs are well suited to give LUF responses, dependi= ng on how one described the role of the LUF. Given that the LUF will retur= n "ownership/responsibleParty" data for a given lookup key (e.g. a TN), NAP= TRs can hold that in the form of a URI whose domain name portion dictates t= he current "owner/responsibleParty". However, the phrasing in speermint ar= ch draft does not quite read this way. It describes the LUF as returning a= domain name, while others in the WG meetings have described it as returnin= g a URI. The latter seems to be more accurate and more amenable to NAPTRs.= And this seems to just be a wording problem with the architecture draft r= ather than a structural problem. Stupid Question: Would it be possible to have the Registry push the relevant DestinationGroup/RouteGroup/NAPTR data to its customer's SIP devices independently of any actual call? This is basically a routing table dump. This is the merged with local internal routing data to build the local data structures needed to generate full SED (internal routing to get to the egress element, next external hop, SIP parameters, security parameters, ...) based on a DestGroup as input. KJC> The key part of this question is of course "independently of any actu= al call". On the surface at least the answer seems to be "Yes". However, = at least two caveats are necessary. (1) The "NAPTR" data referred to above= that holds some portion of the SED data necessary to complete the call may= need to be supplemented with additional SED data derived locally by other = means. So if the receptacle for sending SED data is NAPTRs then those NAPT= Rs *may* have to be locally "massaged" to complete that specific call. (2) = The case of source based routing needs to be recognized here. If the sourc= e of each individual call can impact the routing decision, wich it certainl= y can, then the "source identifiers" associated with any given RouteGroup m= ust also be sent down. And the granularity to which source based routing m= ust be supported (caller's domain name, callers TN Prefix, queriers IP addr= ess, etc) will impact the amount of data sent down. Only the TN/PI -> DestGroup mapping is done by a live, on-demand query to the Registry (or a locally cached copy). This is the only time when we actually need to transmit NAPTRs on the wire between the registry and the querying party. KJC> Good Point. Your "background" draft from last October also described = this. However, this assumes that SSPs are willing to make routing queries = to services residing *outside* their local network, incurring the resulting= propagation delay. This is not always acceptable. ------------- What I'm fearing is that we try to use ENUM/NAPTRs as a SIP-Proxy control protocol. It was never designed for that. It can be coaxed to support simple scenarions. More complexity can be supported in the answers (the ugly: URI mentioned today), but it ENUM just can't support complextity in the quesion. See http://tools.ietf.org/html/draft-lendl-speermint-background-02#section-6.2 for a more verbose explanation. All the latest perversions suggested as feature for ENUM (source-dependent lookups, Trunk-groups) stem from this mistake. KJC> Agree that a better data structure could be devised to hold and to co= mmunicate SED than NAPTRs. /ol -- // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H // http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg _______________________________________________ drinks mailing list drinks@ietf.org https://www.ietf.org/mailman/listinfo/drinks This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. From alexander.mayrhofer@nic.at Tue Aug 18 01:59:25 2009 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03C143A67F1 for ; Tue, 18 Aug 2009 01:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.722 X-Spam-Level: X-Spam-Status: No, score=-8.722 tagged_above=-999 required=5 tests=[AWL=-0.162, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_HI=-8, SARE_MLH_Stock1=0.87] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IOybmNYMq+PJ for ; Tue, 18 Aug 2009 01:59:24 -0700 (PDT) Received: from mail.sbg.nic.at (mail.sbg.nic.at [192.174.68.200]) by core3.amsl.com (Postfix) with ESMTP id 6546D3A691E for ; Tue, 18 Aug 2009 01:59:10 -0700 (PDT) Received: from localhost [127.0.0.1] by mail.sbg.nic.at with XWall v3.44 ; Tue, 18 Aug 2009 10:21:57 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-class: urn:content-classes:message Date: Tue, 18 Aug 2009 10:21:54 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Message-ID: <8BC845943058D844ABFC73D2220D466508814FD7@nics-mail.sbg.nic.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Stockholm Meeting minutes posted Thread-Index: Acof3PHfa3aL++F8QtmbBVjQitic8w== From: "Alexander Mayrhofer" To: X-XWALL-BCKS: auto Subject: [drinks] Stockholm Meeting minutes posted X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 08:59:25 -0000 Hello, The minutes from our WG session in Stockholm have been posted to the Meetings Material site. Please review them here: http://www.ietf.org/proceedings/75/minutes/drinks.txt And let us know if there's anything you are missing. Alex From alexander.mayrhofer@nic.at Mon Aug 31 09:38:03 2009 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14C2D3A6DE0 for ; Mon, 31 Aug 2009 09:38:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.78 X-Spam-Level: X-Spam-Status: No, score=-7.78 tagged_above=-999 required=5 tests=[AWL=-0.950, BAYES_50=0.001, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8HEMJVDY34X2 for ; Mon, 31 Aug 2009 09:38:02 -0700 (PDT) Received: from mail.sbg.nic.at (mail.sbg.nic.at [192.174.68.200]) by core3.amsl.com (Postfix) with ESMTP id A6C0928C3A7 for ; Mon, 31 Aug 2009 09:38:01 -0700 (PDT) Received: from localhost [127.0.0.1] by mail.sbg.nic.at with XWall v3.44 ; Mon, 31 Aug 2009 18:38:10 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 31 Aug 2009 18:38:19 +0200 Message-ID: <8BC845943058D844ABFC73D2220D466508815BF5@nics-mail.sbg.nic.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Hiroshima (IETF 75) DRINKS session attendance? Thread-Index: AcoqWXJHk1OleyFRQjaee1+Z8qsKTA== From: "Alexander Mayrhofer" To: X-XWALL-BCKS: auto Subject: [drinks] Hiroshima (IETF 75) DRINKS session attendance? X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2009 16:38:03 -0000 All, Even though IETF75 in Stockholm was just a few weeks ago, we're already starting to plan for the next WG meeting in Hiroshima. Unfortunately, Alex sadly cannot attend the meeting for personal reasons, and it's unsure whether or not Richard can go. Therefore, we're in the process of finding out whom to expect for a potential meeting in the first place: We've created a poll here: http://doodle.com/8xgg5g9bnzrhaka8=20 And we're asking the working group to indicate whether or not they are going to Hiroshima. If there are significant numbers of people attending, we will try hard to make a session possible. (you can use your initials at the poll if you don't like your name to show up there - maybe drop use a mail privately if you do so, so that we can keep track.) If only very few people can attend a potential session in Hiroshima, we would arrange for a virtual interim meeting instead, and the next "real" session would be in Anaheim next year March. Thanks, Alex