Subject: Re: [RRG] LISP-ALT (was: LISP-EMACS & LISP-ALT)

From: Scott Brim <[email-masked]>
Date: Fri, 16 Nov 2007 13:45:51 -0500

You discuss ALT and EMACS in one message.  I'm going to split them up
and deal with EMACS in a separate reply.

Excerpts from Robin Whittle on Fri, Nov 16, 2007 11:40:48PM +1100:
> I understand that LISP-ALT (AKA LAT = LISP Alternate Topology):
> 
>   http://tools.ietf.org/html/draft-fuller-lisp-alt-01
> 
> is a short-term (for deployment, or just for research) alternative
> to LISP-CONS and LISP-NERD.

LISP-ALT can be a first step to something else but it may be all we
ever need.

> A new set of "LISP-ALT routers" is created, forming an overlay
> network using GRE.  These LISP-ALT routers form a network using the
> same IPv4 address space, but this is a different, separate network
> from the global Internet.  This network runs its own BGP system with

It is not a separate network, just tunneled traffic.  The
GRE-encapsulated packets are carried over global Internet, just like
any other IP packets.  What you have is a "virtual topology", a set of
tunnel relationships between cooperating nodes.  Similarly, this mail
message is being "routed" by a "network" of SMTP "routers", connected
over the Internet.

> a separate ASN number space, completely unrelated to the current BGP
> and ASN numbering systems.  The connectivity patterns of these
> LISP-ALT routers is somehow determined by address structure, rather
> than physical proximity as it is in the current Internet.

Did you understand that part?  If you are responsible for 192.0.2.0/24
you would say so to one or more parent nodes responsible for an
including prefix, for example 192.0.0.0/18.

> ETRs are the authoritative source of mapping information.  (I don't
> understand how this would work, especially with respect to
> redundancy and the fact that ETRs may be cut off from the rest of
> the Net.)

Are you saying that an ETR might have a connection to the ALT
infrastructure but be cut off from ordinary Internet packet flows?
SThe ALT flows are just Internet packet flows, so if you have one you
have the other -- there's fate sharing.  I suppose there could be a
situation where an ETR had a physical interface exclusively for ALT
traffic, and all of its other core-facing interfaces were broken.  

> There is also something in 5.2 (3.) about LISP-ALT routers acting as
> a "proxy-ITR to "support non-LISP sites".  I understand this is to
> handle packets sent from networks without any LISP upgrades -
> specifically, without an ITR.  As I have written recently (mssg
> 529), I don't see how any such scheme can work unless the prefixes
> in which EIDs are found are advertised in ordinary BGP - which is at
> odds with the original conception of LISP.

There are a number of possible "proxy ITR" plans.  I think in the
context you are talking about that yes, EIDs would be advertised in
"ordinary" BGP, but they can be aggregated (reducing BGP state,
possibly dramatically) and stable (reducing churn rate).  In any case
this is not specific to ALT.

> There are so many options within this proposal, and so few examples,
> I can't clearly understand it.  However, I see there is no mention
> of how to cope with MTU, PMTUD etc. problems and that there is no
> discussion of why anyone would want to build this network.

Business motivation is a significant issue for all of the RRG
scenarios.  My attitude towards this is that first we figure out a
really good technical approach for the evolution of the Internet.
Once we know where we want to go, then we think about whether it's
feasible to motivate people to move that way, given that Internet
operations is primarily based on profit.  

