[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lisp] Comments to LISP+ALT draft



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 

 
 


 





 


Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.