Folks,
In draft-ietf-lisp-eid-block-10 you say:
Avoid excessive stretch: In some deployment scenarios, in order to
avoid packet drops, packets triggering a LISP Cache miss are
forwarded toward a PETR, during the time necessary to perform a
mapping lookup over the LISP mapping system. Once a mapping is
obtained packet are not forwarded anymore toward the PETR, they
are LISP encapsulated and forwarded according to the LISP
specifications. The existence of a LISP specific EID block
would allow to avoid scenarios with excessive overhead, where
the destination is a LISP EID and where (while the mapping is
looked up) packets are forwarded over paths like
Source->ITR->PETR->PITR->ETR->Destination, which may show an
excessive stretch factor and degraded performance.
Is this behavior documented anywhere else? If so, where?
Is this behavior also observed in IPv4 implementations?
Also, is there serious consideration to using LISP as a VPN mechanism (as
suggested in draft-ietf-lisp-impact-01 and draft-ietf-lisp-introduction-13). If
so, this behavior should be mentioned in the Threats document.
Ron Bonica
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
