Subject: [Speermint] Source-based routing

From: "Uzelac, Adam" <[email-masked]>
Date: Wed, 8 Nov 2006 19:17:42 -0500

Folks,

I would like to propose that we add to the list of requirements for
SPEERMINT that any session routing proposal that is proposed take into
account the ability to use some source criteria to return next-hop
routes. I just re-read the requirements draft, and I did not see
anything specifically addressing source-based routing. 

Speaking as a VSP, it's important that the ingress session border
element that is returned to the originator of the request be based on,
among other things, who's asking and from where.  In practice, we do not
return next-hop information irrespective if the request comes from
Alice/Bob, or from China/Brazil.  This may be a matter of local policy,
but the tools and IDs that address session next-hop determination need
to account for this.

-AU

_______________________________________________
Speermint mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speermint

---

From: "Reinaldo Penno" <[email-masked]>
Date: Wed, 8 Nov 2006 19:23:51 -0500

Although I'm not a VSP I agree. At some point we discussed on this the
fact that identity/geography/others should be taken into account when
discovering/returning next-hop. That kind of faded way but seems a real
problem to be tackled.

Regards,

Reinaldo

> -----Original Message-----
> From: Uzelac, Adam [mailto:[email-masked]] 
> Sent: Wednesday, November 08, 2006 4:18 PM
> To: [email-masked]
> Subject: [Speermint] Source-based routing
> 
> Folks,
> 
> I would like to propose that we add to the list of 
> requirements for SPEERMINT that any session routing proposal 
> that is proposed take into account the ability to use some 
> source criteria to return next-hop routes. I just re-read the 
> requirements draft, and I did not see anything specifically 
> addressing source-based routing. 
> 
> Speaking as a VSP, it's important that the ingress session 
> border element that is returned to the originator of the 
> request be based on, among other things, who's asking and 
> from where.  In practice, we do not return next-hop 
> information irrespective if the request comes from Alice/Bob, 
> or from China/Brazil.  This may be a matter of local policy, 
> but the tools and IDs that address session next-hop 
> determination need to account for this.
> 
> -AU
>

---

From: "Pfautz, Penn L, GBLAM" <[email-masked]>
Date: Wed, 8 Nov 2006 22:07:38 -0500

I thought we did have a requirement that addressed at least part of this
issue in
draft-ietf-speermint-requirements-01.txt:

o  Variability of the Call Address Data:
      A terminating VSP/ASP or user SHOULD be able to indicate its
      domain ingress points (Signaling Path Border Element(s)) based on
      the identity of the originating VSP/ASP or user.
      The mechanisms recommended for the use and resolution of the call
      addressing data SHOULD allow for variability or customization of
      the response(s) depending on various elements, such as the
      identity of the originating or terminating user or user domain.

Are you asking just to add geographic origin info to this?
I see originating entity and location info helping to determine routing
but it's not clear to me that this isn't a multi-stage (and maybe
multi-protocol) process.
And by location, are we talking originating user location  or
originating network element location?

Penn
-----Original Message-----
From: Reinaldo Penno [mailto:[email-masked]] 
Sent: Wednesday, November 08, 2006 7:24 PM
To: Uzelac, Adam; [email-masked]
Subject: RE: [Speermint] Source-based routing

Regards,

Reinaldo

---

From: "Reinaldo Penno" <[email-masked]>
Date: Thu, 9 Nov 2006 01:57:46 -0500

There is certainly a requirement, but no concrete method as to how to do
it and what to take into consideration.

I guess the problem statement is:

For a certain call, how to I find the most appropriate egress/ingree
peering point? 

The parameters that make "this" call different from another call and how
exactly you find the peering point are still not properly defined.

