Subject: [lisp] Fwd: Re: Re: A mapping system design-- specification of LISP+ALT

From: Charrie Sun <[email-masked]>
Date: Wed, 2 Dec 2009 14:46:24 +0800

It seems there's some problem of my address sending e-mail to the mailing
list. I have changed my address to the mailing list. Sorry for answering the
letter late:)

-------- Forwarded Messages --------
From: "sunletong" <[email-masked]>
To: "David Meyer" <[email-masked]>

Hi David:
    Many thanks for your reply: ) There seems to have some
misconception and i'll try to explain it.

David Meyer <[email-masked]> 在 Tue, 1 Dec 2009 07:53:01 写道：
> Sun,
>
>
>>         I'm a newcomer in this area and please forgive hasty intruding
>>    in.  A few days ago rrg collected proposals of Internet scalability
>>    solutions, and I raised one based on LISP+ALT which concentrates on how
>>    to do EID-to-RLOC mappings.
>
> Thanks for the thinking on this topic. A few comments:
>
> First, much of your design seems to key off section 6.2
> ("Who contains the actual mappings"). What you say is
> that a multihomed site will with two upstreams will have
> "two ETRs located in different ISPs". I take it you mean
> the ETRs will be in the PEs of those ISPs? If so, we
> looked at this design (and IIRC APT also put the ETRs in
> the PEs). In the LISP+ALT architecture, the ETRs are in
> the CEs. Reasons for siting the ETRs in the CEs include:
> providing the site with control over ingress TE, and the
> issue of who stores which database mappings for the site
> (you raised this one); note that when the ETRs are in the
> site's CE(s), the site can arrange the database mappings
> (and which ETR responds to queries) in any way that
> reaches its policy objctives. This is not the case when
> a site's database mappings are held in its upstream
> provider.
>
    Putting ETRs at PEs is originally to isolate customers from being
involved in the separation task and to let ISPs do it. Since it's
largely the core networks that face the scalability problems: many
edge networks do not have a full global routing table, so what are the
incentives for them to take this work? However let ETRs be at CEs do
make mapping data management and TE (so forth) much practicable.

>> Attached is my proposal. A few
>>    summaries listed below:
>>
>>        1. the mapping system  should be run by a neutral body (e.g. public
>>    utility), to be independent of ISPs. This is to conform economy
>>    incentives and to maximize the system's benefits; besides, any ISP who
>>    wants to implement separation could soon benefit from reducing its core
>>    routing table by getting map information from the mapping system;
>
> Yes, though I envision a DNS-like scenario where many
> map-server/resolver providers exist, with some
> distribution mechanism tieing them together (the ALT is
> one example of such a distribution mechanism).
>
>>        2. a specification of how the mapping system is layered both for
>>    IPv4 EID and IPv6 EID: a tradeoff consideration of layer number and
>>    node burden is discussed. And two layers with /16 aggregates each layer
>>    for IPv4, five layers with /24 aggregates each layer  for IPv6 may be
>>    appropriate;
>
> A mapping system like the ALT can have arbritary
> hierarchy. The tradeoff is data-plane fanout (at each
> mapping node) versus the strech that each query
> experienes.
>
    Exactly what i mean tradeoff is much similar to yours. Yet, do you
mean that ALT system is arbitrarily layered and there's no need a norm
as to the layer number and fanout measures each mapping node should
contain? I originally thought there would be a specification of the
layer system which haven't yet be decided.

>>        My questions contain:
>>
>>       1. Is it practical to let a neutral body/group run mapping system?
>>    They can be another interest group, independent of ISP?
>
> My sense is that this will be driven by economic
> concerns. That is, if someone thinks they can make money
> providing mapping services/infrastructure, they will.
>
    thanks a lot for your basic confirmation of this idea. I'm much
relieved to know that it is not impracticable.

>>        2. One my assertion is that EID prefix should not overlap, for EIDs
>>    are assigned to edge sites and they shouldn't be allocated further. Is
>>    that correct?
>
> Not sure exactly what you mean here. That said, as long
> as there is interworking required (read: forever), the
> EID and RLOC spaces can not overlap.
>
    Not EID and RLOC overlapp (they at first should be separated:))
