Re: [dispatch] War of the Worlds (was Re: I-D Action: draft-malas-dispatch-sip-egress-route-00)

Jon,

The provisioning of the "egress route" information is done by the originating side.  The terminating side provisions their ingress routing information into an ENUM server, and the originating party evalutes the routes and associates egress routes to them.  In this way, they append the information provided by the terminating side (provisioning side).  If the terminating side changes the route (domain's) associated with the TNs, which an egress route was appended, then the egress route information is no longer valid and is removed.  The originating side would have to append a new egress route.  Yes, this may seem inefficient, but there are two industry assumptions: 1) routes do not change very often; 2) the efficiency gained by associating an egress route is greater than the inefficiency in updating egress routes.

This draft does not consider the "business" reasons for doing this, but simply says...since, we know you are already doing this, then we should make the method consistent using (a) well defined mechanism(s) approved by a body of experts.

I do not think this goes against what Otmar was asserting in his Speermint draft.  I believe Otmar was trying to address a bigger picture issue, which was not ignored in Speermint.  On the contrary, we decided early to address the short-term issue of basic telephony peering using SIP, and then move on to the bigger more complex issue.  It just took us longer to get there than we expected.  We are still listening.

Regards,

Daryl

________________________________
From: Peterson, Jon [mailto:jon.peterson@neustar.biz]
Sent: Tuesday, March 16, 2010 5:30 PM
To: Adam Roach; Daryl Malas; Dean Willis
Cc: dispatch@ietf.org
Subject: Re: [dispatch] War of the Worlds (was Re: I-D Action: draft-malas-dispatch-sip-egress-route-00)

I'm not sure that dispatching malas-dispatch-sip-egress-route requires us to untwist this particular Gordian knot, nor to resurrect TRIP,  nor to declare some kind of interplanetary Armageddon.

I think Otmar Lendl has been right on the mark in this discussion. He points out that global directories like ENUM serve well as an LUF and poorly as an LRF, to speak in the SPEERMINT idiom - I don't think this is an especially controversial point. I read malas-dispatch-sip-egress as a document that argues that knowing the results of the LUF doesn't necessarily help you to find a next hop to route your call through. Again, I'd say not especially controversial.

malas-dispatch-sip-egress-route then goes on to specify a few NAPTR syntaxes that could contain a sort of joint LUF/LRF routing information. The only conceptual problem I have with this approach is that the entity that typically provisions the LUF doesn't know the local topology of the originating network well enough to say useful things about the LRF - that is indeed the entire motivation for considering the LUF and LRF as separate lookups. The draft sort of glosses this over with a lot of passive voice when describing how the ENUM provisioning gets done. Is it done by the terminating side, or the originating side, or somehow both?

In any event, from a DISPATCH perspective, I'd propose the problem seems to lie comfortable within the parameters of SPEERMINT. Surely one of the SPEERMINT chairs must think this is a worthwhile effort...

Jon Peterson
NeuStar, Inc.

On 3/16/10 3:24 PM, "Adam Roach" <adam@nostrum.com> wrote:

On 3/16/10 3:59 PM, "Daryl Malas" <D.Malas@cablelabs.com> wrote:

> I believe this issue was summarized well during the 73rd IETF meeting at the
> RAI open meeting, and captured in Jonathan's draft:
> http://tools.ietf.org/html/draft-rosenberg-rai-modest-proposal-00

I think Jonathan Rosenberg correctly identified that there was a problem
here. And then, just like Jonathan Swift's original "Modest Proposal," he
goes on to propose that the solution to our problem is best found in eating
our own children.

I disagree profoundly with characterizing Rosenberg's Modest Proposal as an
appropriate summary of the issues, as it gets the analysis precisely wrong.
It proposes completely abandoning the vibrant world as a lost cause, and
embracing the stagnant world as the only path forward. This isn't just
allowing collateral damage to the vibrant world for the sake of expediency
in stagnant world solutions -- it's a suggestion that we nuke the vibrant
world so it doesn't keep annoying people trying to develop stagnant
solutions.

I'll admit that it's easier to see the stagnant world, since the telcos have
quite a bit of money to throw around driving its deployment. But there are
people in the vibrant world working on new services. Go back and re-read
Greger's description of what he's seeing deployed. Check out the stuff that
AG Projects (http://ag-projects.com/) has been working on, selling, and
actually deploying. I don't recall whether you would have been at the
meeting where I wore a t-shirt showing some novel SIP devices -- I'll bring
it to Anaheim.

/a

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch