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

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

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