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