> From: Pfautz, Penn L, GBLAM [mailto:[email-masked]] 
> Sent: Wednesday, November 08, 2006 7:08 PM
> To: Reinaldo Penno; Uzelac, Adam; [email-masked]
> I thought we did have a requirement that addressed at least 
> part of this issue in
> I see originating entity and location info helping to 
> determine routing but it's not clear to me that this isn't a 
> multi-stage (and maybe
> multi-protocol) process.
> Although I'm not a VSP I agree. At some point we discussed on 
> this the fact that identity/geography/others should be taken 
> into account when discovering/returning next-hop. That kind 
> of faded way but seems a real problem to be tackled.
> 
> Regards,
> 
> Reinaldo
> 
> > among other things, who's asking and from where.  In 
> practice, we do 
> > not return next-hop information irrespective if the request 
> comes from 
> > Alice/Bob, or from China/Brazil.  This may be a matter of local 
> > policy, but the tools and IDs that address session next-hop

---

From: Michael Haberler <[email-masked]>
Date: Thu, 09 Nov 2006 08:37:34 +0100

> For a certain call, how to I find the most appropriate egress/ingree

I'm not sure wether that was what Adam meant - need to clarify

I see two interpretations:
- topological optimization of next hop (IP adress, distance..)
- a parameter into policy application - for resolution services which
might give different answers to different originators

-Michael

---

From: "Patrick Melampy" <[email-masked]>
Date: Thu, 9 Nov 2006 14:20:58 -0500

The real issue here affects signaling and media. It appears to me that the
correct algorithm to use would be based on the offered addresses in the SDP,
and which border signaling point is closest. The reasons for this are:

1.) The signaling originator may not be co-located with the source of media.
This is often the case with Softswitch/Media Gateway sources of traffic. Its
also like to be true with Softswitch Based endpoints (MGCP/NCS) where the
call controller is centrally located, but the endpoints are widely
distributed.

2.) The signaling crossing point that is closes to the source of the media
provides a "best crossing point" for the media as well.

Although I've resisted talking about the media --- its truly important. The
location of the media crossing point, and the control of the media, are as
important as any other aspect in peering. 

There are some that would suggest the signaling crossing points and media
crossing points are un-related. But to subsequently setup, manage, and
control the media with a middle box requires the same determination of the
best media crossing point. The mechanisms for doing this "locate the best
middle box" are weak at best. Some say use a policy server. However none of
the policy server interfaces I have seen proposed by ETSI TISPAN, 3GPP, seem
to include a "source ip address" in the request to help choose a destination
ip address. While out of the scope of this working group, one should
consider the utility of the following suggestion.

I propose that the best signaling crossing point be determined based on the
source of the media. This would provide for a defined crossing point that
then could manage the media flows by association.

-----Original Message-----
From: Michael Haberler [mailto:[email-masked]] 
Sent: Thursday, November 09, 2006 2:38 AM
To: Reinaldo Penno
Cc: [email-masked]; Uzelac, Adam
Subject: Re: [Speermint] Source-based routing

Reinaldo Penno schrieb:
> For a certain call, how to I findFrom [email-masked] Thu Nov 09 14:28:27 2006
From: "Patrick Melampy" <[email-masked]>
To: "'Michael Haberler'" <[email-masked]>,
	"'Reinaldo Penno'" <[email-masked]>
Subject: RE: [Speermint] Source-based routing
Date: Thu, 9 Nov 2006 14:20:58 -0500
Cc: [email-masked], "'Uzelac, Adam'" <[email-masked]>

The real issue here affects signaling and media. It appears to me that the
correct algorithm to use would be based on the offered addresses in the SDP,
and which border signaling point is closest. The reasons for this are:

1.) The signaling originator may not be co-located with the source of media.
This is often the case with Softswitch/Media Gateway sources of traffic. Its
also like to be true with Softswitch Based endpoints (MGCP/NCS) where the
call controller is centrally located, but the endpoints are widely
distributed.

2.) The signaling crossing point that is closes to the source of the media
provides a "best crossing point" for the media as well.

Although I've resisted talking about the media --- its truly important. The
location of the media crossing point, and the control of the media, are as
important as any other aspect in peering. 

