Subject: Re: [lisp] last call for draft-ietf-lisp-alt-06

From: Vince Fuller <[email-masked]>
Date: Fri, 13 May 2011 16:14:08 -0700

Hi Hannu-

Thank you for your review.

> The Introduction section refers to LISP 1.5 model that used to be in the
> base LISP spec, but now I am not able to find from the latest document
> version. This cloud be a left over from earlier versions, or then I am
> overlooking something.

Good catch. The terminology "LISP models x.y" is, indeed, obsolete and all
references to it should have been eliminated from all documents. This will
be fixed in the -07 draft.

> Definition section
> "LISP+ALT operates on two name spaces..." It looks to me that LISP ALT
> is primarly dealing with the EID space and very remotely (indirectly)
> with the RLOC space. Should the definition be more accurate on that?

The actual definitions are more precies. Since the introductory paragraph
regarding "two name spaces" and "new network elements" appears to add more
confusion than value, I am removing most of it. It will now simply say:

  This section provides high-level definitions of LISP concepts and
  components involved with and affected by LISP+ALT.

The definitions themselves are unchanged.

> Overall, the issue of ALT topology continues to bother me. In what kind
> of topology the ALT routers should be connected? The draft says the
> following about the toplogy:
> 
> a) "...roughly-hierarchical mesh in which routers at each level in the
> topology are responsible for aggregating..."
> 
> b) ... ALT Routers establish BGP sessions with one another...
> 
> c) ... roughly hierarchical, partial mesh ...
> 
> d) ... such a structure should minimize the number of EID-prefixes
>    carried by LISP+ALT nodes near the top of the hierarchy.
> 
> e) .. upstream ALT router
> 
> f) While related to the global routing database, the ALT serves a very
> different purpose and is organized into a very different hierarchy.
> 
> g) The ALT BGP peering topology should be arranged in a tree-like
>    fashion (with some meshiness), with redundancy to deal with node and
>    link failures. 
> h) ALT BGP mesh
> 
> i) to connect to different parts of the ALT hierarchy if the ETR
>    "owns" multiple EID-to-RLOC mappings for EID-prefixes that
>    cannot be aggregated by the same ALT Router (i.e. are not
>    topologically "close" to each other in the ALT).
> 
> Clearly some of the above relates to the EID address space delegation
> rather than the topology between the ALT routers. However, I would
> suggest a separate section that shows an example of a "reference"
> topology. I use the word "reference" here because all real deployments
> will have they own constraints which this or any other document cannot
> foresee. But such a section about the ALT topology and issues that
> should be taken into account when designing it would be useful. What do
> you think?

The intention is that EID-prefix delegation and ALT router topology be
deliberately coordinated to facilitate aggregation. Because the ALT is
a virtual network, its topology can be engineered through suitable tunnel
placement for this to be true. There are a number of obvious ways that one
could imagine delegating EID prefixes, with the example that comes most
readily to mind being along geographic boundaries. In such a scenario, a
site could be assigned an EID-prefix out of a block for, say, Helsinki. It
would configure its ALT tunnels to routers which perform aggregation for
other sites assigned in the same geographic area. Should the site later
move to Sydney, it would still tunnel back to the same aggregation point.
This means that there would be some "stretch" for Map-Requests sent over
the ALT for that site but that is not considered to be a performance issue
as long as data forwarding via RLOCs learned through LISP still followed
the actual Internet topology.

The document deliberately does not describe a "reference" topology because
it is not clear at this point in the LISP experiment how the "root" of the
EID-prefix assignment hierarchy should be defined; this is intimately
tied to how ALT routers should be interconnected to maximize topological
aggregation.

If there are specific inconsistencies in the (a) through (i) that you
mentioned above, please suggest the text changes that should be made to
each section. And if you'd like to take a crack at suggested text describing
the relationship between EID prefix assignment and ALT aggregation, I'd
consider adding it as a new section.

	--Vince