Subject: [lisp] AD review of draft-ietf-lisp (poart 5)

From: Jari Arkko <[email-masked]>
Date: Thu, 20 Oct 2011 01:26:47 +0300

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