Re: [lisp] Comments on draft-fuller-lisp-alt-04

[Vince Fuller <[e-mail]>]

> 1. I think that it would be useful to add in the document an example
> deployment scenario with a few xTR and a few ALT-routers. This would
> allow the reader to better understand how the ALT topology operates.

This is a good suggestion but I question whether I could do a good job of
describing such an example using text and ASCII art. I will consult with my
co-authors to see what they think.

> 2. The types of messages that are transmitted on the ALT-topology are
> unclear. From my reading of the text, it seems that the ALT-topology
> (i.e. the tunnels between ALT routers) is only used to forward two types
> of messages :
> - Data Probes
> - Map Requests

You are correct. The references to routing Map-Replies over the ALT were
relics of earlier thinking. The -05 draft will eliminate all such references
with the caveat that there may be future experiments involving routing of
Map-Replies over the ALT.

> 3. Map Requests and Data Probes that are sent on the ALT topology should
> be rate limited. This is mentionned in draft-lisp-11, but I think that
> it would be worthwhile to mention this again here.

This is mentioned briefly in the security section under "Scaling of LISP+ALT
router Resources". I will add additional text to strengthen this.

Note also that the -05 draft will discourage the use of Data Probes as there
are a number of open issues that make prove them infeasible.

> 4. Section 5.2 on EID assignment - Hierarchy and topology
> This is a key section of the document that needs to be expanded and
> detailed.
> 
> A first approach would be to define a tree-shaped ALT network, with the
> RIR reponsible for each aggregated EID block at the root. These RIRs
> should have ALT routers and be interconnected by a full mesh of ALT-BGP
> sessions.
> 
> A more detailed example would be useful in this section. You might
> consider RIR1 which is responsible for the allocation of 1.0.0.0/8 and
> RIR2 which is responsible for the allocation of 2.0.0.0/8

Another good suggestion. Again, I will discuss with my co-authors whether
we should add more example configuraation scenarios to the document.

> 5. What should an ALT router do when it receives a packet whose
> destination EID is unreachable (either because of the failure of an ALT
> session or because the corresponding EID block has not been allocated) ?
>  Should it drop the packet or send back an ICMP destination unreachable
> over the normal topology towards the source RLOC ?

There are actually multiple cases here.

If an ALT router receives a Map-Request or Data Probe that matches an EID
Prefix that it knows does not exist (e.g. if it is the aggregator for
10.1.0.0/16, the prefix 10.1.254.0/24 is not assigned, and it receives
a Map-Request or Data Probe destined to 10.1.254.1), it returns a Negative
Map-Reply for the shortest covering prefix that is not a LISP EID. A
Negative Map-Reply is a Map-Reply with zero RLOCs. In this example, the
EID prefix in the Map-Reply could be anything from 10.1.254.1/32 to
10.1.0.0/16 and would depend on what, if any, assignments had been made from
10.1.0.0/16.

The case where an EID prefix does exist in the LISP database but has no
reachable RLOCs is, in some sense, more interesting. Dino - what do is the
correct behavior for an aggregating ALT router in this case?

	--Vince