Subject: [lisp] draft-ietf-lisp-architecture-00: Architectural Aspects

From: Ronald Bonica <[email-masked]>
Date: Fri, 4 Jan 2013 16:47:16 +0000

Hi Noel,

I have been dedicating a little time each day to a close reading of draft-ietf-lisp-architecture and will generate a few comments each day as the work progresses. The following are comments on Section 4 (Architectural Aspects).

Section 4.1: Critical State
===========================
This section would be more concrete if you identified the state that you considered to be critical. We can probably agree that mapping information, as it is maintained within the mapping system, is critical. However, reading this section, I can't tell whether you consider the map-cache, as it is maintain in an xTR, also to be critical. Could you clarify this in the text?

Also, if you consider the xTR map-cache to contain critical state, you should probably note that staleness, as well as loss of this state can cause loss of connectivity.

A New Section Between 4.1 and 4.2: xTR State
============================================
You might want to add a section stating that LISP distinguishes itself from other routing architectures because:

- it maintains a cached-subset of mapping information on the xTR
- the xTR pulls mapping information from the mapping system to itself (as opposed to letting the mapping system push it)

With this architecture comes benefits and costs. One benefit is memory savings on the xTR. (There may be other benefits). The cost is that the protocol needs to address the problem of cache freshness without compromising performance or security. 

Section 4.3: Piggybacking of Control on User Data
=================================================
- Would it be fair to say that a major motivation for piggybacking control information on user data is to address the problem of xTR cache freshness? That having this information reduces the need to expire map-cache entries more quickly than might otherwise be necessary?

- Would it be fair to say that the piggybacking of control information on user data reduces the amount of ETR probing that is required to maintain cache freshness, but does not totally eliminate it. 

- Would it be fair to say that piggybacking of control information on user data introduces a class of security issues, many of which are addressed in draft-ietf-lisp-threats?

- If any of the above statements are true, it might be helpful to add them to Section 4.3.

--------------------------
Ron Bonica
vcard:       www.bonica.org/ron/ronbonica.vcf