I'm still continuing my review. I've now read halfway through Section 11, and
hope to complete the review by Friday.
Technical:
6.3. Routing Locator Reachability
I think Lisp supports only bidirectional reachability (unless it relies on
underlying BGP information), but I was unable to tell for sure from the
document. Nonces and probes appear to work only when the same locator pairs are
used for both directions of traffic. Could you say something about this in the
document?
6.5. Routing Locator Hashing
It may be useful to point to
http://tools.ietf.org/html/draft-ietf-6man-flow-ecmp-05 as well.
1. Either a source and destination address hash can be used or the
traditional 5-tuple hash which includes the source and
destination addresses, source and destination TCP, UDP, or SCTP
port numbers and the IP protocol number field or IPv6 next-
protocol fields of a packet a host originates from within a LISP
site. When a packet is not a TCP, UDP, or SCTP packet, the
source and destination addresses only from the header are used to
compute the hash.
There is a complication that fragments, and in general, IPv6 extension headers
make the 5-tuple approach impractical on some systems. I wonder if this should
affect the recommendation somehow. I can see the danger that people implement
the 5-tuple check incompletely, causing fragmented packets to potentially go to
a different path. But this is obviously a general issue, not Lisp specific. I
can't remember other recommendations than the 6man document above about this
matter. Does someone else remember?
6.6.2. Solicit-Map-Request (SMR)
The various rate limit mechanisms should either be specified or you should
state that the right parameters are still under experimentation (I'd prefer the
latter).
Since the ETRs don't keep track of remote ITRs that have cached their
mappings, they do not know which ITRs need to have their mappings
updated. As a result, an ETR will solicit Map-Requests (called an
SMR message) from those sites to which it has been sending
encapsulated data to for the last minute. In particular, an ETR will
send an SMR an ITR to which it has recently sent encapsulated data.
More time factors that we do not yet know if they work well.
But more importantly, what happens with ITRs who are not currently sending data
but had cached a map entry? If the previous cache entry still contains working
locators, we are fine, but what if not? Doesn't this point to a limitation that
locator sets cannot (completely) change except on time scales longer than map
entry cache lifetimes? Or am I missing something?
o When a tunnel encapsulated packet is received by an ETR, the outer
destination address may not be the address of the router.
This seems like a basic thing, but I must have missed this. Which Lisp tunnel
packets do not use the address of an ETR as the destination?
7. Router Performance Considerations
I expected this section to also talk about the effects of caching-based
designs. What happens when you suddenly are getting a flood of new destinations
to find a mapping to, etc.
The solution we propose to solve this problem is to cache traceroute
IPv4 headers in the ITR and to match them up with corresponding IPv4
Time Exceeded messages received from core routers and the ETR. The
ITR will use a circular buffer for caching the IPv4 and UDP headers
of traceroute packets.
All IPv4 UDP packets? Uh oh... perhaps you should include some of the
implications either here or Section 7. This means inspecting every packet, for
instance... Are you sure there are no other solutions to doing this?
The signature of a traceroute packet comes in two forms. The first
form is encoded as a UDP message where the destination port is
inspected for a range of values. The second form is encoded as an
ICMP message where the IP identification field is inspected for a
well-known value.
This is not much fun, either. Traceroute implementations generally allow quite
liberal specification of which packets should be used for the probing: ICMP
echo, UDP, TCP SYN, port selections, etc. At the very least you should document
what the implications are, i.e., that only limited traceroute functionality can
be supported. I don't think you can rely on configuration of port ranges and
other things, because even if the administrator would know what traceroute
types are used in his own network, traceroute should also work from the outside
in the other direction, initiated by other people.
10. Mobility Considerations
We've talked about this in the past. I don't think
mobility-as-a-feature-of-lisp belongs in this document, it belongs in the
possible future document on Lisp mobility. We should not speculate what could
be done.
The impacts of Lisp to mobility protocols are, however, in scope. But I at
least found the text somewhat unclear. First, I think you have decide what kind
of scenarios you'd like to support. The text talks about changing EIDs, and I
think that is something that you wouldn't necessarily need to cover; it is
pretty alien to the current mobility protocols. But it would be a very
reasonable question to ask if mobile nodes can move in and out of Lisp
networks, and what the effects are? As far as I can tell, this can subdivided
into the following aspects:
1) Pure mobile nodes (like most of today's laptops and PDAs) that do not
support mobility protocols. When such a node arrives in a Lisp site, it will
cause cache activity as it continues to do what it wants to do and re-establish
connections to the sites that it wants to communicate with.
2) Mobile nodes that support a mobility protocol (MIP4, MIP6, HIP, etc). If all
parties in the communication are in Lisp sites, these should not be affected
beyond the usual cache effects. Lisp as is should be able to support this.
3) As above but using interworking between the Lisp and the Non-Lisp Internets.
These bring NAT-like effects, I think, which may work with MIP4 but may have
issues with MIP6.
4) Home agents and other forwarding agents. Can these exist in a Lisp site? I
think the considerations are very similar to those in items 2 and 3.
Here's a suggested quick rewrite:
10. Mobility Considerations
There are several kinds of mobility of which only some might be of
concern to LISP. Essentially they are as follows.
10.1. Site Mobility
A site wishes to change its attachment points to the Internet, and
its LISP Tunnel Routers will have new RLOCs when it changes upstream
providers. Changes in EID-RLOC mappings for sites are expected to be
handled by configuration, outside of the LISP protocol.
10.2. Slow Endpoint Mobility
An individual endpoint wishes to move, but is not concerned about
maintaining session continuity. Renumbering is involved. LISP can
help with the issues surrounding renumbering [RFC4192] [LISA96] by
decoupling the address space used by a site from the address spaces
used by its ISPs. [RFC4984]
10.3. Fast Endpoint Mobility
Fast endpoint mobility occurs when an endpoint moves relatively
rapidly, changing its IP layer network attachment point. Maintenance
of session continuity is a goal. This is where the Mobile IPv4
[RFC5944] and Mobile IPv6 [RFC3775] [RFC4866]. Possible Lisp support for
similar functionality remains to be addressed by future work.
10.4. Interaction with Existing Mobile Nodes
Mobile nodes that do not support any particular protocol mechanism (such
as Mobile IP) should appear to Lisp sites just as other hosts do. However,
nodes that move around are likely to re-establish connections to their
communication peers when they enter the Lisp site, and this will likely
cause additional mapping entries to be fetched for the caches, and
may cause some initial performance degradation.
Mobile nodes that use a mobility protocol (Mobile IPv4, Mobile IPv6, HIP)
but communicate entirely within Lisp-enabled sites should not experience
any differences to their usual operations. Again, mobile node movement will
cause new communication patterns to the relevant home agents and, in the case
of route optimization, correspondent nodes.
The use of mobility protocols between Lisp-enabled and non-Lisp enabled sites
will likely cause NAT-like effects. The specific effects remain a topic for
further
work and experimentation.
Editorial:
There are two basic deployment trade-offs to consider: centralized
versus distributed caches and flat, recursive, or re-encapsulating
tunneling. When deciding on centralized versus distributed caching,
the following issues should be considered:
Perhaps you should define what you mean by centralized caching, distributed
caching, etc. It was not clear for me.
Jari
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
