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

[Lori Jakab <[e-mail]>]

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