Subject: [lisp] #84: Renumbering burden when clients change providers (comment 9 reported by Y. Rekhter)

From: "lisp issue tracker" <[email-masked]>
Date: Wed, 28 Apr 2010 04:45:19 -0000

#84: Renumbering burden when clients change providers (comment 9 reported by Y.
Rekhter)
-------------------------------+--------------------------------------------
Reporter:  wmhaddad@…          |       Owner:     
    Type:  technical           |      Status:  new
Priority:  major               |   Component:  alt
Severity:  -                   |    Keywords:     
-------------------------------+--------------------------------------------
 In the Introduction:

 3.  Easing of renumbering burden when clients change providers.
       Because host EIDs are numbered from a separate, non-provider-
       assigned and non-topologically-bound space, they do not need to
       be renumbered when a client site changes its attachment points to
       the network.

 At least with respect to LISP+ALT, this statement is incorrect.  Sites are
 simply locked in to their EID provider instead of being locked in to their
 ISP as they are now.  The lock-in would appear to be more severe than it
 is today, since unless strong aggregation is preserved, LISP's entire
 value proposition is lost.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/lisp/trac/ticket/84>
lisp <http://tools.ietf.org/lisp/>
LISP WG document issues

---

From: "lisp issue tracker" <[email-masked]>
Date: Wed, 28 Apr 2010 05:53:16 -0000

Priority:  major               |   Component:  draft-ietf-lisp
Changes (by wmhaddad@…):

  * component:  alt => draft-ietf-lisp

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/lisp/trac/ticket/84#comment:1>
lisp <http://tools.ietf.org/lisp/>
LISP WG document issues

---

From: Eliot Lear <[email-masked]>
Date: Wed, 28 Apr 2010 07:59:36 +0200

Yakov (and others),

>   value proposition is lost.

This statement is overly broad, because how aggregation occurs will 
depend on how the ALT ecosystem is built up.  One approach that I have 
heard that could work well be some sort of regional system where 
aggregation occurs at that level.  For instance, there could be several 
ALT EID providers in New York that all make use of a particular block of 
address space.  They disaggregate that address space within region, but 
otherwise aggregate above.

Eliot

---

From: Ross Callon <[email-masked]>
Date: Wed, 28 Apr 2010 17:46:05 -0400

If I understand your proposal correctly: 

There could be several ALT EID providers in a particular region, that all are capable of mapping EID's to RLOC's for a particular range of EID's. They would each be allocating EID's from a particular range (ie, using a common prefix). I assume that this means either that they would coordinate EID assignments, or that they would each have a subrange within this range of EIDs that they could each assign. They would each advertise the same one prefix into the ALT topology covering this range, and many different organizations could have EID's taken from this range (presumably each organization would have a smaller block out of the range). A request for an EID to RLOC mapping could be routed to any of these ALT EID providers, which would either know the mapping (for the entire range), or would know which of the other ALT EID providers in the region would know the mapping. In any case, for the entire ALT topology outside of that region the mapping requests for EID's within that range could be routed to this set of ALT EID providers using a single prefix which covers that range. 

Eliot, is this approximately the model that you are referring to in your email (understanding that this is not the only possible model)? 

How would the geographic and/or topological location of the customer site effect whether or not they would accept (or be given) an EID from this particular range? 

Thanks, Ross

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Eliot Lear
Sent: 28 April 2010 02:00
To: lisp issue tracker
Cc: [email-masked]
Subject: Re: [lisp] #84: Renumbering burden when clients change providers (comment 9 reported by Y. Rekhter)

  Yakov (and others),

Eliot
_______________________________________________
lisp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lisp

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 28 Apr 2010 17:33:13 -0700

Let me add to this thread.

(1) There are no ALT providers.
(2) Sites will use map-resolver and map-servers from a mapping service  
provider (MSP).
(3) There will be multiple MSPs that sell service to sites at a  
specific tier level. This
     is not a pricing tier level, this is an EID address aggregation  
level.
(4) So when a site is allocated an EID-prefix from a RIR, it can buy  
from one or more various
     MSPs.

The site can change MSPs without changing their EID-prefix or their  
locator-set.

And, the site can change service providers and not have to renumber  
their EID-prefix, just a single locator address (it will get a new PA  
address from the new service provider it connects to) changes on the  
CPE router that connects to the new service provider.

The MSP can be an independent entity, an RIR, a service provider,  
interconnect provider, government, etc...

Dino

On Apr 28, 2010, at 2:46 PM, Ross Callon wrote:

