Subject: [lisp] Comments to LISP+ALT draft

From: "Flinck, Hannu (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 27 Oct 2009 14:34:53 +0200

Hello 

After reading the LISP+ALT (draft-ietf-lisp-alt-01) I have following
comments, suggestions and questions. 

General comment:

LISP+ALT draft lacks consistency with draft-ietf-lisp-ms-04, instead the
term "configuration" is used quite broadly covering the area of the
mentioned draft and leaving too much for a reader to fill in the caps.
See below what I mean:

Section 4 

Sentence from alt-01: "Note that ETRs are not required to participate
(or prevented from participating) in LISP+ALT; they may choose
communicate their mappings to their serving LISP+ALT router(s) at
subscription time via configuration." This is very true, but ETRs may
also choose to use Map-Register messages that contain a list of
EID-prefixes plus a set of RLOC as defined in draft-ietf-lisp-ms-04.txt
section 4. The issue here is that this is not only subscription time
event but a continuous (periodic to be more specific) process as defined
in draft-lisp-ms.

Section 5
Sentence "A LISP+ALT router near the edge learns EID prefixes originated
by authoritative ETRs, either by eBGP peering with them or by
configuration." This should be aligned with ietf-lisp-ms-04.txt to cover
Map-registering. 

Section 5.2
"It also implies that an ETR that originates a prefix must maintain BGP
sessions with all ALT routers that are configured to originate an
aggregate which covers that prefix. " This I find contradictory to the
target to keep ETR a simple CPE device as it insists on the use of BGP
peering.  

Section 5.4
"It receives Data Probes and Map-Requests only over GRE tunnel(s) to its
"upstream" LISP+ALT router(s) and responds with Map- Replies for the EID
prefixes that it "owns". " Here the text is about ETR. I guess that is
should say "receives Data Probes and Map-Requests ... FROM its
upstream... " 

Section 6.2
Sentence "these LISP+ALT router(s) the ETR must route Map-Requests and
Data Probes to the ETR and contain configuration (in effect, static
routes) for the ETR's ..." The first occurrence of "the ETR" looks like
a typo. If not more clarification in  the text would improve its
readability. Notice a again the use of the term of  "configuration" in
this context. Not really sure if this is the similar configuration that
was implied in the earlier part of the text.

Section 8.1
"Not only does this greatly improve the scalability of the global
routing system but it also allows improved traffic engineering
techniques by allowing richer and more fine-grained policies to be
applied."  But how are the operator policies and the mapping system
policies correlated? The network can only apply its existing BGP
policies for data packets entering into its network, but not during the
map resolution phase?

Section 9.1

"As in the case above, the ETR is connected to LISP+ALT router(s) using
GRE tunnel(s) but rather than BGP being used, the LISP+ALT router(s) are
configured with what are in effect "static routes" for the EID prefixes
"owned" by the ETR. " Maybe ETR chooses to use the Map-Register message
as in draft-eitf-lisp-ms, or is this what is meant by static routes?
In case the ETR happens to have connections  to multiple LISP+ALT
routers in different parts of the ALT hierarchy how does the ETR know
where to register/configure what EID prefix?

Best regards
Hannu

---

From: Vince Fuller <[email-masked]>
Date: Tue, 27 Oct 2009 11:05:42 -0700

> mentioned draft and leaving too much for a reader to fill in the caps.

Hello Hannu-

Thanks for the comments. The LISP+ALT spec authors are reviewing them and
considering how best to incorporate your suggestions.

I am a little hesitant to simply make all of the changes that you have
offered because the LISP+ALT spec pre-dates LISP-MS and is still intended
to be independent of it. I do agree that this historical fact has created
some inconsistencies between the two documents but need to consider how to
modify the wording in LISP+ALT to clarify things without at the same time
sacrificing its independence from LISP-MS.

	--Vince
	(for the LISP+ALT authors)

---

From: Sam Hartman <[email-masked]>
Date: Tue, 27 Oct 2009 15:53:53 -0400

>>>>> "Vince" == Vince Fuller <[email-masked]> writes:

    Vince> I am a little hesitant to simply make all of the changes
    Vince> that you have offered because the LISP+ALT spec pre-dates
    Vince> LISP-MS and is still intended to be independent of it. I do
    Vince> agree that this historical fact has created some
    Vince> inconsistencies between the two documents but need to
    Vince> consider how to modify the wording in LISP+ALT to clarify
    Vince> things without at the same time sacrificing its
    Vince> independence from LISP-MS.

Speaking as an individual.  I think that addressing these comments
while preserving independence is quite important.  It seems that
lisp+alt can distribute mapping information whenever it somehow knows
what BGP prefixes to announce.  That can happen either because the
prefixes are local, because "static routes" are configured, or because
the router learns the prefix through something else.  One something
else is that the router may be a map server (or receive information
through some mechanism from a map server).  However I don't see any
reason why the map server relationship should be special in this
specification.

I think that during the specification process we want to be careful to
define clean architectural interfaces around the components.  However
I do see the points that are made here and believe that addressing
these concerns could be an excellent opportunity to move towards these
cleaner interfaces.

I look forward to reviewing the editors' proposals for resolving these issues.