What i mean is like today's IP prefixes can an EID prefix cover
another smaller one? This is to ensure that a mapping lookup need not
to do a longest-prefix match. As i have explained, an edge network
wouldn't subdivide it's EID prefix and give it to another edge work,
like provider networks do. So there wouldn't be overlap between EID
prefixes (?)

>>       It is too impudent to raising a hand here and if my questions are
>>    too naive please forgive me.
>
> Nah, not at all. Its always great for new people to come
> along and question current thinking and have new
> ideas. That is a very good thing that should be
> encouraged.
>
>> Any reply will be warmly accepted and i'll be deeply
>>  appreciated:)  At last sorry for such long words: )
>
> No problem, and again, thanks for your thinking on this
> subject.
>
> Dave
>

    At last, I didn't see the two cache design and comments about them
here. The main functionality of the second map-node-pointer cache is
to facilitate data validity confirmation. Also I've made some
experiments and the results show that the second cache can effectively
reduce the hops each query experiences.
    Greatly thanks once again:)

Best Regards,
Letong

---

From: David Meyer <[email-masked]>
Date: Wed, 2 Dec 2009 08:14:45 -0800

> list. I have changed my address to the mailing list. Sorry for answering the

	No worries.

> layer system which haven't yet be decided.

	Sorry, let me see if I can be a little clearer. Since the
	ALT is just BGP, we can build as many (or as few) layers
	of hierarchy (i.e., aggregation boundaries) as we
	like. It seems a reasonable approach would include a few
	such aggregation boundaries. Note that there is nothing
	in the protocol that enforces this; hierarchy is
	implemented though policy. That said, business concerns
	will dominate how mapping systems are deployed. People
	will do what makes most sense for their business.

> another smaller one?

	Yes.

> This is to ensure that a mapping lookup need not

	I think I understand what you are saying, but in the case
	of the ALT it is just BGP.

	Dave

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 02 Dec 2009 11:23:08 -0500

I think that there is a subtle difference between the IP situation for 
nested prefixes and the LISP EID situation.

As I read things, and I may be confused, you can not have two sets of 
responses that map EID blocks to RLOCs, where one response is for a 
short prefix, and one is for a long prefix within that, pointing to 
different RLOCs.  If you ever do that, I think there is significant 
misdirection potential.
SUppose that an ITR first asks for a destination EID that is inside the 
short prefix, and outside the long one.  The ITR gets an answer.
If the ITR then gets a packet with a destination EID from the long 
prefix, there will already be a proper match in the table.  It will not 
issue a new resolution request.  (And assuming both sets of traffic 
continue, it is quite likely that the short prefix will be refreshed 
consistently, and the long prefix never discovered.

Thus, while EIDs can be delegated from shorter prefixes to longer 
prefixes, I think that an EID block that actually resolves to RLOCs can 
never also delegate a portion of that space to a separate entity, with 
distinct RLOCs.

It is quite possible that I am missing something, and I apologies if so.

Yours,
Joel

David Meyer wrote:
...
>> What i mean is like today's IP prefixes can an EID prefix cover
...

---

From: David Meyer <[email-masked]>
Date: Wed, 2 Dec 2009 08:39:41 -0800

Joel,

> never also delegate a portion of that space to a separate entity, with  

	Let me see if I understand. Are you saying that you can't
	have two mapping sover the form:

	a.b.c.d/n -> rloc.1
	a.b.c.d/m -> rloc.2
	
	where (n < m) && (rloc.1 != rloc.2)

	Dave

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 02 Dec 2009 11:45:30 -0500

That's what I am saying.  It looks like an ITR could get locked to 
rloc.1, and therefore never resolve to rloc.2.  (I first noticed this 
problem relative to the mobility ideas.)

Yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 02 Dec 2009 11:48:41 -0500

To elaborate on my last answer, using some numbers,
you can not have a mapping of the form
1.2/16 -> rloc.1
1.2.3/24 ->rloc.2
If an ITR first looks up 1.2.6.9, it gets the first entry.
If it is then handed a packet to EID 1.2.3.7, it will perfectly happily 
use the entry it has, and not ask for a new one.  Therefore it will 
never hear about the mapping to rloc.2.

Yours,
Joel

---

From: David Meyer <[email-masked]>
Date: Wed, 2 Dec 2009 08:52:00 -0800

> problem relative to the mobility ideas.)

	Ok, gotcha. IIRC this was the case in which we discussed
	whether EIDs for mobile nodes could come from an
	enterprises EID block.
	
	Dave

---

From: David Meyer <[email-masked]>
Date: Wed, 2 Dec 2009 08:53:04 -0800

> never hear about the mapping to rloc.2.

	Yep. Thnx for clarifying.

	Dave

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 2 Dec 2009 12:06:13 -0500

On Dec 2, 2009, at 11:45 AM, Joel M. Halpern wrote:

> rloc.1, and therefore never resolve to rloc.2.  (I first noticed  
> this problem relative to the mobility ideas.)

I brought up this issue with Dino and Darrel (and maybe Dave?) in  
HIroshima, and they seemed to indicate that this you wouldn't use this  

>>  where (n < m) && (rloc.1 != rloc.2)

Instead, you would do this:

	a.b.c.d/n -> rloc.1 (weight = 100), rloc.2 (weight = 0)
         a.b.c.d/m -> rloc.1 (weight = 0), rloc.2 (weight = 100)

At the time, I thought that would solve the problem, but now I must  
have missed something about the explanation, as it is still true that  
if the ITR has an entry for the shorter prefix, it will never do a  
mapping lookup for the longer prefix, so it will never see the second  
answer with the different weights...

My use case for this type of configuration was a company that has a  
large HQ and various small satellite offices, perhaps connected by  
leased lines or other private links, and all directly connected to the  
Internet.  They would like Internet traffic for the satellite offices  
to go directly to/from those offices, but to fall back to going  
through the HQ if one of the satellite offices does not have direct  
Internet connectivity.  However, they would not like traffic to/from  
HQ to flow through the satellite offices if/when HQ has Internet  
connectivity problems.

So, Dino and Darrel, I'm sorry but I seem to have forgotten or  
misunderstood some part of your explanation.  Could you explain how  
this would work again?

Margaret

>
> Yours,
> Joel
>
> David Meyer wrote:
>> 	Joel,
>>> I think that there is a subtle difference between the IP situation  
>>> for  nested prefixes and the LISP EID situation.
>>>
>>> As I read things, and I may be confused, you can not have two sets  
>>> of  responses that map EID blocks to RLOCs, where one response is  
>>> for a  short prefix, and one is for a long prefix within that,  
>>> pointing to  different RLOCs.  If you ever do that, I think there  
>>> is significant  misdirection potential.
>>> SUppose that an ITR first asks for a destination EID that is  
>>> inside the  short prefix, and outside the long one.  The ITR gets  
>>> an answer.
>>> If the ITR then gets a packet with a destination EID from the  
>>> long  prefix, there will already be a proper match in the table.   
>>> It will not  issue a new resolution request.  (And assuming both  
>>> sets of traffic  continue, it is quite likely that the short  
>>> prefix will be refreshed  consistently, and the long prefix never  
>>> discovered.
>>> prefixes, I think that an EID block that actually resolves to  
>>> RLOCs can  never also delegate a portion of that space to a  
>>> separate entity, with  distinct RLOCs.
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: David Meyer <[email-masked]>
Date: Wed, 2 Dec 2009 09:26:56 -0800

On Wed, Dec 02, 2009 at 12:06:13PM -0500, Margaret Wasserman wrote:
> At the time, I thought that would solve the problem, but now I must have 
> missed something about the explanation, as it is still true that if the 
> ITR has an entry for the shorter prefix, it will never do a mapping 
> lookup for the longer prefix, so it will never see the second answer with 
> the different weights...
>
> Internet.  They would like Internet traffic for the satellite offices to 
> go directly to/from those offices, but to fall back to going through the 
> HQ if one of the satellite offices does not have direct Internet 
> connectivity.  However, they would not like traffic to/from HQ to flow 
> through the satellite offices if/when HQ has Internet connectivity 
> problems.
>
> misunderstood some part of your explanation.  Could you explain how this 
> would work again?

	There are basically three mechanisms we've talked about
	to handle this case (and the case Joel pointed out):

	- An xTR that changes its policy [0] can send SMRs
	- An ITR can use RLOC-probing to learn new mappings 
	- or the TTL on the cache entry can time out and the ITR
	  the ITR will send a map-request on the next packet

	Dave

[0]	Where "policy" could be EID prefix length, RLOC set, or 
        weights and priorites.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 02 Dec 2009 12:44:48 -0500

Sorry, I do not see how any of the three mechanisms apply to the cases 
under discussion.
1) We are not discussing a change of policy
2) Since the ITR is not going to probe for all the EIDs in a block, one 
would expect the odds to favor it probing, and maintaining, the short 
prefix, and never learning about the long prefix.
3) There is no current reason for the ITR to send a map request.  If we 
want to change the semantics so that eveyr distinct EID needs a mpa 
request, but prefixes can be used pending the resolution, we could do 
that.  But that is not what the document says currently?