> As with the other LISP proposals (unless they adopt an "anycast ITRs
> in the core" approach, as perhaps they might - see message 529) it
> is not obvious how packets from non-upgraded networks can get to a
> "proxy-ITR" so they can be tunneled to the correct ETR.

BGP.  See above.

> Since the number of separate micronets (see mssgs 533 & 535) and
> therefore ETRs is likely to grow to vastly higher than the ~240k
> prefixes of the current BGP system, it is not clear to me why BGP is
> a good choice to cope with this larger number in the LISP-ALT
> overlay network.  (I understand this new network has some
> simplifications which might help.)

Mainline BGP carries announcements of prefixes with paths to get
there.  Routes are propagated following physical topology.  The ALT
infrastructure carries announcements of prefixes with a promise that
it can get you to a node that can give you an EID-RLOC mapping.
Routes are not constrained to propagate following physical topology,
so prefixes can be aggressively aggregated.  Even if the EID space
fragments (and I think it will too), the announcements carried over
the ALT infrastructure will still aggregate way down, to the same
number at the top levels.  For example, if I have 192.0.2.0/24, as
above, that is connected to a parent node responsible for
192.0.0.0/18, and I split that /24 into two /25s, both of them will
still connect through the same parent (or one below it), and the split
will not be visible above that level.

> Overall, I think the LISP proposals (not so much NERD) are hard to
> understand, with terse, conceptual descriptions with many options
> and not enough examples.   

And your feedback will help make future versions clearer.  Thank you.

> This is different from having a variety of principles which can be
> combined in various combinations, as in LISP, to create
> fundamentally different architectures.

Actually I'll disagree here.  All of the scenarios proposed consist of
multiple functional components.  For example, it is admirable that we
(all) have been able to separate data plane and control plane so that
we can mix and match.  This kind of flexibility is important.  You say
you can produce different "architectures" by combining them
differently.  That's true, and that's why names and packaging are  not
as important as the functional components themselves.  It is good that
we can mix and match -- that gives us power and freedom in creating
the future Internet.

> I am surprised that Ivip remains the only proposal which aims for
> fast distribution of mapping data to query servers and ITRDs all
> over the world.  Bandwidth, RAM and CPU power are cheap and getting
> cheaper.  So I don't think the future architecture of the Net should
> be constrained by over-complex architectures which have only modest
> aims regarding mobility and rapid delivery of packets - as if the
> designers are scared by the apparent impossibility of doing what
> Ivip aims to achieve.

I suspect you are wrong that you are the only one distributing mapping
data to query servers.  To start with, NERD does, and CONS does via
caching.  There are tradeoffs with pushing your mapping information.
How do you deal with policy differentiation?  How do you get one site
to use one RLOC set, and a different site to use a different one,
without revealing your policies to the world?  One of the things I
like about ALT is that it supports policy differentiation while still
keeping mapping information tied to operational reality.

> I think it will be practical to create a fresh architecture and a
> fancy, fast, mapping data distribution system 

Please propose something.

> I think a lot of the options and complications of LISP are attempts
> to fix problems which are inherent in its conception, including:
> 
> 1 - An overly ambitious goal of removing BPG advertisements, when
>     I think it would be fine to keep a lid on the current number, or
>     accept a somewhat higher number, provided we can serve the needs
>     of many more end-user networks.

All of the scenarios keep BGP around, but just reduce the rate*state
it suffers.  There is no goal of removing BGP advertisements
completely.  

> 2 - An overly cautious approach to the problem of distributing
>     mapping information around the world - either with CONS,
>     which does not attempt it, or NERD which does it very slowly.
>     (TRRP generally does not attempt it and eFIT-APT intends to
>     do it very slowly indeed, over the current BPG network - which
>     is not necessarily a consenting partner . . . )

Please run a simulation, or at least provide an analysis with numbers.
I hope others will too.

> 3 - Therefore, LISP mapping distribution is too slow to allow
>     mapping database changes to be the means of implementing
>     multihoming service restoration.  This leads to the requirement
>     for more complex mapping information, ITRs having to make their
>     own decisions about which of various ETRs is the best one to
>     tunnel packets to etc.

Multihoming service restoration?  To me this means either (1)
continuity of higher layer sessions, for example RTP, or (2) switching
from one ETR to a different one.  Session continuity happens at a
higher layer.  The IP layer service is constant and doesn't need to be
restored (that's why you're multihomed).  ETR switching is handled in
LISP using information in headers and Map-Replies.   

Scott

--
to unsubscribe send a message to [email-masked] with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg

---

From: Robin Whittle <[email-masked]>
Date: Sat, 17 Nov 2007 14:16:41 +1100

Hi Scott,

Thanks for your response.

I understand that LISP-ALT is not a physically separate network, but
 that it uses tunnels through the current network to create a
structurally independent network, with its own use of address space,
its own BGP system and its own new use of BPG's ASNs.

I understand that the connectivity between the LISP-ALT routers is
structured according to the address hierarchy:

> Did you understand that part?  If you are responsible for
> 192.0.2.0/24 you would say so to one or more parent nodes
> responsible for an including prefix, for example 192.0.0.0/18.

This makes me think that the connections are not structured
according to geography.  The Devil's Advocate perspective on this is
that the links between routers could be, on average, rather
geographically long compared to the links between ordinary BGP
routers.  This means lots of routers per tunnel, with consequent
increases in overall latency and risk of packet loss.

>> ETRs are the authoritative source of mapping information.  (I
>> don't understand how this would work, especially with respect
>> to redundancy and the fact that ETRs may be cut off from the
>> rest of the Net.)
> 
> infrastructure but be cut off from ordinary Internet packet
> flows? The ALT flows are just Internet packet flows, so if you
> have one you have the other -- there's fate sharing.  I suppose
> there could be a situation where an ETR had a physical interface
> exclusively for ALT traffic, and all of its other core-facing
> interfaces were broken.

I was questioning the whole LISP approach of making ETRs the
authoritative source of mapping information.  I write more on this
in my next message on LISP-EMACS.

>> There is also something in 5.2 (3.) about LISP-ALT routers
>> acting as a "proxy-ITR to "support non-LISP sites".  I
>> understand this is to handle packets sent from networks without
>> any LISP upgrades - specifically, without an ITR.  As I have
>> written recently (mssg 529), I don't see how any such scheme
>> can work unless the prefixes in which EIDs are found are
>> advertised in ordinary BGP - which is at odds with the original
>> conception of LISP.
> 
>  context you are talking about that yes, EIDs would be advertised
> in "ordinary" BGP, but they can be aggregated (reducing BGP
> state, possibly dramatically) and stable (reducing churn rate).
> In any case this is not specific to ALT.

I can't understand clearly what you are proposing - can you give a
concrete, detailed, example?  I write more about this in my next
message.

>> There are so many options within this proposal, and so few
>> examples, I can't clearly understand it.  However, I see there
>> is no mention of how to cope with MTU, PMTUD etc. problems and
>> that there is no discussion of why anyone would want to build
>> this network.
> 
> scenarios.  My attitude towards this is that first we figure out
> a really good technical approach for the evolution of the
> Internet. Once we know where we want to go, then we think about
> whether it's feasible to motivate people to move that way, given
> that Internet operations is primarily based on profit.

I agree we need to be somewhat bold - but not completely unrealistic
- in these early days of designing a new architecture.  That is why
I boldly went for a simpler system based on the assumption that we
could achieve the challenging task of pushing mapping data out
around the Net within a few seconds.  This seems a lot easier to me
than than trying, as you do with LISP, to add complexity to a
pull-based system in order to achieve acceptable performance.

>> Since the number of separate micronets (see mssgs 533 & 535)
>> and therefore ETRs is likely to grow to vastly higher than the
>> ~240k prefixes of the current BGP system, it is not clear to me
>> why BGP is a good choice to cope with this larger number in the
>> LISP-ALT overlay network.  (I understand this new network has
>> some simplifications which might help.)
> 
> there.  Routes are propagated following physical topology.  The
> ALT infrastructure carries announcements of prefixes with a
> promise that it can get you to a node that can give you an
> EID-RLOC mapping. Routes are not constrained to propagate
> following physical topology, so prefixes can be aggressively
> aggregated.  Even if the EID space fragments (and I think it will
> too), the announcements carried over the ALT infrastructure will
> still aggregate way down, to the same number at the top levels.
> For example, if I have 192.0.2.0/24, as above, that is connected
> to a parent node responsible for 192.0.0.0/18, and I split that
> /24 into two /25s, both of them will still connect through the
> same parent (or one below it), and the split will not be visible
> above that level.

Yes, I understand that the logical structure of the LISP-ALT network
will be tied directly to the tree-like splitting of the address
space into the micronets of each end-user network.  This is
conceptually simpler than the BGP prefixes being advertised in a
geographically scattered fashion, with the geographically-structured
BGP network trickling this information through itself until every
router has what it needs to make a good enough forwarding decision
for each prefix.

However, based on my limited understanding of LISP-ALT, I still
think your new LISP-ALT routers are going to be scattered
geographically all over the Net, and that a logical link from the
LISP-ALT router in you example network 192.0.2.0/24 is probably not
going to be anywhere physically near the LISP-ALT router for
192.0.0.0/18.  So while logically, LISP-ALT would look like a
compact network, the physical distances of the links between routers
could be, on average, very long.  If you can give some more concrete
examples, this might correct the likely deficiencies in how I
imagine LISP-ALT would work.

>> Overall, I think the LISP proposals (not so much NERD) are hard
>> to understand, with terse, conceptual descriptions with many
>> options and not enough examples.
> 

OK.  I would be glad of similar attention to the Ivip ID.

If you believe it is fundamentally undesirable or impractical to
push mapping data out globally, aiming for a few seconds delay, to
ITRDs and QSDs all over the world, then I suppose you might think
Ivip is not worth considering.

However, Ivip doesn't enforce every ITR to be an ITRD.  There is
great flexibility - with local decisions about where to place
caching ITRCs, Query Servers (caching QSC and full database QSDs the
ITRCs need, and full database ITRDs.  So if the cost and
difficulties of pushing the data is high, Ivip can be deployed with
fewer, more centralised, ITRDs and QSDs.  I think this is more
locally flexible and more elegant than having to make a global
overlay network as you are proposing with LISP-ALT and LISP-EMACS.

>> This is different from having a variety of principles which can
>> be combined in various combinations, as in LISP, to create 
> Actually I'll disagree here.  All of the scenarios proposed
> consist of multiple functional components.  For example, it is
> admirable that we (all) have been able to separate data plane and
> control plane so that we can mix and match.  This kind of
> flexibility is important.  You say you can produce different
> "architectures" by combining them differently.  That's true, and
> that's why names and packaging are  not as important as the
> functional components themselves.  It is good that we can mix and
> match -- that gives us power and freedom in creating the future
> Internet.

OK - I can imagine that one could deploy a pure LISP-NERD system, a
pure LISP-CONS system etc. or some combination of the two.

Its just that if you can do LISP-NERD to some places, why can't you
also push the data (actually, each LISP-NERD requests the mapping
data files) to some Query Servers which are geographically close to
LISP-CONS' all caching ITRs?  Then, you don't need LISP-ALT or
LISP-EMACS.

eFIT-APT says "Push (slowly) all the mapping info to a Default
Mapper in every upgraded network".

Ivip says "Push (very quickly) the mapping info to ITRD and QSDs
which can be located as deep in ISP networks, or outside them, as
you like.  Then deploy as many ITRCs and ITFHs (in hosts) with
caching QSCs as makes sense in order to achieve the best trade-off
between cost of ITRs etc. query and push traffic, and more optimal
paths for the traffic packets.

LISP-CONS says "All ITRs are caching, so we need a global CAR-CDR
network to handle (and perhaps cache) mapping queries".

LISP-ALT says "All ITRs are caching, so we build a GRE overlay
network to handle mapping queries, and also (like eFIT-APT's Default
Mappers) send unmapped packets to something which will both tunnel
it to the correct ETR and send mapping information to the ITR".

LISP-NERD says "Caching ITRs have difficulties finding which ETR to
tunnel novel packets to, so it is better for all ITRs to get a full
(rather slow) feed of mapping data.

The 3 mechanisms:

  CONS - Global CAR-CDR network.

  ALT - Global GRE network with its own BGP system.

  NERD - ITRs downloading all mapping data periodically.

are not the sort of thing you would mix and match.

If it was practical to do NERD, then it would be easier to have
local Query Servers to handle those LISP ITRs which only cache -
rather than build a CONS or ALT global network.

I don't think you wouldn't build both the CONS and the ALT network.

Ivip is a single, flexible, architecture which could be deployed
with various mixes of full database and caching ITRs and Query
Servers.  There is not one part of Ivip which isn't globally needed
if another part is built.

>> I am surprised that Ivip remains the only proposal which aims
>> for fast distribution of mapping data to query servers and
>> ITRDs all over the world.  Bandwidth, RAM and CPU power are
>> cheap and getting cheaper.  So I don't think the future
>> architecture of the Net should be constrained by over-complex
>> architectures which have only modest aims regarding mobility
>> and rapid delivery of packets - as if the designers are scared
>> by the apparent impossibility of doing what Ivip aims to
>> achieve.
> 
> I suspect you are wrong that you are the only one distributing
> mapping data to query servers.  To start with, NERD does, and
> CONS does via caching.

My understanding of LISP-NERD is that all ITRs have a full copy of
the database, and that they all download (AKA "push") the mapping
updates themselves.  Full database Query Servers are only needed for
handling queries from caching ITRs, and from any caching Query Servers.

When I wrote: "fast distribution of mapping data to query servers
and ITRDs all over the world." I meant: "Fast pushing of the
complete mapping updates to all ITRDs and QSDs all over the world."

"Distribution" is more general, and perhaps could include the query
and cache system of LISP-CONS and LISP-ALT, but that is not what I
was trying to convey.

> There are tradeoffs with pushing your mapping information. How do
> you deal with policy differentiation?  How do you get one site to
> use one RLOC set, and a different site to use a different one, 
> without revealing your policies to the world?  One of the things
> I like about ALT is that it supports policy differentiation while
> still keeping mapping information tied to operational reality.

Ivip does not attempt to enable the end-user to specify one ETR for
some ITRs and another ETR for other ITRs.  If you want to load
balance a network 22.33.44.0/24 over four ITRs in four ISPs, Ivip
only enables you to do this by having some mix of this address space
mapped to each such ITR.  Ivip has arbitrary lengths of address
space for micronets, so you can specify a different ETR for every IP
address if you like, or have micronets such as:

  22.33.44.0    ETR1   Micronet length 1
  22.33.44.1    ETR2 } Micronet length 2
  22.33.44.2    ETR2 }
  22.33.44.3    ETR3   Micronet length 1
  22.33.44.4    ETR4 } Micronet length 5
  22.33.44.5    ETR4 }
  22.33.44.6    ETR4 }
  22.33.44.7    ETR4 }
  22.33.44.8    ETR4 }

This is not the most elaborate form of load balancing - so other
ITR-ETR schemes may be superior in this respect.  However it is nice
and simple.

I would think that an end-user network of the sort which would have
LISP-EID space or Ivip-mapped address space wouldn't be too fussed
about which other ISPs networks their packets arrived by en-route to
each ETR.  They will be vitally interested in which ETR the packets
go to, but I would have thought "policy" was something the ISPs were
interested in, and that they would continue to use current BGP
arrangements to achieve this.

Can you give an example of when it would be desirable for an
end-user to give out one ETR or set of ETRs for some ITRs to use and
another set for other ITRs?  How would you do this with LISP-CONS,
LISP-ALT or LISP-NERD?  I don't recall mention of this in the LISP IDs.

>> I think it will be practical to create a fresh architecture and
>> a fancy, fast, mapping data distribution system
> 

I have.  The overall architecture is described here:

  http://tools.ietf.org/html/draft-whittle-ivip-arch-00#section-7
  http://tools.ietf.org/html/draft-whittle-ivip-arch-00#section-8

I am working on a more secure and robust system than the simple UDP
packet approach I have in the ID.

>> I think a lot of the options and complications of LISP are
>> attempts to fix problems which are inherent in its conception,
>> including:
>> 
>> 1 - An overly ambitious goal of removing BPG advertisements,
>> when I think it would be fine to keep a lid on the current
>> number, or accept a somewhat higher number, provided we can
>> serve the needs of many more end-user networks.
> 
> All of the scenarios keep BGP around, but just reduce the
> rate*state it suffers.  There is no goal of removing BGP
> advertisements completely.

OK - I got the impression from Dino that he wanted, ideally,
initially at least, to have the main BGP system have no
advertisements for any prefixes which contain EID space.

>> mapping information around the world - either with CONS, which
>> does not attempt it, or NERD which does it very slowly. (TRRP
>> generally does not attempt it and eFIT-APT intends to do it
>> very slowly indeed, over the current BPG network - which is not
>> necessarily a consenting partner . . . )
> 
> Please run a simulation, or at least provide an analysis with
> numbers. I hope others will too.

It is early days yet.

I figure that we can build a robust, fast, reliable, Replicator
system more easily than trying to get a global CAR-CDR or LISP-ALT
network running with acceptable reliably and speed.

>>  for more complex mapping information, ITRs having to make
>> their own decisions about which of various ETRs is the best one
>> to tunnel packets to etc.
> 
> continuity of higher layer sessions, for example RTP, or (2)
> switching from one ETR to a different one.  Session continuity
> happens at a higher layer.  The IP layer service is constant and
> doesn't need to be restored (that's why you're multihomed).  ETR
> switching is handled in LISP using information in headers and
> Map-Replies.

I mean (2).

LISP and eFIT-APT (I am not sure about TRRP) involve a complex body
of mapping data, giving the ITR multiple ETRs to choose between -
with each ITR having to do its own detective work to figure out
which ETR is both reachable and has connectivity to the destination
host.

