Hi Fred, I just posted an updated revision, addressing your comments. In my previous reply I forgot that mobility is out of scope for now for the WG (and we already had a few mobility scenarios in mind, which we couldn't include), so I didn't add the mobile network scenario you mentioned.
Best regards, -Lori On 02/27/2013 11:56 PM, Templin, Fred L wrote: > Hi Lori, > >> -----Original Message----- >> From: Lori Jakab [mailto:[email protected]] >> Sent: Wednesday, February 27, 2013 8:30 AM >> To: Templin, Fred L >> Cc: [email protected] >> Subject: Re: [lisp] comments on 'draft-ietf-lisp-deployment-06' >> >> 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 > Thanks - I too noticed this draft after having sent the message. > >>> 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! > OK. > >>> 3) Section 6.1, number 4, should say "request increase in MTU >>> to 1556 *or greater* on service provider connections". >> Indeed, will fix. > OK. I leave the exact language up to you, but I think we agree > on the point. > >>> 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? > The "Verify MTU Handling" recommendations only apply to the > first-hop service provider connection. There is no way to > control any further hops beyond that. Maybe just add a > trailing sentence such as: "However, even with these > mitigations path MTU issues are still possible [RFC4459]." > >>> 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. > OK. > >> The mobile router should be an xTR itself, > OK. That matches with the "IRON Client" [RFC6179]. > >> and will receive a list of RTRs >> (what you call servers above) it can use for traversing the NAT > Right. that matches with the "IRON Server". > >> (for the connections where a NAT is detected). > It is also OK to just use the same function even for RLOCs > that are not behind a NAT. > >> Path stretch optimizations are certainly possible, > Right - that matches with AERO [RFC6706]. > >> they depend on the implementation of the Map-Server. > OK. > >> Incoming traffic engineering is possible with LISP, > How does the LISP mobile node tell the network how it wants > its inbound traffic to be delivered? IRON Clients provide > their Servers with a set of "handles" that represent their > ISP connections. The Client then informs the server as to how > it would like its inbound traffic to be delivered across > those handles - for example, some flows could be delivered > via the Client's WiFi interface and others delivered via the > Client's 4G interface, etc. Here, a handle is used instead of > an ISP address because the ISP address can change even while > the handle remains the same. > >> however, outgoing traffic engineering is not LISP specific, it should be >> done with existing mechanisms. > Right - the same for IRON. > >> Would you like this scenario added to the document? > You might want to take a look at "RANGER Scenarios" [RFC6139] for > this and other scenarios which might also be applicable to LISP. > From what you are saying, it sounds like addressing this scenario > is somewhat of a work-in-progress for LISP, where IRON already > has it pretty much worked out. It might be worth a comparative > study between the two approaches to see which pieces look the > most promising - and, the study could possibly indicate that a > combination of some features from both approaches would make the > most sense. The IRON-related documents are here: > > http://www.rfc-editor.org/rfc/rfc5320.txt > http://www.rfc-editor.org/rfc/rfc5558.txt > http://www.rfc-editor.org/rfc/rfc5720.txt > http://www.rfc-editor.org/rfc/rfc6139.txt > http://www.rfc-editor.org/rfc/rfc6179.txt > http://www.rfc-editor.org/rfc/rfc6706.txt > https://datatracker.ietf.org/doc/draft-templin-intarea-seal/ > https://datatracker.ietf.org/doc/draft-templin-intarea-vet/ > https://datatracker.ietf.org/doc/draft-templin-ironbis/ > > Thanks - Fred > [email protected] > >> Best regards, >> -Lori _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
