Re: [RRG] Comments on draft-lewis-lisp-interworking

[Jari Arkko <jari.arkko@piuha.net>]

Dino,

>>>   In case 3 (LISP site to Non-LISP site), a LISP site can send packets
>>>   to a non-LISP site because the non-LISP site prefixes are routable.
>>>   The non-LISP site need not do anything new to receive packets.  The
>>>   only action the LISP site needs to take is to know when not to LISP-
>>>   encapsulate packets.
>>
>> Hmm. But aren't there other things involved, too? If you do not
>
> Like what?
>
>> LISP-encapsulate, you must be performing some kind of NAT translation to
>
> No, not in this case. We break out the case when the non-LISP site
> wants to send packets to the LISP site into 2 sub-cases, if the LISP
> site has routable addresses and when it does not.
>
> And of course when it doesn't have routable addresses, you have to
> NAT, you have no choice. Just like your home network does.

Right. I was merely pointing out the need for the NAT in the second case.

>> Observation on Section 4.3: limiting the impact of routable EIDs is not
>> enough, we have to create an incentive to do so. Since we cannot block
>> people from advertising things in BGP, pretty much the only remaining
>> option is to make some other approach more desirable: better, cheaper,
>> faster, etc. Can you say something about what
>
> That is what the PTR option is for. It's simply a question of having
> this control locally at the site (the NAT solution) or having the
> infrastructure help (the PTR solution). They both have their downsides.

I understand that there are two options, and that they are different.
But it still has to be the case that whatever my site decides to do the
end result has to be better than simply pushing the information via BGP,
otherwise it won't get done. I think the PTR approach is the potentially
more attractive approach. However, for me to rely on that there has to
be someone who deploys a PTR. Who do they deploy it? (I think there are
good answers to this; I'm asking you to document those.)

>> Comment on Section 5: The document should talk about what is the
>> motivation for deploying PTRs.
>
> Will add to it, but you probably guess the motivation is so you can
> pull PI addresses out of the core as soon as possible without using
> NATs on the edges.

This is a motivation from the point of view of the Internet, not a
motivation for me as an business person to buy a new box that serves
some other people.

As I said above, I think there are reasons for doing this. For instance,
I could imagine a business where I'm selling PTR connectivity to LISP
sites. However, this appears to work only if I can choose the LISP sites
that I'm serving. This seems to imply that I can only advertise part of
the identifier space with anycast. I'm wondering how that's better than
advertising PI space... but maybe your responses below on aggregation
will shed some light on this.

>
>> Comment on Section 5: I don't understand how we distinguish advertising
>> the EIDs vs. larger prefixes. Given the non-aggregability of EIDs, can
>
> Don't assume EIDs are not aggregatable, they could be very much
> aggregatable in IPv6 down to a /16. In IPv4, we'll have to use a few
> prefixes, hopefully just 10 or so and not in the 100s and definitely
> won't deploy it if in the 1000s. But many think this is still a very
> small price to pay (in the 1000s) to be able to suppress more specific
> PA advertisements of PI advertisements from the 10^6 multi-homed sites
> we expect to come.

I'm sorry, but I don't understand why you believe the EIDs are
aggregatable. Sure, we can choose a /4 which holds the EID space. But
the question is whether a PTR can advertise all of this, or if due to
business reasons you want to be able to switch between PTR providers. If
this is needed, I don't see how you can aggregate EID space.

>> you even have larger ones, other than "all EIDs"? The business
>> implications seem severe, because you cannot have contracts for specific
>> service.
>
> Well, maybe a business opportunity too!

Ok -- can you say more?

I realize that you don't want to reveal the business opportunities that
you see. But I would like to see even one example of a situation where
this makes business sense AND you can aggregate EID space.

>> Section 5.2: it seems that the MTU implications of PTRs are different
>> from pure LISP. In pure LISP, you have the ability to locally configure
>
> Please don't differentiate a PTR from a pure LISP. A PTR is a router
> that does ITR functionality but does not do ETR functionality because
> the packet has a direct-site return path.

Point taken about the return path.

>> your network with an MTU that fits in 1500 bytes even if a LISP header
>> is added to it. With PTRs, the encapsulation is happening without the
>> knowledge of the legacy endsite. This means that either we must require
>> the legacy endsites (and paths to them) to be able to deal with PMTU
>> discovery or the PTR - LISP site tunneling mechanisms need to be able to
>> carry 1500 byte payload packets. Some discussion of this might be useful
>> in the document.
>
> See draft-farinacci-lisp-06.txt for resolving MTU issues.

I did read it earlier, and I liked the MTU handling. However, you still
need to deal with path MTU on the legacy-to-LISP path with PTRs, and as
I explained above, you have to assume one of the following for this to work:

1) support for the new ICMP-less path MTU RFC in the legacy site.
2) that ICMP is not blocked in the legacy site or on the path to it
3) that path between PTR and LISP site has MTU > 1500 bytes.

>> Section 5.3, scaling. It seems that we hit the worst point when 50% of
>> the Internet is LISP capable and 50% not. Assuming equal traffic
>> distribution, 25% of traffic in the Internet would have to go through a
>> PTR, right? It would be interesting to see some discussion of the
>
> How do you think 25% of all traffic today will go through one router? 

Not one router, but through the set of all PTRs in the world.

> Well, it doesn't happen so LISP can't help create more switching
> capacity. You build out many of them. And deployment experience will
> tell us if the "interworking tunnels" should have large diameter (PTRs
> deployed closer to non-LISP sites) or smaller diameter (PTRs deployed
> closer to LISP-sites).

This sounds reasonable, but I'm not sure I fully understand how this
works -- maybe we need to resolve the aggregation question first before
we can talk about this. If you can aggregate EID space in the PTRs, I
think this will work.

>> anycast routing properties in this situation. For instance, do we expect
>
> PTRs might look like they use anycast addressing since other proposals
> refer to it as such. But it's not using anycast addressing. That is
> the PTR routers do not have the same IP address assigned to each of
> them. They simply advertise the same EID-prefixes making the non-LISP
> sites think there are multiple paths to the EID. This way, you
> distribute load by having sources send to the closest PTR which will
> encapsulate to the LISP site.

So, the PTRs have different IP addresses, but all advertise at least
partially overlapping EID space? Ok, the PTRs do not act as anycast end
points. Still, in the routing system the same EID space is advertised
from multiple locations. I suspect the properties of this are similar to
anycast.

Jari




--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg