I am a bit concerned that the description of the cases does not work.
In particular, if I am reading the text (preserved below) properly, it
says that the ITR can use the presence of a covering prefix in the
regular BGP table to tell that a destination is a non-LISP destination.
But in order for interworking to function, all LISP EIDs must fall into
prefixes which are advertised into the regular BGP routing table by
PITRs somewhere. As such, it seems that decision process 1 below would
be counter-productive, sending all LISP-LISP traffic through PITRs.
Since I know that what I am inferring is not what you intend, we need
better text please.
Yours,
Joel
On 2/3/2012 1:21 PM, Darrel Lewis wrote:
Yes this is a good suggestion. Interworking pre-dated negative map-replies so
the text hear isn't as clear as it should be. How about:
In case 3, LISP site to Non-LISP site, a LISP site can (in most
cases) send packets to a non-LISP site because the non-LISP site
prefixes are routable. The non-LISP site need not do anything new to
receive packets. The only action the LISP site needs to take is
to know when not to LISP-encapsulate packets. This can be achieved
by using one of two mechanisms:
1. At the ITR in the source site, if the destination of an IP packet
is found to match a prefix from the BGP routing table, then the
site is directly reachable by the BGP core as it exists and
operates today.
2. An ITR knows explicitly that the destination is non-LISP if the
destination IP address of an IP packet matches a (negative)
Map-Cache entry which has the action 'Natively-Forward'.
There are some situations where (un-encapsulated) packets originated by a
LISP site may not get forwarded successfully to a non-LISP site.
These situations are reviewed in section 7, (Proxy-Egress Tunnel Routers).
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