There are some that would suggest the signaling crossing points and media
crossing points are un-related. But to subsequently setup, manage, and
control the media with a middle box requires the same determination of the
best media crossing point. The mechanisms for doing this "locate the best
middle box" are weak at best. Some say use a policy server. However none of
the policy server interfaces I have seen proposed by ETSI TISPAN, 3GPP, seem
to include a "source ip address" in the request to help choose a destination
ip address. While out of the scope of this working group, one should
consider the utility of the following suggestion.

I propose that the best signaling crossing point be determined based on the
source of the media. This would provide for a defined crossing point that
then could manage the media flows by association.

-----Original Message-----
From: Michael Haberler [mailto:[email-masked]] 
Sent: Thursday, November 09, 2006 2:38 AM
To: Reinaldo Penno
Cc: [email-masked]; Uzelac, Adam
Subject: Re: [Speermint] Source-based routing

-Michael

---

From: "Reinaldo Penno" <[email-masked]>
Date: Thu, 9 Nov 2006 14:56:12 -0500

As I side note I mentioned in the IETF meeting that we keep pushing
media aside and only talking about signaling but what mostly matters in
terms of user experience is the media.  So, I agree with you that media
is important.

About your suggestion below, that's a nice insight, but it is still not
clear to me how from the source IP address the proxy finds the notion of
"distance". Of course the first peering proxy that receives the
signaling can look at number of Vias or TTL or others.  But how would
this proxy find out the distance between the endpoint and other peering
proxies in order to send a correct 302, for instance? 

So, the "default" peering proxy can try to find that out (even if
consulting some external DB) or the endpoint could try itself. The
endpoint could send OPTION messages with increasing Max-Forwards to a
coupld of proxies, or some other funky method.

Thanks,

Reinaldo

> From: Patrick Melampy [mailto:[email-masked]] 
> Sent: Thursday, November 09, 2006 11:21 AM
> To: 'Michael Haberler'; Reinaldo Penno
> Cc: [email-masked]; 'Uzelac, Adam'
> The real issue here affects signaling and media. It appears 
> to me that the correct algorithm to use would be based on the 
> offered addresses in the SDP, and which border signaling 
> point is closest. The reasons for this are:
> 
> This is often the case with Softswitch/Media Gateway sources 
> of traffic. Its also like to be true with Softswitch Based 
> endpoints (MGCP/NCS) where the call controller is centrally 
> located, but the endpoints are widely distributed.
> 
> 2.) The signaling crossing point that is closes to the source 
> of the media provides a "best crossing point" for the media as well.
> 
> Although I've resisted talking about the media --- its truly 
> important. The location of the media crossing point, and the 
> control of the media, are as important as any other aspect in 
> peering. 
> 
> There are some that would suggest the signaling crossing 
> points and media crossing points are un-related. But to 
> subsequently setup, manage, and control the media with a 
> middle box requires the same determination of the best media 
> crossing point. The mechanisms for doing this "locate the 
> best middle box" are weak at best. Some say use a policy 
> server. However none of the policy server interfaces I have 
> seen proposed by ETSI TISPAN, 3GPP, seem to include a "source 
> ip address" in the request to help choose a destination ip 
> address. While out of the scope of this working group, one 
> should consider the utility of the following suggestion.
> 
> I propose that the best signaling crossing point be 
> determined based on the source of the media. This would 
> provide for a defined crossing point that then could manage 
> the media flows by association.
> 
> - a parameter into policy application - for resolution 
> services which might give different answers to different originators
> 
> 
> 
> -Michael
>

---

From: "Uzelac, Adam" <[email-masked]>
Date: Thu, 9 Nov 2006 15:11:19 -0500

Is there consensus around the notion that media considerations are in
scope of SPEERMINT?  It's not always the case, but it should be a
consideration when determining next-hops route responses to a location
function look-up.  I would like to point out that this becomes very
difficult in ENUM/DNS next-hop determinations.  Hence the existence of
the INVITE/3XX next-hop determination method.

