Hi Fred, Thank you very much for the feedback. See responses in-line below:
On 02/26/13 00:55, Templin, Fred L wrote: > Hi, > > I am reading this document for the first time and had a few > comments to share below. > > Thanks - Fred > [email protected] > > 1) Section 2.5 ("Tunnel Routers Behind NAT"), this seems to > show a limitation in that there can be only one xTR behind > a NAT. I would like to address the case when there may be > many xTRs behind the NAT - can LISP do that? There is specification being worked on that will enable many xTRs behind NAT. It will, however require a Re-encapsulating Tunnel Router (RTR) to proxy all data packets for it to work. See https://tools.ietf.org/html/draft-ermagan-lisp-nat-traversal > > 2) Section 2.6, I don't understand why it says "MTU/PMTUD > issues minimized" for the recursive scenario? It's a typo, thanks for catching this! > > 3) Section 6.1, number 4, should say "request increase in MTU > to 1556 *or greater* on service provider connections". Indeed, will fix. > However, controlling just the first-hop interface MTU > does not assure MTU mitigations across the entire path. > Similarly, "care must be taken that ICMP is not being > filtered" cannot be assured along the entire path. And, > studies have shown that ICMP filtering does impact MTU > handling in current operational practices: > > > http://www.nlnetlabs.nl/downloads/publications/pmtu-black-holes-msc-thesis.pdf True, we are citing RFC 4459 at the end of section 2.1 with regard to this issue. Would it help if we referenced it in this section as well? > > Additionally, I have a use case that I'm not sure is well addressed by > the document. I would like to address the use case of mobile networks > configured as stub sites that connect to ISPs via a mobile router. Each > mobile router may have multiple ISP connections, and can change its ISP > addresses dynamically as it moves around. Some of the ISP addresses may > be global and others may be private, such as behind a carrier-grade NAT. > Many such mobile routers may be located behind the same NAT. > > I want to give each mobile router an EID prefix that it can use to number > interfaces within the mobile network. The mobile network may contain just > one interface, a few interfaces, or it may contain many interfaces. > > I now want that the mobile network can remain reachable from the outside > world by the same EID prefix addresses even as the mobile router travels > around dynamically. The mobile router will need an xTR so that its ISPs > will not filter its packets that use EID source addresses. I also want > the mobile router to be able to traffic engineer in both the outgoing > *and* incoming directions. For this, there needs to be some sort of > server sitting outside of any NATs that the mobile router can "register" > itself with. The mobile router should be able to change between different > servers as it moves around, e.g., to reduce path stretch or in the > event of a server failure. The servers in turn associate with proxy > xTRs so that outgoing packets destined to EIDs located in distant > networks can be routed appropriately. > > This is the way IRON sets things up. Can it also be done with LISP? Yes, using the NAT traversal specification I mentioned above. The mobile router should be an xTR itself, and will receive a list of RTRs (what you call servers above) it can use for traversing the NAT (for the connections where a NAT is detected). Path stretch optimizations are certainly possible, they depend on the implementation of the Map-Server. Incoming traffic engineering is possible with LISP, however, outgoing traffic engineering is not LISP specific, it should be done with existing mechanisms. Would you like this scenario added to the document? Best regards, -Lori _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
