Continuing with my review. Many of the observations below are questions. I may
understand most of these better once I finish the whole document, but I wanted
to send out my notes already now.
Technical:
o End-systems (hosts) only send to addresses which are EIDs. They
don't know addresses are EIDs versus RLOCs but assume packets get
to LISP routers, which in turn, deliver packets to the destination
the end-system has specified.
Is this always true, e.g, when some interworking mechanism between the LISP and
non-LISP parts of the Internet is in use, and one of the peers employs some NAT
traversal techniques? It would seem that there can be cases where the peers
observe RLOC addresses and use them for some purpose.
This might be something to mention in the limitations/things to test section,
for instance, or discussed in in the interworking document (and maybe it
already is, I did not check).
A server host can be the endpoint
of a LISP tunnel as well.
...
o RLOCs are always IP addresses assigned to routers
Isn't this an inconsistency? Or is a server that terminates a tunnel called a
router?
o When a router originates packets it may use as a source address
either an EID or RLOC.
You should state somewhere what the manageability requirements are for making
this happen, or if hardcoded policies are sufficient (e.g., iBGP vs. eBGP use
of addresses). Does this require additional functionality for RFC 3484 style
source address selection, or can you cope with existing functionality?
Note: I'm not asking for any new functionality, just a statement about the
expectations.
In order to avoid excessive packet overhead as well as possible
encapsulation loops, this document mandates that a maximum of two
LISP headers can be prepended to a packet.
This seems hard to mandate in any real sense. Perhaps you want to say "recommends"
instead of "mandates"?
2. The LISP ITR must be able to map the EID destination to an RLOC
of one of the ETRs at the destination site. The specific method
used to do this is not described in this example. See [ALT
<http://tools.ietf.org/html/draft-ietf-lisp-15#ref-ALT>] or
[CONS <http://tools.ietf.org/html/draft-ietf-lisp-15#ref-CONS>] for
possible solutions.
3. The ITR will send a LISP Map-Request. Map-Requests SHOULD be
rate-limited.
4. When an alternate mapping system is not in use, the Map-Request
packet is routed through the underlying routing system.
Otherwise, the Map-Request packet is routed on an alternate
logical topology. In either case, when the Map-Request arrives
at one of the ETRs at the destination site, it will process the
packet as a control message.
First, the the "alternate mapping system" appears here for the first time.
Maybe you should indicate it refers to [ALT].
Second, parts of step 4 go pretty deep in what the specific mapping methods
are. I'm wondering if this alternative text would fit better:
"4. The Map-Request packet is delivered to the right ETR with the help of the
mapping system. (For instance, in [ALT] this happens via an EID-based alternate routing
topology.) In any case, when the Map-Request arrives ..."
6. The ITR receives the Map-Reply message, parses the message (to
check for format validity) and stores the mapping information
from the packet. This information is stored in the ITR's EID-to-
RLOC mapping cache. Note that the map cache is an on-demand
cache. An ITR will manage its map cache in such a way that
optimizes for its resource constraints.
This is just a comment, but FWIW, I am not super happy about the way the
caching is an integral part of the specifications for LISP. Fundamentally, you
could have used two orthogonal tools for dealing with routing scalability: 1.
have only a subset of routers have to deal with EID routing (the xTRs) and 2.
use caching for scaling these routers better. If we had done this, then we
would have had a very easy answer to those who have criticized the caching
approach over the years: it is optional and up to the implementors to use or
not. The first tool would still have been a valid approach to make the Internet
scale better, even if you never did any caching.
In any case, your description of the thins-to-test should probably say
something about effects of caching.
8. The ETR receives these packets directly (since the destination
address is one of its assigned IP addresses), strips the LISP
header and forwards the packets to the attached destination host.
Spoofing of inner header addresses of LISP encapsulated packets is
possible like with any tunneling mechanism. ITRs MUST verify the
source address of a packet to be an EID that belongs to the site's
EID-prefix range prior to encapsulation. An ETR must only
decapsulate and forward datagrams with an inner header destination
that matches one of its EID-prefix ranges. If, upon receipt and
decapsulation, the destination EID of a datagram does not match one
of the ETR's configured EID-prefixes, the ETR MUST drop the
datragram. If a LISP encapsulated packet arrives at an ETR, it MAY
compare the inner header source EID address and the outer header
source RLOC address with the mapping that exists in the mapping
database. Then when spoofing attacks occur, the outer header source
RLOC address can be used to trace back the attack to the source site,
using existing operational tools.
First, I think Step 8 should be slightly edited to cover the fact that some additional
checks are being made. E.g., "The ETR receives these packets directly (since ...),
checks the validity of the addresses used in the packet, strips the LISP header and
..."
Second, I wish you would have specified the source address checks better. Are
there situations where you would NOT want to make a pretty strict test, i.e.,
that source EID maps to source RLOC?
The next sub-sections illustrate packet formats for the
homogenous case (IPv4-in-IPv4 and IPv6-in-IPv6) but all 4
combinations SHOULD be supported.
For interoperability, wouldn't it be cleaner to have a MUST here? How would I
otherwise know if I can send an IPv4-in-IPv6 packet to a destination?
Editorial:
Since additional tunnel headers are prepended, the packet becomes
larger and can exceed the MTU of any link traversed from the ITR to
the ETR. It is recommended in IPv4 that packets do not get
fragmented as they are encapsulated by the ITR. Instead, the packet
is dropped and an ICMP Too Big message is returned to the source.
This feels odd, as there is no explanation in this point about what you do with
IPv6. Maybe a sentence on IPv6 should be added?
I'm sure the details on IPv6 follow later in the document, but I suspect that
other readers would be wondering here in the same way as I am.
I'm reading on...
Jari
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