-AU

PS - please read "media considerations" as _NOT_ meaning exclusively
CODECs. 

-----Original Message-----
From: Reinaldo Penno [mailto:[email-masked]] 
Sent: Thursday, November 09, 2006 11:56 AM
To: Patrick Melampy; Michael Haberler
Cc: [email-masked]; Uzelac, Adam
Subject: RE: [Speermint] Source-based routing

Thanks,

Reinaldo

> The real issue here affects signaling and media. It appears to me that

> the correct algorithm to use would be based on the offered addresses 
> in the SDP, and which border signaling point is closest. The reasons 
> for this are:
> 
> This is often the case with Softswitch/Media Gateway sources of 
> traffic. Its also like to be true with Softswitch Based endpoints 
> (MGCP/NCS) where the call controller is centrally located, but the 
> endpoints are widely distributed.
> 
> 2.) The signaling crossing point that is closes to the source of the 
> media provides a "best crossing point" for the media as well.
> 
> important. The location of the media crossing point, and the control 
> of the media, are as important as any other aspect in peering.
> 
> There are some that would suggest the signaling crossing points and 
> media crossing points are un-related. But to subsequently setup, 
> manage, and control the media with a middle box requires the same 
> determination of the best media crossing point. The mechanisms for 
> doing this "locate the best middle box" are weak at best. Some say use

> a policy server. However none of the policy server interfaces I have 
> seen proposed by ETSI TISPAN, 3GPP, seem to include a "source ip 
> address" in the request to help choose a destination ip address. While

> out of the scope of this working group, one should consider the 
> utility of the following suggestion.
> 
> I propose that the best signaling crossing point be determined based 
> on the source of the media. This would provide for a defined crossing 
> point that then could manage the media flows by association.
>

---

From: Shawn Pouliotte <[email-masked]>
Date: Thu, 09 Nov 2006 12:18:42 -0800

I think the biggest question for me is what is important at the peering
point - there are a lot of things that could theoretically be signaled but
what is important? You are trying to decide if, how and where to admit
traffic into a network.

For this chain, yes, I was thinking about a collapsed BG model. You are
alluding to a mid-com model as I read it. I only know of 1 vendor offering
H.248 controlled ip to ip gateways and they are not seeing much success. I
know of one other vendor that is developing in this area. The general driver
for this as I understood was streamlining resources by splitting signaling
and media, offering a better scaling model, better resource selection model,
and h/a model. That said, I have not run into anyone that actually wanted
media path in a vastly different geography from signaling. Nothing would
preclude it. I am curious to hear thoughts from the carrier representatives
on the list. 

So, with all that I certainly don't disagree that source based parameters
play a role in route selection. When the group makes recommendations on
those, we should understand the use cases and why they are important (in a
deployable network).

Shawn

---

From: "Uzelac, Adam" <[email-masked]>
Date: Thu, 9 Nov 2006 15:30:18 -0500

[Shawn sayz]"I think the biggest question for me is what is important at
the peering point"
[adam sayz] - The pickle here is that this is very much a matter of
local policy.  As a VSP, all I would like is a method to know and
account for things that are important to me.

[Shawn sayz]"- there are a lot of things that could theoretically be
signaled but what is important? "
[adam sayz] Once again as a VSP, what's needed is a method to know and
account for criteria that is important to my next-hop route
determination. BUT what is important to me isn't necessarily important
to someone else, or what's important at sunset isn't at sunrise, etc,
etc.  We are starting to get into requirement for the provisioning draft
that David Schwartz signed himself up to developing - and this is a good
thing.

As I see it, queries to external registries/databases/etc to determine
next-hops ultimately provide inputs for a local next-hop routing
determination.  

-AU

---

From: "Reinaldo Penno" <[email-masked]>
Date: Thu, 9 Nov 2006 15:35:51 -0500

Hello Shawn,