Up until Margaret brought up her case, I had simply assumed that the 
right answer was never to use nested EID blocks for actual allocations.

Given that an EID corresponds to a site, would it be simpler for the 
multi-site organization to use an EID per site?  the HQ can offer a 
lower priority RLOC for each of the remote site EIDs, and the remote 
sites can offer a lower priority RLOC for the HQ EID.  If we don't try 
to take them all out of the same block, it seems to work fine.  (Or if 
we use one block, but disagreggate it for advertisement.)

Yours,
Joel

David Meyer wrote:
...

---

From: David Meyer <[email-masked]>
Date: Wed, 2 Dec 2009 10:19:18 -0800

> prefix, and never learning about the long prefix.

	Let's see: The probe is a map-request (p-bit) that is
	sent to an RLOC. Since a site's ETRs are consistently
	configured, probing in any of them will result in a
	map-reply that contains all of the matching EID prefixes
	and their associated data.

	The here point being that the EID prefix length in a
	map-cache doesn't really matter for these purposes. Of
	course there is a problem if all of a site's RLOC change;
	this is covered in the LISP-MN draft.

> that.  But that is not what the document says currently?

	If its an xTR and it changes its EID prefix length, RLOC
	set, etc, it will want to notify its correspondents. Note
	the use of xTR v. ITR.  

> multi-site organization to use an EID per site?  

	It could.

> the HQ can offer a  

	That can also work.

	Dave

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 02 Dec 2009 13:51:40 -0500

I think that this implies that the initial response (and all probe based 
response) would have to include the EID block for each and every site in 
the enterprise.
I am reminded many, many, years ago when Fred Baker was trying to 
install the first very large VPN, and folks first saw just how big a 
retail giant and each of its stores could be.
Please, we do not want to require that the map reply contain the EID for 
each and every site.

Given that LISP names sites, not machines, it seems to me that the 
answer is that every site has an EID block.  That trying to treat these 
as related is simply asking for trouble.  The fact that if a machine 
moves from a remote site to the home site it has to change EIDs is a 
consequence of the LISP design (unless one has mobility.  That is why 
you worked out how to add mobility...)

Trying to use RLOC longest match semantics and RLOC overlapping prefix 
semantics on cached mapping entries seems to me to be asking for trouble.

If other folks really want to do this, then it seems to me that we are 
going to have to write up very clearly how it works, and explain the 
implications of our choice.  As far as I can tell, the text as currently 
written is not clear about whether this is permitted, or how it is 
supposed to work.

(For clarity, all of the above, and all of the preceding discussion, has 
been purely personal opinion.  Having just had a hat change, I am not 
yet in the proper habits of being clear about the difference.
Also, having just changed roles, it is probably more important than 
usual that I be clear about the difference.  Apologies if I confused 
anyone.)

Yours,
Joel

David Meyer wrote:
...
...

---

From: "Darrel Lewis (darlewis)" <[email-masked]>
Date: Wed, 2 Dec 2009 11:01:47 -0800

> you worked out how to add mobility...)

LISP gives you the flexibility to do either.  If you have less than 32
sites (for LSB issues), and want to have overlapping prefixes, you can
consistantly configure your ETRs.  

If you have more than 32 sites, or any other reason, then they should be
stored and used (as you suggest) as individual prefixes, with no
covering aggregate.

-Darrel

---

From: Xu Xiaohu <[email-masked]>
Date: Thu, 03 Dec 2009 10:28:19 +0800

Hi all,

It seems that the same issue had even been discussed two years ago. See
http://www.ops.ietf.org/lists/rrg/2007/msg00429.html

Another related issue was also discussed. See
http://www.ietf.org/mail-archive/web/ram/current/msg01827.html

Xiaohu

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表 Joel M.
> Halpern
> 发送时间: 2009年12月3日 0:49
> 收件人: David Meyer
> 抄送: Charrie Sun; lisp
> 主题: Re: [lisp] Fwd: Re: Re: A mapping system design-- specification of
> LISP+ALT
>

---

From: Charrie Sun <[email-masked]>
Date: Thu, 3 Dec 2009 10:45:06 +0800

---------- Forwarded message ----------
From: Charrie Sun <[email-masked]>
Date: 2009/12/3
Subject: Re: [lisp] Fwd: Re: Re: A mapping system design-- specification of
LISP+ALT
To: "Joel M. Halpern" <[email-masked]>

Hi all,

2009/12/3 Joel M. Halpern <[email-masked]>

Sorry, I do not see how any of the three mechanisms apply to the cases under
> discussion.
> want to change the semantics so that eveyr distinct EID needs a mpa request,
> but prefixes can be used pending the resolution, we could do that.  But that
> is not what the document says currently?
>
> Up until Margaret brought up her case, I had simply assumed that the right
> answer was never to use nested EID blocks for actual allocations.
>
> multi-site organization to use an EID per site?  the HQ can offer a lower
> priority RLOC for each of the remote site EIDs, and the remote sites can
> offer a lower priority RLOC for the HQ EID.  If we don't try to take them
> all out of the same block, it seems to work fine.  (Or if we use one block,
> but disagreggate it for advertisement.)

I didn't quite catch it, could you tell me how would the different priority
RLOC for each site work to solve the EID-prefix nesting problem?

>>        - An ITR can use RLOC-probing to learn new mappings        - or the
>> TTL on the cache entry can time out and the ITR

David Meyer wrote:
       Since the ALT is just BGP, we can build as many (or as few) layers

Since ALT is just BGP, and we would handle things such as prefix
deaggregation for EIDs just like current IP prefixes, how can we guarantee
that LISP+ALT is scalable?
    Besides, Dan Jen and Lixia Zhang has a draft discussing the
difference between mapping to support mobility and mapping to support
scalablity[0]. I quoted a section which i approved:
   "In mobility solutions packets are forwarded to the location where
mapping information is stored. In routing scalability solutions mapping
information needs to be available at packet entry points to the network.
Attempts to use one mapping system for both purposes can lead to high
overhead in either mapping information distribution or otherwise mapping
information discovery, as well as stale mapping information being used for
data forwarding."
    Isn't LISP designed for scalability problems?

[0] "Understand Mapping", draft-jen-mapping-00.txt

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 02 Dec 2009 22:12:50 -0500

Instead of using overlapping (or nested) prefixes, you use separate 
prefixes.

Yes, the company still gets a single allocation.  But they don't create 
a mapping entry for that single allocation.  Instead, they disagregate 
it into whatever sizes they need.  (Remember that EID usage is MUCH more 
efficient than IP address usage, since you don't have to worry about 
topology within the site, so this is pretty easy.)
Then each site registers its assigned EID prefix, with its RLOCs, and 
with a good preference value so that these are the natural techniques.
Some sites have backup links to HQ.  Those sites also register the HQ 
EID block, with the sites RLOC, but with a less preferred priority.  If 
HQ RLOCs all go away, the other sites can be used as a path.
Similarly, if HQ is backing up access to some sites, it can advertise 
those EID blocks, with HQs RLOCs, with a less preferred priority than 
the sites advertise for themselves.  If the site RLOCs go down, HQ will 
be used to reach those sites.

But in the mapping system, there are no overlapping entries for mapping 
EID blocks to RLOCs or EID blocks to ETRs.  shorter prefixes are only 
used to manage allocation.  (The site would be likely to run its own ALT 
node(s) for this kind of thing, since otherwise it has a lot of 
configuration to hand to whomever is running the disaggregated ALT 
entries.  But it does not have to run its own if it really does not want 
to.)

Yours,
Joel

Charrie Sun wrote:
> From: *Charrie Sun* <[email-masked] <mailto:[email-masked]>>
> Date: 2009/12/3
> Subject: Re: [lisp] Fwd: Re: Re: A mapping system design-- specification 
> of LISP+ALT
> To: "Joel M. Halpern" <[email-masked] <mailto:[email-masked]>>
> 
> 
> Hi all,
> 
> 2009/12/3 Joel M. Halpern <[email-masked] 
> <mailto:[email-masked]>>
> 
>     Sorry, I do not see how any of the three mechanisms apply to the
>     cases under discussion.
>     2) Since the ITR is not going to probe for all the EIDs in a block,
>     one would expect the odds to favor it probing, and maintaining, the
>     short prefix, and never learning about the long prefix.
>     3) There is no current reason for the ITR to send a map request.  If
>     we want to change the semantics so that eveyr distinct EID needs a
>     mpa request, but prefixes can be used pending the resolution, we
>     could do that.  But that is not what the document says currently?
> 
>     sites can offer a lower priority RLOC for the HQ EID.  If we don't
>     try to take them all out of the same block, it seems to work fine.
>      (Or if we use one block, but disagreggate it for advertisement.) 
> 
>  
> I didn't quite catch it, could you tell me how would the different 
> priority RLOC for each site work to solve the EID-prefix nesting problem?
>  
> 
> 
> 
>     Yours,
>     Joel
> 
>     David Meyer wrote:
>     ...
> 
> 
> deaggregation for EIDs just like current IP prefixes, how can we 
> guarantee that LISP+ALT is scalable?
>    " In mobility solutions packets are forwarded to the location where 
> information discovery, as well as stale mapping information being used 
> for data forwarding ."
> ------------------------------------------------------------------------
>

---

From: Charrie Sun <[email-masked]>
Date: Thu, 3 Dec 2009 12:24:30 +0800

Got it. Thnks. While, does it mean that either the site run its own ALT
nodes, where the deaggreation of EID blocks becomes local policy, or the
outside world will see deaggreated EID blocks which will flood the mapping
table?

> Yes, the company still gets a single allocation.  But they don't create a
> mapping entry for that single allocation.  Instead, they disagregate it into
> whatever sizes they need.  (Remember that EID usage is MUCH more efficient
> than IP address usage, since you don't have to worry about topology within
> the site, so this is pretty easy.)
> Then each site registers its assigned EID prefix, with its RLOCs, and with
> a good preference value so that these are the natural techniques.
> Some sites have backup links to HQ.  Those sites also register the HQ EID
> block, with the sites RLOC, but with a less preferred priority.  If HQ RLOCs
> all go away, the other sites can be used as a path.
> Similarly, if HQ is backing up access to some sites, it can advertise those
> EID blocks, with HQs RLOCs, with a less preferred priority than the sites
> advertise for themselves.  If the site RLOCs go down, HQ will be used to
> reach those sites.
>
> But in the mapping system, there are no overlapping entries for mapping EID
> blocks to RLOCs or EID blocks to ETRs.  shorter prefixes are only used to
> manage allocation.  (The site would be likely to run its own ALT node(s) for
> this kind of thing, since otherwise it has a lot of configuration to hand to
> whomever is running the disaggregated ALT entries.  But it does not have to
> run its own if it really does not want to.)
>
> Yours,
> Joel
>
> Charrie Sun wrote:
>
>>
>>
>>  2009/12/3 Joel M. Halpern <[email-masked] <mailto:
>> [email-masked]>>
>>
>>    Besides, Dan Jen and Lixia Zhang has a draft discussing the difference
>> between mapping to support mobility and mapping to support scalablity[0]. I
>> quoted a section which i approved:
>> data forwarding ."

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 02 Dec 2009 23:29:34 -0500

