Hi Lori, Sorry for the delay; the changes that were applied look OK to me.
Thanks - Fred [email protected] > -----Original Message----- > From: Lori Jakab [mailto:[email protected]] > Sent: Wednesday, March 20, 2013 3:55 AM > To: Templin, Fred L > Cc: [email protected] > Subject: Re: [lisp] comments on 'draft-ietf-lisp-deployment-06' > > 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