the reverse is also true. If you _do not_ have a collapsed peering
scheme (signaling and media crossing at the same point through media
anchoring), chances are media is going to follow layer 3 routing and
signaling Layer 5 (route headers, outbound proxy, etc, etc). And they
might in fact go to two different completely locations.

So, maybe what you actually like is for media to follow signaling after
you discover the "best" (whatever that means) signaling crossing point.

Regards,

Reinaldo

> From: Shawn Pouliotte [mailto:[email-masked]] 
> Sent: Thursday, November 09, 2006 12:19 PM
> To: Patrick Melampy; 'Michael Haberler'; Reinaldo Penno
> I think the biggest question for me is what is important at 
> the peering point - there are a lot of things that could 
> theoretically be signaled but what is important? You are 
> trying to decide if, how and where to admit traffic into a network.
> 
> 
> For this chain, yes, I was thinking about a collapsed BG 
> model. You are alluding to a mid-com model as I read it. I 
> only know of 1 vendor offering
> H.248 controlled ip to ip gateways and they are not seeing 
> much success. I know of one other vendor that is developing 
> in this area. The general driver for this as I understood was 
> streamlining resources by splitting signaling and media, 
> offering a better scaling model, better resource selection 
> model, and h/a model. That said, I have not run into anyone 
> that actually wanted media path in a vastly different 
> geography from signaling. Nothing would preclude it. I am 
> curious to hear thoughts from the carrier representatives on 
> the list. 
> 
> So, with all that I certainly don't disagree that source 
> based parameters play a role in route selection. When the 
> group makes recommendations on those, we should understand 
> the use cases and why they are important (in a deployable network).
> 
> Shawn
> 
> 
> to me that 
> > in the SDP, and which border signaling point is closest. 
> The reasons for this are:
> > 
> > out of the scope of this working group, one should consider 
> the utility of the following suggestion.
> > 
> determined based 
> services which

---

From: "Stastny Richard" <[email-masked]>
Date: Thu, 9 Nov 2006 21:33:07 +0100

IMO it is in scope, but our first priority is to get a peering going at all

media is only relevant in some use cases and the problems are not
easy to resolve. So it should have second priority - it will also take
some time to work out the use cases, etc.
 
Richard

________________________________

Von: Uzelac, Adam [mailto:[email-masked]]
Gesendet: Do 09.11.2006 21:11
An: Reinaldo Penno; Patrick Melampy; Michael Haberler
Cc: [email-masked]
Betreff: RE: [Speermint] Source-based routing

-AU

-----Original Message-----
From: Reinaldo Penno [mailto:[email-masked]]
Sent: Thursday, November 09, 2006 11:56 AM
To: Patrick Melampy; Michael Haberler
Cc: [email-masked]; Uzelac, Adam
Subject: RE: [Speermint] Source-based routing

Thanks,

Reinaldo

---

From: "Stastny Richard" <[email-masked]>
Date: Thu, 9 Nov 2006 21:44:48 +0100

>you discover the "best" (whatever that means) signaling crossing point.
 
This is exactly the problem here: I do not care about the "best" (whatever that means ;-)
signalling crossing point). The only thing that counts in source based routing is media
 
IMO we are trying to solve a problem we have created by ourselves:

First we do not use the basic peering model  (end-user to end-user) for whatever weird reason,
and then we are not happy with the resulting media stream going a weird signalling path
and want to optimize it a bit, introducing a very complex next hop routing scheme -- but
not for signalling, for media
 
Richard

Von: Reinaldo Penno [mailto:[email-masked]]
Gesendet: Do 09.11.2006 21:35
An: Shawn Pouliotte; Patrick Melampy; Michael Haberler
Cc: [email-masked]; Uzelac, Adam
Betreff: RE: [Speermint] Source-based routing

Hello Shawn,

Regards,

Reinaldo

---

From: "Reinaldo Penno" <[email-masked]>
Date: Thu, 9 Nov 2006 15:46:01 -0500

It is in scope