> There could be several ALT EID providers in a particular region,  
> that all are capable of mapping EID's to RLOC's for a particular  
> range of EID's. They would each be allocating EID's from a  
> particular range (ie, using a common prefix). I assume that this  
> means either that they would coordinate EID assignments, or that  
> they would each have a subrange within this range of EIDs that they  
> could each assign. They would each advertise the same one prefix  
> into the ALT topology covering this range, and many different  
> organizations could have EID's taken from this range (presumably  
> each organization would have a smaller block out of the range). A  
> request for an EID to RLOC mapping could be routed to any of these  
> ALT EID providers, which would either know the mapping (for the  
> entire range), or would know which of the other ALT EID providers in  
> the region would know the mapping. In any case, for the entire ALT  
> topology outside of that region the mapping requests for EID's  
> within that ran
> ge could be routed to this set of ALT EID providers using a single  
> prefix which covers that range.
>
> Eliot, is this approximately the model that you are referring to in  
> your email (understanding that this is not the only possible model)?
>
> How would the geographic and/or topological location of the customer  
> site effect whether or not they would accept (or be given) an EID  
> from this particular range?
>
> Thanks, Ross
>
> Subject: Re: [lisp] #84: Renumbering burden when clients change  
> providers (comment 9 reported by Y. Rekhter)
>
>  Yakov (and others),
>

---

From: Yakov Rekhter <[email-masked]>
Date: Wed, 28 Apr 2010 18:25:42 -0700

Dino,

>From  section 4.4 of draft-ietf-lisp-ms-05.txt:

                                            Using a LISP+ALT mapaping
       database, the Map-Resolver is connected to the ALT network and
       sends the Map-Request to the next ALT hop learned from its ALT
       BGP neighbors. 

How would the Map-Resolver connect to the ALT network if there
are no ALT providers ?

Yakov.

---

From: Eliot Lear <[email-masked]>
Date: Thu, 29 Apr 2010 07:54:31 +0200

Ross,

First, I'll refer you also to Dino's answer since he has a different 
model in mind.

> Eliot, is this approximately the model that you are referring to in your email (understanding that this is not the only possible model)?

Yes, but see below.

> How would the geographic and/or topological location of the customer site effect whether or not they would accept (or be given) an EID from this particular range?

It almost doesn't matter, so long as there is known state between the 
ETR and the ALT, because we're not talking data packets.  Put another 
way, I *should* have written the above in terms of federations rather 
than regions.

Eliot

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 28 Apr 2010 23:10:49 -0700

> How would the Map-Resolver connect to the ALT network if there

A Map-Resolver has a peering agreement with another organization that  
will do ALT with it. It is not necessarily a subscription based  
service like a site would connect to a service provider as we see it  
today. Ditto for two tier-1 ISPs that BGP peer with each other.

Dino

---

From: Yakov Rekhter <[email-masked]>
Date: Thu, 29 Apr 2010 06:42:55 -0700

Dino,

> today. Ditto for two tier-1 ISPs that BGP peer with each other.

Does the above mean that there is still an ALT network ?

Yakov.

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 29 Apr 2010 16:21:58 +0200

Hi Yakov,

> Does the above mean that there is still an ALT network ?

I am sure Dino or Elliot will give you their answer, but I want to give 
you my POV too.

There is no need for ALT network in the classic understanding of 
"network" which is build and operated by single entity.

There is clearly a need for a mapping plane .. be it LISP-ALT or 
LISP-DHT or LISP-XYZ, but that can be constructed based on mutual 
non-adjacent inter-provider's agreements. (Sure it could be also 
supported by one global provider.) I think terminology wise it would be 
better for it to be referred to as ALT plane not ALT network.

You very well know that this is build using IP encapsulation technology 
which does not require any signaling in the transit networks and 
therefor allows a lot of flexibility (as opposed to any other tunneling 
technology which may require signaling and full support in any transit 
node).

Now can you clarify what is really this particular doubt you are trying 
to clarify ? I don't think I understand issue #84 if this strictly 
assumes EID to RLOC binding. AFAIK that was never the design constrain.

Deployment example:

Assume there is ALT plane in US and someone who will allocate EIDs. Me 
sitting in SJC I can get an EID or set of EIDs for my own network. All I 
need to do is to inform an ALT plane what are my current RLOCs whenever 
I decide to switch the local providers. Other then renumbering a single 
interface to my provider I don't see I need to do any thing else on my 
xTRs acting as CEs.

Cheers,
R.

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 29 Apr 2010 09:18:01 -0700

> Does the above mean that there is still an ALT network ?

Yes, but it is relatively sparse to what you would expect from an  
underlying BGP topology. I really don't mean to be vague but trying to  
understand where the disconnect is.

Dino

>>>>> From: [email-masked] [mailto:[email-masked]] On  
>>>>> Behalf
>>>>> Of Eliot Lear
>>>>> address space.  They disaggregate that address space within  
>>>>> region,
>>>>> but

---

From: Yakov Rekhter <[email-masked]>
Date: Thu, 29 Apr 2010 10:07:20 -0700

Dino,

> understand where the disconnect is.

If there will be an ALT network, then someone should provide it
(someone have to operate the equipment that forms the ALT network).

Thus stating that there is an ALT network contradicts your statement
that "there are no ALT providers".

Yakov.

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 29 Apr 2010 11:14:07 -0700

> that "there are no ALT providers".

I told you who could be an MSP. An MSP connects to the ALT. The ALT  
node can be from any of those MSP organizations.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 29 Apr 2010 11:22:13 -0700

> "network" which is build and operated by single entity.

That was what I was trying to say.

> supported by one global provider.) I think terminology wise it would  
> be better for it to be referred to as ALT plane not ALT network.