Ivip mapping data is a single ETR, which is changed by some external
system, of the end-user's choice, which decides how best to
multihome the end-user's network, and sends the appropriate mapping
updates (perhaps through some intermediary) to the RUAS (Root Update
Authorisation Server) where it gets Replicated out to the world's
ITRDs and QSDs within a few seconds.  QSDs can push the changes to
ITRCs and caching Query Servers which recently queried the mapping
for any address affected by the update.

 - Robin

---

From: "Tom Petch" <[email-masked]>
Date: Mon, 26 Nov 2007 09:14:51 +0100

----- Original Message -----
From: "Scott Brim" <[email-masked]>
To: "Robin Whittle" <[email-masked]>
Cc: "Routing Research Group list" <[email-masked]>
Sent: Friday, November 16, 2007 7:45 PM
Subject: Re: [RRG] LISP-ALT (was: LISP-EMACS & LISP-ALT)

<snip>
> including prefix, for example 192.0.0.0/18.
<snip>
> And your feedback will help make future versions clearer.  Thank you.

I too struggle to understand these proposals.  I find the best approach is to
wait until there is a reply to Robin's questions, when things usually become
clearer:-)  Thus no, I did not understand responsibility for prefixes from the
references to 'a hierarchy which matches the EID prefix allocation' or to 'in a
tree-like fashion (with some meshiness), both with redundancy' if indeed that is
what they mean.  Yet your sentence above conveys the idea clearly and concisely;
worth deferring the reading of the I-D for.

