Re: [lisp] comments on 'draft-ietf-lisp-deployment-06'

["Templin, Fred L" <[e-mail]>]

Hi Lori,

Sorry for the delay; the changes that were applied look
OK to me.

Thanks - Fred
[e-mail]

> -----Original Message-----
> From: Lori Jakab [mailto:[e-mail]]
> Sent: Wednesday, March 20, 2013 3:55 AM
> To: Templin, Fred L
> Cc: [e-mail]
> 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:[e-mail]]
> >> Sent: Wednesday, February 27, 2013 8:30 AM
> >> To: Templin, Fred L
> >> Cc: [e-mail]
> >> 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
> >>> [e-mail]
> >>>
> >>> 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
> > [e-mail]
> >
> >> Best regards,
> >> -Lori