Removing option 1 would solve my concern very nicely. Thanks.
Joel
On 2/3/2012 3:10 PM, Darrel Lewis wrote:
On Feb 3, 2012, at 10:35 AM, Joel M. Halpern wrote:
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.
Good point Joel, I think the text confuses the issue. At this point the right
way for a device to determine if the destination is LISP is to _look into the
mapping system_ not the DFZ. How about simply removing the first numbered
bullet, and adjusting the text?
I also noticed that I didn't provide in response to Jari on Section 8. (though
i right now I am at a loss for exactly what text to include I will think about
it. and reply this weekend.
-D
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
