Restriction on number of encapsulations (comment 13 reported by Y. Rekhter)

[wmhaddad@…]

Section 4:

An additional LISP header may be prepended to packets by a transit
router (i.e. TE-ITR) when re-routing of the path for a packet is
desired. An obvious instance of this would be an ISP router that
needs to perform traffic engineering for packets in flow through its
network. In such a situation, termed Recursive Tunneling, an ISP
transit acts as an additional ingress tunnel router and the RLOC it
uses for the new prepended header would be either a TE-ETR within the
ISP (along intra-ISP traffic engineered path) or a TE-ETR within
another ISP (an inter-ISP traffic engineered path, where an agreement
to build such a path exists).

This specification mandates that no more than two LISP headers get
prepended to a packet. This avoids excessive packet overhead as well
as possible encapsulation loops. It is believed two headers is
sufficient, where the first prepended header is used at a site for
Location/Identity? separation and second prepended header is used
inside a service provider for Traffic Engineering purposes.

The restriction on the number of encapsulations seems impossible to enforce, and therefore somewhat pointless. Worse, it seems harmful; in order to foil ISP TE, all one needs to do is place an extra header in the LISP packets. If the spec is obeyed,
re-encapsulation will be prevented.

The restriction on the number of headers would also seem to preclude host-based implementations of LISP being located behind site-based LISP routers.