Subject: [RAM] draft-farinacci-lisp-00

From: Brian E Carpenter <[email-masked]>
Date: Wed, 07 Feb 2007 12:32:16 +0100

Hi Dino, Vince and Dave O,

First, don't take this the wrong way, but I think your terminology is
broken.

To see what I mean, try the following substitutions:

EID -> SLOC (site locator)
RLOC -> GLOC (global locator)

Why? Because in fact, as you describe things, the SLOC (EID) is
a valid locator in the infrastructure of the end site, which might
by the way be an international corporate network. The GLOC (RLOC)
is a valid locator in the global Internet.

I can take this a little further. We could also imagine a
VLOC (VPN locator) which would apply on a VPN infrastructure,
but would logically be at the same level as a GLOC.

If you follow this logic and your mention of recursion, I think
you end up with xLOC where x stands for the routing context in
which the xLOC is used. You could certainly have a recursively
encapsulated packet GLOC.VLOC.SLOC.payload, for example.
Or alternatively you could say that in the case of a GLOC.SLOC.payload
packet, the Internet is the default VPN.

Apart from breaking your cute acronym, I don't think this
changes anything in your proposal. But I'm a bit leery of using
"ID/loc split" to describe what is actually a multi-level locator
scheme. (Which BTW I think is a very good approach, and I've thought
so since 1994.)

I can also restore the acronym: Locators In Sequence Protocol,
or Locators for Internet and Sites Protocol.

Now for a few specific comments.

> 2.  Introduction
...
>    1.  Reduction of routing table size in the "default-free zone" (DFZ).
>        Use of a separate numbering space for RLOCs will allow them to be
>        assigned topologically (in today's Internet, RLOCs would be
>        assigned by providers at client network attachment points),
>        greatly improving aggregation and reducing the number of
>        globally-visible, routable prefixes.

I think you probably mean "Containment" rather than "Reduction"
in practice. Also you miss out what I think is an important point:
containment of the number of BGP4 updates caused by edge prefixes.
(If you don't contain those, I think you don't solve the most serious
problem.)

Also I don't notice any explicit mention of multihoming here. I
think you need to be more clear how multihoming works with LISP.

...
>    Note that while the detailed protocol
>    specification and examples in this document assume IP version 4
>    (IPv4), there is nothing in the design that precludes use of the same
>    techniques and mechanisms for IPv6.  It should be possible for IPv4
>    packets to use IPv6 RLOCs and for IPv6 EIDs to be mapped to IPv4
>    RLOCs.

I think that you'll generate more negative feeling by not typing
in the IPv6 mapping than the saving in effort is worth :-)
Also, I'm curious how this will relate to what's already being
done in SOFTWIRE.

> 4.  Basic Overview
> 
>    One key concept of LISP is that end-systems (hosts) operate the same
>    way they do today.  The IP addresses that hosts use for tracking
>    sockets, connections, and for sending and receiving packets do not
>    change.  In LISP terminology, these IP addresses are called Endpoint
>    Identifiers (EIDs).
> 
>    Routers continue to forward packets based on IP destination
>    addresses.  These addresses are referred to as Routing Locators
>    (RLOCs).  Most routers along a path between two hosts will not
>    change; they continue to perform routing/forwarding lookups on
>    addresses (RLOCs) in the IP header.

Another point to mention is that site infrastructure, from SOHO to
large corporate, will continue to use "EIDs" as fully functional
locators (which is why I think you are wrong to describe this
as an ID/loc split). And that VPNs will continue to work largely
as they do today.

In fact, upper layers will just see TTLLAAs as they do today.
(TTLLAA = thing that looks like an address). That's a shared
feature with shim6 and an excellent property.

> 4.1.  Packet Flow Sequence
...
>    4.  The LISP header is stripped so that the packet can be forwarded
>        by the router control-plane.  The router looks up the destination
>        EID in the router's EID-to-RLOC database (not the cache, but the
>        configured data structure of RLOCs).  An ICMP EID-to-RLOC Mapping
>        message is originated by the egress router and is addressed to
>        the source RLOC from the LISP header of the original packet (this
>        is the ITR).  The source RLOC in the IP header of the ICMP
>        message is one of the ETR's RLOCs (one of the RLOCs that is
>        embedded in the ICMP payload).

What happens about lost ICMP packets, and how do you deal with
ICMP filtering, which is pretty common?

> 5.  Tunneling Details

Nit: "Type of Service" is called "Differentiated Services Field"
since RFC 2474.

Also, is there any nasty interaction with ECN?

> 10.  Security Considerations

Well, I'd really want to see more of a threat analysis. Surely
some of the attacks against shim6 would apply here too, unless
you deem the routing infrastructure immune to subversion?

    Brian

_______________________________________________
RAM mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ram