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

[Dino Farinacci <dino@cisco.com>]

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  
> approach is to

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.

> 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.

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.

> 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.

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.

> 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.

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

> Two current questions.  What namespace are the GRE endpoint  
> addresses in?  The

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- 
> ALT routers

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.

> 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?

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

--
to unsubscribe send a message to rrg-request@psg.com 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