Or look at s.3  ' LISP-ALT operates on two name spaces ' yes, which?  name space
( or namespace ) does not occur again.  Ditto 'introduces a new network element,
the EID Prefix Aggregators (see below)' well yes the term is below in 'Generic
Routing Encapsulation (GRE) tunnels between EID       Prefix Aggregators' but
only there - it is never defined, never explained.

It seems pertinent that [LISP] is an informative reference for this I-D and so
not necessary in order to understand it; presumably because ' Section 4 outlines
the basic LISP 1.5 model.' and so no more information on LISP is thought
necessary.

I struggle partly because of the grammar, which is not quite the English grammar
I learnt at school so that I find myself emending the text, but more because of
an absence of the big picture with the focus instead on a mass of incoherent (to
me) detail.  Ah well, as long as Robin keeps asking the questions, I'll be ok.

Two current questions.  What namespace are the GRE endpoint addresses in?  The
current IPv4 32 bit namespace or some other (in the way in which eg AS numbers,
OSPF router ids, OSPF area numbers are also 32 bit numbers but in different
namespaces).

And the description of BGP 'advertising summary prefixes to the LISP-ALT routers
logically "above" them'.  Does BGP also advertise downwards and sideways, as in
the BGP of the current Internet, so that everyone has a consistent view of the
topology, or are there unexplained mechanisms to restrict advertising?