Because of the ALT structure, the disagregation disappears one level up 
the ALT tree.  So it does not matter in terms of the impact on the rest 
of the system whether the business runes its own ALT node, or they just 
have their ALT delegation parent node hold the details.
Yours,
Joel

Charrie Sun wrote:
> outside world will see deaggreated EID blocks which will flood the 
> mapping table?
> 
>  
> 2009/12/3 Joel M. Halpern <[email-masked] <mailto:[email-masked]>>
> 
>     Yes, the company still gets a single allocation.  But they don't
>     create a mapping entry for that single allocation.  Instead, they
>     disagregate it into whatever sizes they need.  (Remember that EID
>     usage is MUCH more efficient than IP address usage, since you don't
>     have to worry about topology within the site, so this is pretty easy.)
>     Then each site registers its assigned EID prefix, with its RLOCs,
>     and with a good preference value so that these are the natural
>     techniques.
>     Some sites have backup links to HQ.  Those sites also register the
>     HQ EID block, with the sites RLOC, but with a less preferred
>     priority.  If HQ RLOCs all go away, the other sites can be used as a
>     path.
>     Similarly, if HQ is backing up access to some sites, it can
>     advertise those EID blocks, with HQs RLOCs, with a less preferred
>     priority than the sites advertise for themselves.  If the site RLOCs
>     go down, HQ will be used to reach those sites.
> 
>     But in the mapping system, there are no overlapping entries for
>     mapping EID blocks to RLOCs or EID blocks to ETRs.  shorter prefixes
>     are only used to manage allocation.  (The site would be likely to
>     run its own ALT node(s) for this kind of thing, since otherwise it
>     has a lot of configuration to hand to whomever is running the
>     disaggregated ALT entries.  But it does not have to run its own if
>     it really does not want to.)
> 
>     Yours,
>     Joel
> 
>     Charrie Sun wrote:
> 
> 
> 
>         From: *Charrie Sun* <[email-masked]
>         <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>>
>         Date: 2009/12/3
>         Subject: Re: [lisp] Fwd: Re: Re: A mapping system design--
>         specification of LISP+ALT
>         To: "Joel M. Halpern" <[email-masked]
>         <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>>
> 
> 
>         Hi all,
> 
>         <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>>
> 
>          I didn't quite catch it, could you tell me how would the
>         different priority RLOC for each site work to solve the
>         EID-prefix nesting problem?
>          
> 
> 
>            Yours,
>            Joel
> 
>            David Meyer wrote:
>            ...
> 
> 
>                       - An ITR can use RLOC-probing to learn new
>         mappings               - or the TTL on the cache entry can time
>         out and the ITR
>          Since ALT is just BGP, and we would handle things such as
>         prefix deaggregation for EIDs just like current IP prefixes, how
>         can we guarantee that LISP+ALT is scalable?
>         difference between mapping to support mobility and mapping to
>         support scalablity[0]. I quoted a section which i approved:
>           " In mobility solutions packets are forwarded to the location
>         where mapping information is stored. In routing scalability
>         solutions mapping information needs to be available at packet
>         entry points to the network. Attempts to use one mapping system
>         for both purposes can lead to high overhead in either mapping
>         information distribution or otherwise mapping information
>         discovery, as well as stale mapping information being used for
>         data forwarding ."
>         [email-masked] <mailto:[email-masked]>