>
> 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
This is actually incorrect. An ITR or PITR will encapsulate to a PETR, not when
a cache miss happens but when the mapping system returns a “forward-native”
action in a Null Map-Reply (one with no locator-set).
> 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
What is returned by the mapping system is the best least specific prefix that
describes all non EID destinations within it.
This “forward-native” entry is put in the map-cache with one or more PETRs in
the locator-set. Current implementations configure this set of PETRs.
> 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
This is totally wrong. PITR, by definition, are not decapsulators. Maybe the
author meant:
Source -> ITR -> RTR -> ETR -> Destination
which is a different type of path and use-case then:
Source -> ITR -> PETR -> Destination
where the PETR is natively forwarding to the destination. This is the case
where a LISP-site is sending to a non-LISP site.
> excessive stretch factor and degraded performance.
>
> Is this behavior documented anywhere else? If so, where?
The latter is in the Interworking RFC and the Deployment RFC.
> Is this behavior also observed in IPv4 implementations?
In all environments. Even VXLAN/LISP data-center environments.
> 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.
Yes, there are several large deployments and there was a use-case ID that was
written and has expired.
Dino
>
> Ron Bonica
>
> _______________________________________________
> lisp mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/lisp
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