"However, in order to achieve real-time Session PEERing,
both signaling and media flows must be taken into
consideration. In addition, the working group recognizes that
there will be use cases that require SPEERMINT to focus on the
interaction between the application layer and lower network
layers, or the dependence of specific application layer use
cases on lower layers, so SPEERMINT will have to be prepared to
solve these problems as they arise."

Thanks,

Reinaldo 

> From: Stastny Richard [mailto:[email-masked]] 
> Sent: Thursday, November 09, 2006 12:33 PM
> To: Uzelac, Adam; Reinaldo Penno; Patrick Melampy; Michael Haberler
> Cc: [email-masked]
> media is only relevant in some use cases and the problems are 
> not easy to resolve. So it should have second priority - it 
> will also take some time to work out the use cases, etc.
>  
> Richard
> 
> Is there consensus around the notion that media 
> considerations are in scope of SPEERMINT?  It's not always 
> the case, but it should be a consideration when determining 
> next-hops route responses to a location function look-up.  I 
> would like to point out that this becomes very difficult in 
> ENUM/DNS next-hop determinations.  Hence the existence of the 
> INVITE/3XX next-hop determination method.
> 
> -AU
> 
> PS - please read "media considerations" as _NOT_ meaning 
> exclusively CODECs.
> 
> As I side note I mentioned in the IETF meeting that we keep 
> pushing media aside and only talking about signaling but what 
> mostly matters in terms of user experience is the media.  So, 
> I agree with you that media is important.
> 
> About your suggestion below, that's a nice insight, but it is 
> still not clear to me how from the source IP address the 
> proxy finds the notion of "distance". Of course the first 
> peering proxy that receives the signaling can look at number 
> of Vias or TTL or others.  But how would this proxy find out 
> the distance between the endpoint and other peering proxies 
> in order to send a correct 302, for instance?
> 
> So, the "default" peering proxy can try to find that out 
> (even if consulting some external DB) or the endpoint could 
> try itself. The endpoint could send OPTION messages with 
> increasing Max-Forwards to a coupld of proxies, or some other 
> funky method.
> 
> Thanks,
> 
> Reinaldo
> 
> 
> 
> The reasons 
> > 1.) The signaling originator may not be co-located with the 
> source of 
> > media.

---

From: "Reinaldo Penno" <[email-masked]>
Date: Thu, 9 Nov 2006 15:48:02 -0500

I agree about the media statement. I was just poiting out that maybe the
signaling crossing path is also the best one for media. But maybe not. 

> Sent: Thursday, November 09, 2006 12:45 PM
> To: Reinaldo Penno; Shawn Pouliotte; Patrick Melampy; Michael Haberler
> This is exactly the problem here: I do not care about the 
> "best" (whatever that means ;-) signalling crossing point). 
> The only thing that counts in source based routing is media
>  
> First we do not use the basic peering model  (end-user to 
> end-user) for whatever weird reason, and then we are not 
> happy with the resulting media stream going a weird 
> signalling path and want to optimize it a bit, introducing a 
> very complex next hop routing scheme -- but not for 
> signalling, for media
>  
> Richard
> 
> the reverse is also true. If you _do not_ have a collapsed 
> peering scheme (signaling and media crossing at the same 
> point through media anchoring), chances are media is going to 
> follow layer 3 routing and signaling Layer 5 (route headers, 
> outbound proxy, etc, etc). And they might in fact go to two 
> different completely locations.
> 
> So, maybe what you actually like is for media to follow 
> signaling after you discover the "best" (whatever that means) 
> signaling crossing point.
> 
> Regards,
> 
> Reinaldo
> 
> > I think the biggest question for me is what is important at the 
> > peering point - there are a lot of things that could 
> theoretically be 
> > signaled but what is important? You are trying to decide 
> if, how and 
> > where to admit traffic into a network.
> >
> >
> > For this chain, yes, I was thinking about a collapsed BG model. You 
> > are alluding to a mid-com model as I read it. I only know 
> of 1 vendor 
> > offering
> > H.248 controlled ip to ip gateways and they are not seeing much 
> > success. I know of one other vendor that is developing in 
> this area. 
> > The general driver for this as I understood was 
> streamlining resources 
> > by splitting signaling and media, offering a better scaling model, 
> > better resource selection model, and h/a model. That said, 
> I have not 
> > run into anyone that actually wanted media path in a vastly 
> different 
> curious to 
> > hear thoughts from the carrier representatives on the list.
> >
> > So, with all that I certainly don't disagree that source based 
> > parameters play a role in route selection. When the group makes 
> > recommendations on those, we should understand the use 
> cases and why 
> > they are important (in a deployable network).
> >
> > Shawn
> >
> >
> > source of media.
> points and