Frustratedly,

Tom Petch

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 26 Nov 2007 09:20:21 -0800

Let me try to help make the designs more clear by replying to this  
email.

> I too struggle to understand these proposals.  I find the best  

We are trying to stay at a relatively high level and look for  
alternating models. We have some good options and some that probably  
won't get deployed.

I think we are at a point, where we can take each one to the next  
level of detail in both refining the spec details and doing some  
prototype code. We have done that for a couple of the proposals.

We will present at RRG Friday next week. Hopefully that will clear  
things up more.

> worth deferring the reading of the I-D for.

Simply put if a site in California and a site in New York each have an  
EID-prefix allocation out of the same power-of-2 block, those two  
blocks can be aggregated. You do that by having each site ITR connect  
to the same LISP-ALT router that does the aggregation. Since the  
topology is logical, we can connect the 2 aforementioned sites  
together based on their allocations, independent on what service  
provider they attach to for underlying connectivity.

> only there - it is never defined, never explained.

Namespace is a generic term I think people have felt comfortable with,  
so we continue to use it. The more precise name is "addressing  
domains", just like if you configured 2 VRFs in a router, each one  
would be in a different addressing domain. Meaning, that 10.0.0.1 in  
one VRF is not the same host as 10.0.0.1 in another VRF.

In LISP we have an EID addressing domain and a Locator addressing  
domain. They don't cross over to each other. And as you probably have  
figured out, the EID "maps" to a Locator. So the EID is used as the  
addressing domain within a site and the locator is used as the  
addressing domain outside of the site.

> me) detail.  Ah well, as long as Robin keeps asking the questions,  

Well I think all the authors are writing in "American", sorry.  ;-)

> Two current questions.  What namespace are the GRE endpoint  

The tunnel endpoints must use locator addresses or they cannot be  
realized by the underlying topology, the real physical topology.

> And the description of BGP 'advertising summary prefixes to the LISP- 

Where ever we mention prefixes in LISP-ALT, we mean EID-prefixes. We  
will go through the spec and make sure we fixed all places.

> topology, or are there unexplained mechanisms to restrict advertising?

BGP advertises in a peer-model like it does today. The peering is  
between these new boxes versus existing underlying BGP peering. It is  
an overlay, and to run BGP on the overlay where we treat each hop as  
an eBGP hop, is the reason we need GRE tunnels (versus using BGP multi- 
hop).

Not sure that is answering your question, but maybe throwing more  
words out could.

> Frustratedly,

Sorry, we will try to make it more clear.

Dino