Right, that is the model we have defined. We want the "mapping  
database transport system" to be modular and can drop in easily. The  
list above are examples of mapping database transport systems.

Sites do not have to change or upgraded since the use map-resolvers  
and map-servers.

> You very well know that this is build using IP encapsulation  
> technology which does not require any signaling in the transit  
> networks and therefor allows a lot of flexibility (as opposed to any  
> other tunneling technology which may require signaling and full  
> support in any transit node).

That is correct.

> Now can you clarify what is really this particular doubt you are  
> trying to clarify ? I don't think I understand issue #84 if this  
> strictly assumes EID to RLOC binding. AFAIK that was never the  
> design constrain.
>
> Deployment example:
>
> Assume there is ALT plane in US and someone who will allocate EIDs.  
> Me sitting in SJC I can get an EID or set of EIDs for my own  
> network. All I need to do is to inform an ALT plane what are my  
> current RLOCs whenever I decide to switch the local providers. Other  
> then renumbering a single interface to my provider I don't see I  
> need to do any thing else on my xTRs acting as CEs.

Correct.

Dino

---

From: Ross Callon <[email-masked]>
Date: Thu, 29 Apr 2010 16:18:34 -0400

I don't see what would motivate a particular group of organizations to  provide EID to RLOC mapping service unless they can charge for it (or they can roll it into other services, such as Internet connectivity for a corporate site). For a mapping service to cooperate with others on the mapping for a particular range of EIDs seems like a way to drive down the price of the service that they offer. I don't see what would motivate a group of mapping service organizations to cooperate with each other on providing a mapping for a single EID range. 

What seems more likely to me is that one organization would provide a mapping service for a particular range of addresses, and a different organization would provide a mapping service for a different range of addresses. Of course, each organization providing mapping services could make use of multiple redundant servers, both to spread load and to provide backup in case a server fails (and perhaps also to distribute the servers to have a server "near" where any request might come from, in a topological sense). 

To me this seems to imply that a customer site with a EID prefix is tied into a single mapping service, unless they are willing to change their EID. Of course, they can change their Internet service provider from which they get physical connectivity with very little trouble (just tell their mapping service to change their mapping, and change the configured address on their CE routers).  

I do understand that this assumes a model of how the mapping service might be deployed, and that there might be other models and some uncertainty regarding what might actually end up being deployed. 

Ross 

-----Original Message-----
From: Eliot Lear [mailto:[email-masked]] 
Sent: 29 April 2010 01:55
To: Ross Callon
Cc: lisp issue tracker; [email-masked]
Subject: Re: [lisp] #84: Renumbering burden when clients change providers (comment 9 reported by Y. Rekhter)

  Ross,

Yes, but see below.

Eliot

---

From: Darrel Lewis <[email-masked]>
Date: Thu, 29 Apr 2010 13:48:02 -0700

Its my feeling that an organization will be able to charge for mapping.

We know from experience in the DFZ that service providers are willing to route whatever prefixes that their customers provide (PI space or PA space from some other provider).  Many will also route PA space from other providers. Finally if a end site gets PI space from the registries, the point of who gets originally provides the address space is moot.

The key point is none of this is directly tied to the provider that is selling them data-plane Internet access.

-D

On Apr 29, 2010, at 1:18 PM, Ross Callon wrote:

>> There could be several ALT EID providers in a particular region, that all are capable of mapping EID's to RLOC's for a particular range of EID's. They would each be allocating EID's from a particular range (ie, using a common prefix). I assume that this means either that they would coordinate EID assignments, or that they would each have a subrange within this range of EIDs that they could each assign. They would each advertise the same one prefix into the ALT topology covering this range, and many different organizations could have EID's taken from this range (presumably each organization would have a smaller block out of the range). A request for an EID to RLOC mapping could be routed to any of these ALT EID providers, which would either know the mapping (for the entire range), or would know which of the other ALT EID providers in the region would know the mapping. In any case, for the entire ALT topology outside of that region the mapping requests for EID's within that r
> ange could be routed to this set of ALT EID providers using a single prefix which covers that range.
>>

---

From: Eliot Lear <[email-masked]>
Date: Thu, 29 Apr 2010 23:05:42 +0200

> Its my feeling that an organization will be able to charge for mapping.

We have an existence proof of sorts.  Let's look at the forward map 
registry and registrars.

Eliot

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 30 Apr 2010 23:33:51 -0400

Presumably, the EID delegation to end users will be a fee based service. 
  That fee will also cover the costs of running the BGP routers that 
will be needed to maintain the aggregated mapping infrastructure.

If the top level assignment authority (as mandated by RFCs if we ever go 
standards track) requires that there be competition for the maintenance 
of assignments, then the customer can take is business to a competing 
assigner for the block from which he got his EID assigned.
This does require some extra protocol somewhere to allow competing 
assigners.  Ir probably leads to a requirement that the competitors peer 
with each other.  But those sorts of requirements can be included in the 
system.

There are probably other ways to get the competitive goal.
I agree that it is important in the long term that we be able to have 
such competition.
Until I see what the WG wants for deployments, I don't know if that is 
at all important during the experiment.

Yours,
Joel