---

From: Shawn Pouliotte <[email-masked]>
Date: Thu, 09 Nov 2006 13:11:11 -0800

Adam,

I completely understand you and agree 100%. The difficulty I have is that a
vague requirement will lead to huge variation in implementation. At the end
of all this, people will implement products to try and address the needs.
For the various scenarios, what are the needs? For example, is there a use
case in peering where I might want to route on "s=" in an SDP? I would think
not but maybe there is. I agree that source information is important, but
what is the minimum set?

Perhaps the provisioning requirements will flesh this out but provisioning
will also cover administrative concepts that are out of scope of signaling.

K - I'll try and shut up now. Lets see where the provisioning requirements
take us. 

Shawn

On 11/9/06 12:30 PM, "Uzelac, Adam" <[email-masked]> wrote:

> what's needed is a method to know and

---

From: Otmar Lendl <[email-masked]>
Date: Thu, 9 Nov 2006 23:04:07 +0100

On 2006/11/09 20:11, Patrick Melampy <[email-masked]> wrote:
> and which border signaling point is closest. 

"closest" is optional.

"reachable" is the important issue.

Consider VSP networks connected to each other via various VoIP-peering
setups (e.g. special VLANs at Internet exchanges like LINX, AMSIX & co
that are not routed on the Internet).

Example: 
Let VSP1 be connected to IX-A and IX-B
Let VSP2 be connected to IX-B and IX-C
Let VSP3 be connected to IX-A and IX-C

a) If VSP1 wants to reach VSP2, that call needs to go via IX-B. 
b) If VSP3 wants to reach VSP2, he needs go via IX-C, thus a different
ingress point into VSP2.

If we have URI based addressing and use the global DNS, we have a
problem here with straight forward SRV/A lookups. Whatever you put in
there, you will give unusable answers to half of the queries and expect
the caller to fall back to the second avertized ingress point. This will
not scale with the number of such IXs out there.

There are a number of ways to solve this:

* The location-function is local to the IX-*. 
  In that case, in a) the LF in IX-B will tell VSP1 the ingress point of
  VSP2 which resides within IX-B

  On the other hand, in b) the LF in IX-C will return a different
  ingress point for VSP2, namely the one in IX-C.

  This does not scale all too well as parallel/sequential queries
  into all LFs of all IXs are needed.

* Let VSP2 operate a sip proxy on the open internet which uses
  3xx replies to direct VSP1 and VSP3 to ingress points within the
  IX-* networks.

* Manual configuration.
  The source network has local configuration regarding what ingress
  element it is supposed to target when talking to a certain destination
  (as defined by domain or E.164 prefix).

* Changes to the domain -> ingress algorithm (i.e. rfc3263).

* Add IX- membership indications to the DNS. Thus the source VSP
  can use a IX-specific algorithm for ingress discovery.
  (that's what I propose in
  http://tools.ietf.org/wg/speermint/draft-lendl-speermint-federations-03.txt
  )

In other words: Plain ENUM/RFC3263 won't cut it. We can add the
source-dependency (or IX-dependency) at various steps in the lookup 
chain. I just don't see a way around that.

/ol
-- 
< Otmar Lendl ([email-masked]) | nic.at Systems Engineer >